Как провести модульное тестирование загрузчика на PIC18 с использованием стека TCP / IP?

Я разрабатываю загрузчик с использованием компилятора XC8 C 1.12 в MPLAB X 1.60 от Microchip. Целевой чип - PIC18F87J60. Мой загрузчик выполняет некоторые дополнительные функции, которые обычно не выполняются загрузчиками. Он загружает образ приложения на флеш-память с сервера и проверяет его целостность, вычисляя хэш-сумму MD5. Кроме того, он должен пройти тест аутентификации на сервере, специфичном для этого проекта. Чтобы все это работало, я использую стек TCP / IP v5.42 от Microchip.

Сейчас я хочу тщательно протестировать загрузчик, но у меня возникли проблемы с выбором правильного метода и инструментов. У меня есть доступ к Pickit 3 ICD, но нет никакого другого специализированного оборудования, такого как логические анализаторы и т. Д. (Кроме оссцилоскопа). Загрузчик реализован в виде иерархической FSM, что может (а может и не) усложнить ситуацию еще больше.

Я думал хотя бы о модульном тесте / модульном тестировании всех различных частей загрузчика и рассматривал все состояния FSM как отдельные функции. В Интернете есть несколько фреймворков для модульного тестирования, некоторые из которых утверждают, что их можно использовать во встроенных и ограниченных средах, таких как моя.

Проблема с ними в том, что большинство из них реализовано как своего рода библиотека C, которая будет скомпилирована с остальной частью программы, но все они ожидают, что компилятор будет следовать некоторому стандарту. Компилятор XC8 действительно следует стандарту C90, но не в полной мере (очевидно, из главы «Отклонение от стандарта ANSI C» в документации). Это вызывает проблемы при компиляции фреймворков.

Я мог бы обойти эту проблему, смоделировав все оборудование, зарегистрировав доступ и протестировав свою машину для разработки под Windows 7, но это потребует огромных усилий, поскольку я использую библиотеку TCP / IP, от которой сильно зависит загрузчик. Еще одним недостатком является то, что в конечном итоге я хочу протестировать на кристалле, потому что код C может вести себя на микросхеме PIC иначе, чем на моем Intel i7.

Есть ли у кого-нибудь идеи, как правильно unit-/moduletest мой загрузчик? Стоит ли проводить модульное тестирование такой программы на такой платформе? Могу ли я использовать какие-либо другие методики тестирования?

Требования / предварительные / примечания:

  • Я говорю о методах тестирования белого ящика. На данный момент тестирование Blackbox не является болезненным. Кроме того, функционально загрузчик не скомпилирован и все функциональные требования измеримы.
  • Я хочу максимально автоматизировать тесты и даже автоматически запускать тестирование, когда я нажимаю «скомпилировать».
  • Нет никаких строгих требований к производительности, и у меня есть запасная память ROM, так что инструменты кода, такие как установка большого количества датчиков, не должны быть большой проблемой.
  • Я далеко не гуру тестирования. Любые причудливые слова, которые я использовал выше, взяты всего за пару часов исследования, но у меня нет реального опыта тестирования.

Заранее благодарим за любые мысли и предложения.

Битджунки,


person Jupiter    schedule 29.06.2013    source источник


Ответы (2)


Я обнаружил, что модульное тестирование встроенных систем очень сложно. Побочные эффекты от периферийных устройств чрезвычайно обременительны. Сложнее всего справиться с побочными эффектами, вызванными чтением области памяти (например, чтением, очищающим флаг). Лучшее, что вы можете сделать, - это изолировать доступ к оборудованию. Даже внутри модуля ограничение доступа - хорошая идея. Модульное тестирование стоит того, но может достичь точки уменьшения отдачи намного быстрее во встроенном пространстве, чем другие.

Мне повезло с seatest. Это очень просто; он не предлагает более причудливых функций, предлагаемых Unity и др. (без автоматического имита) но это переносимый, прямой язык C и поддерживает основные функции, необходимые для тестирования.

Моя вторая рекомендация - создать файл с переменными, названными в честь всех доступных регистров вашего MCU. Легко очистить скрипт компоновщика Microchip на предмет имен регистров и вставить их в c-файл. Это значительно упрощает компиляцию всего вашего кода на платформе ПК. Это поможет вам быстрее приступить к работе, а также упростит тестирование.

person LogicG8    schedule 01.07.2013
comment
Скачал и попробовал seatest. Он скомпилирован после некоторых настроек, но PIC сбрасывается из-за переполнения стека при выполнении assert. Боюсь, что любой фреймворк, даже самый маленький, будет слишком большим / сложным для моего 8-битного PIC18. Я попробую создать свой собственный фреймворк с помощью MinUnit. - person Jupiter; 05.07.2013

Существует форк Unity для Microchip XC8 / PIC16, который не использует setjmp / longjmp, здесь: https://github.com/jwalkerbg/Unity

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

Попробуйте изолировать код, который не зависит от состояния оборудования (например, расчет md5), чтобы вы могли протестировать его в своей среде разработки (работающей на Intel i7). Тестирование этого кода можно легко автоматизировать (вы можете добавить задание тестирования в свой сценарий сборки, а также можете запустить все на сервере непрерывной интеграции).

Для кода, который зависит от состояния оборудования, вы можете (1) смоделировать оборудование или использовать симулятор (и по-прежнему запускать его в своей среде разработки или сервера непрерывной интеграции) или (2) запустить тесты, встроив его в ваше реальное оборудование. Вариант 2 не может быть легко автоматизирован. Возможно, вам даже придется развертывать и запускать каждый тест вручную. Кроме того, получение результатов теста может оказаться непростым, поскольку консоль или файловая система могут быть недоступны в вашей встроенной среде.

person ericbn    schedule 14.01.2014