Тесты встроеного ПО

[pokk]

Добрый день, подскажите как можно протестировать некий программный модуль, который работает в МК. С  TDD я совсем не знаком успел только прочитать
"Модульное тестирование ПО встроенных систем в среде Unity" от Dale. Это конечно полезная вещь но она  не позволяет протестировать поведение программы именно в самом железе.

Вот у меня был модуль который переключает режимы работы вентилятора от значений температуры.
Я его сделал в виде нескольких состояний где переключение между ними происходит от значений температуры считываемого от термодатчика.
Что бы протестировать работу этого модуля мне пришлось отключить термодатчик и по интерфейсу связи вручную закидывать значения температуры.
Но такое тестирование можно проводить только на этапе разработки системы. А хотелось бы что бы его можно было запускать всегда и немного автоматизировать процесс(не вручную закидывать значения температуры).

Сложность тестирования этого модуля на ПК заключается в том что, значений температур переключение режимами задаётся пользователем и они находятся во внешнем ПЗУ.


Как ещё можно протестировать данный модуль ?

[Dale]

То, что Вы хотите сделать, относится к области приемочного или системного тестирования. Этот вид тестирования не имеет отношения к модульному, и для него применяются совершенно другие инструменты и, соответственно, другие методики: вместо TDD - BDD, в последнее время есть тенденция к сползанию на ATDD.

В принципе написать системные тесты можно и средствами xUnit, но это уж больно непрактично, поэтому так делают очень редко (судя по литературе; лично я вообще не встречал подобных прецедентов).

Я как-то делал перевод статьи "Развитие в направлении разработки встроенных систем", раздел 3.1 там как раз посвящен системному тестированию. К сожалению, там этот процесс описан весьма кратко, к тому же использованное там оборудование больше не выпускается, а программное обеспечение - не поддерживается, так что перенять их опыт один к одному не получится.

У меня есть инсайдерская информация, что недавно начался совместный российско-американский open source проект по разработке оборудования и ПО для системного тестирования встроенных систем. Но работы там непочатый край, и если этот проект и будет завершен успешно, то не завтра. На данный момент, к сожалению, только ручное тестирование ad hoc.

[Sla]

Внутреннее тестирование, на ограниченных ресурсах - это еще та, большая проблема.

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

Основной посыл, что нужен эталонный экземпляр..

Например.. ТЕСТ памяти. Сначала доверяемся Внутренним базовым регистрам. Ну, а кому еще?
Далее проводятся простые тесты
состояния ПЗУ, например, проверка контрольной суммы кода. (внимание! тест проводится на подозреваемом устройстве, где хранится сам код, но все же надо кому-то довериться).
Затем ОЗУ - грубые - быстрые (запись всех 0, всех 1) бегущая единица, бегущий 0, затем  при необходимости более ресурсоемкие - запись патернов снизу вверх, сверху вниз
После проверки "ресурса" принимается его истинность и трастовость. Тогда можно проверить и внутренние регистры, не базовые (порты и им подобные)
Сложно проверить частотные характеристики - время переключения, потому что задействован внутренний таймер работающий на внутренней частоте, но это можно проверить.. запустив два таймера, на разных скоростях (если есть два)
Или произвести иммитацию таймера.. Запустив таймер, и запустив известный цикл с заранее известными характеристиками

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

Т.е. ничего нового, ничего старого, вроде все просто, и в тоже время... иногда бессмысленно.

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

[Вад]

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

Что значит "вручную"? Спрашиваю потому, что диапазон тут от "вручную вбил значения в код модульного теста" до "вручную вбиваю каждый раз при запуске теста", и автоматизированное модульное тестирование подразумевает первое.
Причём, если так хочется тестировать на динамике от реального датчика, никто ж не мешает записать длинный ряд показаний с него в файл и тестировать с применением этого набора показаний, генерируемого "фальшивым" (mock) датчиком. Хотя это, возможно, и лишнее.

Сложность тестирования этого модуля на ПК заключается в том что, значений температур переключение режимами задаётся пользователем и они находятся во внешнем ПЗУ.

Не очень понял фразу: что пользователем задаётся? Как модуль узнаёт про эти заданные параметры и их изменение? И как это всё влияет на тестируемость модуля?

[pokk]

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

Что значит "вручную"?

Взял из головы значение температуры и отправил по USART после посмотрел, изменился режим(на светодиодах) или нет потом установил другое значение температуры и снова отправил походу это более подходит ко второму варианту.

2) Пользователь задаёт диапазон переключения режимов. Они записываются в ПЗУ, а при старте программы считываются от туда и модуль работает с ними как с константой. По этому в тесте надо как-то учитывать что за диапазоны были установлены или в идеале тест должен и их менять. 

[Вад]

pokk, но ведь модуль - это просто код (скорее всего, на языке C) - зачем его тестировать сразу в железе? Может быть, можно изолировать управляющую логику от работы с периферией и тестировать её отдельно, автоматическими модульными тестами?

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

