Easyelectronics.ru

Доброго времени суток!
Кто как покрывает тестами свои прошивки?
Я пишу на C и у меня есть автомат реализующий протокол обмена данными на UART. Задействованы три прерывания: два на UART (прием и отправка байта) и один на таймер (для детектирования timeout'ов). Автомат хранит состояние в некоторой структуре protocol.
Есть ли более-менее удобный способ как покрыть тестами работу этого автомата?
Суть теста заключается в следующем:
1. обнуляем все данные в структуре protocol,
2. выставляем нужные для конкретно этого теста значения,
3. имитируем прием определенной посылки,
4. если автомат инициировал отправку - выполняем отправку этой посылки (сохраняем вывод из UART в массив)
5. проверяем результат:
5.1. тестовые значения определенных полей protocol - совпадают или нет.
5.2. что отправил автомат - то, что ожидали или нет.
*. если нужно имитируем прерывания таймера для проверки timeout'ов.

Проверка выполняется самого алгоритма, так что выполнять именно в аппаратном варианте нет смысла и я выполняю на PC просто вызывая прерывания как функции.
И пока столкнулся с тем, что все делать вручную не очень удобно, например для теста состояния структуры я использую три экземпляра protocol: 1. init - начальное состояние структуры, 2. mask и 3. value - битовая маска и значения, которые проверяю после теста (структура относительно большая, проверять абсолютно все поля смысла нет). Неудобство заключается в том, что проверить совпадает ли финальный экземпляр структуры по нужным мне параметрам я могу, но отобразить какие именно параметры отличаются - нормального способа не нашел.

Тестами хочу покрыть для того чтобы быть уверенным в рабочем алгоритме, т.к. ловить затем глюки раз в неделю на мк у меня желания нет.

Может есть уже готовые методики?

у меня методика простая - кодогенерация.
когогенерация и исходников и тестов и примеров использования.

либа протокола НЕ должна быть завязанана железо. отвязывайте и тестирование должно быть на обычном PC.

исходники сгенерированных тестов создают
некоторрую сетевую конфигурацию
создают пакеты
заливают их тестовыми данными
отправляют по сети, тестируя канал отправки и приёма
и
проверяют полное совпадение полученного и отправленного
и делается это на 7 языках

спасибо за ответ,

т.е. библиотека не должна напрямую взаимодействовать с прерываниями, а посредством, скажем, буферами приема/передачи, с которыми уже работают прерывания?
в моем варианте привязка к аппаратной перефирии есть, но я это обошел - при подключении на PC вместо регистров - глобальные переменные, которые контролируются тестами (не совсем одно и то же, но меня устраивает).


а как все это работает? - есть готовые библиотеки, при помощи которых можно реализовать подобное или все это самописное?

всё самописное.
кодогенерация происходит на Scala
плюс есть самописные плагины к IntelliJ, для поддержки и отладки кодогенерации
создана утилита по навигации по данным пакета и их отображение в Excel
создана утилита по отображению структуры данных (типа как в базах данных)
создана утитилита конвертирования описания из протобуфера в мой формат описания

и уже всё работает, но.... вот тут то и ожидала меня засада

когда начал гонять тесты именно на производительность, больших данных стало понятно, что я фатально ошибся в архитектуре.

я старался получить данные из сети, и с минимальными изменениями, заливал это в промежуточный байтовый массив, в формате позволяющими последовательно вычитывать из него данные. в...
формат нужный пользователю.
и если с чтением полученных макетов ещё ОК.
то ссозданием пакетов облом.

ошибка заключатся в том, что при заливки созданного пакета данными, особенно его необязательных полей происходило слишком много ресайзов массива и перемещения данных

ненужно было делать промежуточных структур-массивов, а сразу навязывать(генерировать) пользователю свои структуры, НО(!) с максимально быстрым доступом к полученным данным.

корни ошибки в том, что изначально, в первых версиях все это работало, и предназначалось только для микроконтроллеров...
но я решил расширить границы
и уперся в потолок больших данных.

сейчас сижу думаю как из этого выходить.

очевидно что бинарные данные нужно сразу писать в струкутуры с максимально быстрым доступом,
не надо в один массим класть несколько массивов и постепенно вычитывать.
нужно создавать отдельные массивы... да будет больше место занимать. и сериазизация потребует больше кода...
но зато быстрее читать и писать

Программа на пк читает входной текстовый файл и пишет в выходной текстовый файл

В этой программе
тестируемая функция [автомат]
контекст функции, сохраняющийся между её вызовами [состояние]
функция декодер строки из входного файла [события]
функция кодер строки в выходной файл [лог]

И цикл
чтение события -> декодер -> автомат -> кодер -> запись в лог
пока не кончится входной файл

Разбор лога любой тулзой для анализа текста, самое простое - awk [gawk] - любимое детище того самого Кернигана

Тестировать код микроконтроллера это весело, особенно если прошивка пишется в то время как менеджеры уже доложили о готовности продукта :)

P\S люблю автоматизировать испытания :) после написания прошивки скажем под STM32F030, быстренько набросать тестовую прошивку для какой либо дискаверины которая будет долбить по 1000 раз и эмулировать разные режимы работы, чуть что не так - остановка на конкретном участке (обычно брекпоинт ловушка).

Некоторые IDE предлагают собственные методы отладки. Например скриптовый отладчик в Keil.

ничего удобнее исходника с вшитыми, сгенерированными тестовыми данными нет.

отлаживаешь как обычно - запускаешь код. и стандартно ловишь ошибки.
ставишь брэкпойнты в проблемных местах и ходишь пошагово просматривая состояния.