Видимо, Dale сразу лучше вас понял, поскольку он и написал, что ваше описание похоже на приёмочное тестирование, когда вся система уже интегрирована.
Модульное тестирование подразумевает изолирование модуля от общения с реальной периферией и другими модулями и проверку его, и только его, корректности при заданных извне условиях (как позитивных, так и негативных - с некорректными входными данными). Для этого, возможно, потребуется ввести слои абстракции, чтобы разорвать прямые связи модуля с окружающей периферией, с помощью абстракций скрыв подробности общения с термодатчиком, светодиодами и прочими аппаратными устройствами, которыми ваш модуль управляет. То есть, фактически убрав этот код из вашего модуля куда-то наружу, так, чтобы ваш модуль только в общих чертах представлял, откуда он берёт данные и чем командует. Тогда его можно будет протестировать по первому варианту: подставлять разные пользовательские конфигурации и разные последовательности показаний датчиков, и убеждаться, что во всех случаях всё работает как задумано, без необходимости гонять эти сценарии вручную на железе.

[Dale]

Видимо, Dale сразу лучше вас понял

Скорее догадался по ключевой фразе:

Вот у меня был модуль который переключает...

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

[pokk]

Данную тему я поднял с целью определится в какою сторону копать, что бы к следующему проекту было понятно как добавить какой нибудь из видов тестов(или какой).
Вад, В принципе вы правы, но в тестирования в железе я приследую несколько целей:

1)  Быть уверенным на 100%  что при модификации любой части(модуля) программы, внесенные изменения не затронут другие модули косвенным образом(в качестве бага может быть функция memset c лишним байтом).
 При тестировании на ПК на 100% быть уверенным я не могу так как изначально у нас разорваны зависимости между модулями.

2) Что бы в случае такого 

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

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

3) Протестировать периферию. С этим как-то совсем всё туманно, ну к примеру модуль термодатчика (работающий на протоколе 1-wire) начал периодически выдавать КЗ на ноль или 1, вместо значения температуры. Тут единственное что я могу придумать это наставить контрольные точки в модуле и при прохождении их передавать их на ПК и после анализировать их. 

[Dale]

1)  Быть уверенным на 100%  что при модификации любой части(модуля) программы, внесенные изменения не затронут другие модули косвенным образом(в качестве бага может быть функция memset c лишним байтом).

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

При тестировании на ПК на 100% быть уверенным я не могу так как изначально у нас разорваны зависимости между модулями.

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

можно было просто найти отказавший компонент

Пока здесь, как я уже говорил выше, конь не валялся. Будем ждать успехов проекта. Если будут хорошие новости, непременно сообщу, сам их жду с нетерпением.

3) Протестировать периферию. С этим как-то совсем всё туманно

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

[Sla]

Чисто программным путем я не вижу возможности его диагностировать.

Можно частично. Путем накопления предыдущей информации.

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

Например отрыв - когда на входе сплошной шум
КЗ - четкая 1 или четкий 0

Или же резкие скачки, повторяющиеся во времени.

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


Кроме того, наличие внешних watch-dog'ов также могут помочь. (но это уже не программное решение, а комплекс)
Например, передача в watch-dog внутреннего состояния прибора. А вотчдог уже контролирует процесс внутренних состояний, последовательность их наступления, время нахождения в этом состоянии.

[Dale]

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

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

[Dale]

Кстати, иногда совсем незначительная модификация аппаратной части существенно облегчает диагностику. Вот реальный пример микросхемы H-моста для управления электродвигателем, с которой как-то доводилось иметь дело:

Добавление всего двух резисторов и компаратора позволило достоверно диагностировать обрыв в силовой цепи привода.

[pokk]

Кроме того, наличие внешних watch-dog'ов также могут помочь.

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

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

[Dale]

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

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

[Sla]

Самый простейший внешний watch-dog это схема ресета управляющего контроллера

Т.е. внешний таймер настраивается на определенное время... На момент окончания тайминга на сброс контроллера подается сигнал.
Управляющая программа контроллера, регулярно подает на на сброс таймера сигнал, таймер обнуляется и запускается заново. Если по какой-либо причине произошло зацикливание, или остановка управляющей программы, то вотчдог сигналом сброс перезагрузит контроллер.
Это простейшее описание. На самом деле все намного серьезней..
Т.е. не только сбросить, но еще и заблокировать управляющие цепи, чтоб на момент сброса не произошло резких переключений.
Кроме того, ватчдог может строиться, как я ранее говорил и на анализе состояний, где состояния контроллера жестко прописаны в вотчдоге.
Например:
Состояние передачи данных, состояние измерения, состояние ожидания внешнего сигнала.
Но не Состояние передачи данных, состояние ожидания, состояние измерения. 

И понятно, что это упрощение. Кроме того, вотчдог может "вешаться" на адресную шину и самостоятельно отслеживать состояние.
Т.е. поэтому адресу контроллер должен был прийти с этого адреса или с этого или с третьего, и уйти на другие известные вотчдогу, но никак иначе. Но это достаточно сложные и ресурсо(временные)емкие процедуры по согласованию работы двух устройств. Грубо, я не знаю как это называется сейчас, но в мое время это называлось - diagnostic processor - диагностический процессор.
зы.. я очень давно отошел от встроенных систем управления, так что не пинайте меня за, возможно, неверные формулировки. А за темой слежу только чисто из-за спортивного интереса - не мало лет отдано.