нашел глюк? отлично! кусок сгенерёного кода откидываем в обязательное тестирование с пояснениями обнаруженных ошибок.

затем, жмакаем кнопку - сгенерировался новый исходник, с вшитыми новыми тестовыми данными
и так далее...

в ручную долбить тестовые данные - просто не реально. кстати для генерации тестовых значений циферок и строк использую scalacheck. дико удобно.

особенно мне "помогло", то, что сделал конвертер из формата протобуфера в свой формат описания протокола.

примеров готовых описаний протокола на протобуфере - дофига.

жмакаем кнопку - получаем описание в своём формате.
жмакаем кнопку- по описанию сгенерировался сам код разбора протокола
+ код тестирование я вшитыми тестовыми данными и некоторой сетефой конфигурацией
+ код примера как использовать сгенерённый код.

запускаем дебаг
создается пакет
заливается тестовыми данными и после этого тут же тестово вычитывается
потом этот пакет отправляется по тестовой вируальной инфраструктуре и получается.
опять полученное сравнивается с отправленным.
каждое поле, каждое значение.
всюду, в любом месте можно поставить брейкпойнт.

всё.

разве это не прекрасно?

именно дикое разнообразие уже готового кода описания протокола, пусть даже в другом формате, позволило мне отловить кучу багов и кейсов использования.

Пока нет статьи в сообществе с подробным и грамотным описанием требуемых телодвижений для реализации того где, что и как вам позволило, это треп и самопиар.

Это не трёп и самопиар, а просто классный костыль, который сначала, средством документации, надо превратить в инструмент, а потом, поддержкой и развитием - в продукт.
Проблема в том, что это не сделать силами одного человека. И дальше либо искать, кому это продать, либо выложить в открытый доступ. Но по этим направлением, увы, cheblin двигаться не готов. Давно хотел попробовать его поделие, благо оно вот прямо очень нужно мне в работе. Но сложность с явой и отсутствие описания как этим пользоваться для людей, не умеющих в скалу постоянно меня останавливает.

К примеру, классная зона применения его кодогенератора - реверс инженеринг проприетарного оборудования, которым я, увы, занимаюсь регулярно. Забиваешь в тесты отснифиные данные и лепишь структуры.

оу, это всё таааакое уже старое...

и это... Вы не совсем уловили идею.

Пользователь описывает в програмитской манере (используется лексика JAVA) метаинформацию - какие данные и куда ему нужно передать.
+ даёт небольшие подстказки кодогенератору, типа - данные этого поля есть смысл сжимать, а вот этого нет...

жмакает кнопку и через минуту в папке назначения получает исходники в заказанных языках програмирования.

Пользователь НЕ описывает сколько бит и в какой последовательности будет в протоколе... его это НЕ парит.
но если хочется заморочиться, весь код перед тобой. заморачивайся.


знать Scala не нужно, это мой внутренний инструмент написания кодогенератора и парсеров.

Вот из-за этого и не взлетает, потому что либо пользователь, либо программистские манеры

э-э-э програмист не может быть пользователем?

Из возможных вариантов нормальный человек, в том числе и программист, всегда выберет более простой

имя сестра, имя....

Ну давай рассмотрим какую-нибудь гипотетическую, но конкретную задачу
В контексте изиэлектроникс, не высокой поэзии
Предлагай

да вот, вполне конкретное описание протокола
в моем формате это описание будет выглядить так

Ну и кто что поймёт из твоей ссылки?

вообще, это хорошо известный широко используемый формат описания протокола Protocol Buffers

добавил ЭТО, конвертнутое в мой формат

каждый класс - это пакет с данными. поля в нем сами данные.
данные могут быть как примитивами так и строками, массивами, и ... другими пакетами(вложенности)


описание в протобуфере выглядит так

коряво и досих пор НЕ поддерживается в IDE... никакого рефакторинга, переименовать и переместить ещё тот геморой.

а вот это описание в моём формате



полная поддержка любой JAVA IDE, которых просто завались...

вот примерно во что это генерится на с++ в Protocol Buffers

Эмм... ладно, тогда я сам предложу )
Как насчёт попробовать применить эту кухню к GDB Remote Serial Protocol https://sourceware.org/gdb/onlinedocs/g ... tocol.html ?
Это позволило бы генерировать протокольную часть gdb-серверов на любых поддерживаемых генератором языках, то есть возможность делать gdb сервер на любом таком языке
Вплоть до того что упихивать это в мк, как это делает black magic probe https://github.com/blacksphere/blackmagic/wiki
Ну и gdb-серверы это не высосанная из пальца потребность, а все open source ide, которые сейчас из-за этого все замыкаются на openocd

тоже вариант с одним НО.

это не описание, это недоразумение.
а так да. вещь нужная. однако потребует предварительной большой, тотальной ручной работы напильником, прежде чем это можно будет передавать кодогенератору.

отложил себе, потом, в новой версии своего креатива к этому вернусь.

Да, а openocd в свою очередь замыкается на известные ему адаптеры, и всё, приплыли
Хотя jtag, swd и т.п. что идёт в сторону железа не проблема, но проблема что с этим делать дальше на верхнем уровне
В результате делают имитации адаптеров известных openocd

почему для реализации данного протокола нельзя было взять тот же Protocol Buffers?

подозреваю, что на тот момент его тупо ещё небыло.

потому и родилось вот такое, наколеночное угрёбище. полистал... тошниловка.

Ещё вторую часть марлезонского балета можешь полистать - как сам gdb общается с ide https://sourceware.org/gdb/onlinedocs/g ... 02fMI.html )