Модульное тестирование проекта, использующего ОСРВ
Для моего следующего проекта по встраиваемым системам я хочу использовать модульное тестирование. Технически это может не быть разработкой, основанной на тестировании, но я бы, по крайней мере, хотел бы провести модульные тесты заранее и провести всестороннее тестирование.
Я использую цепочку инструментов IAR EWARM. Я рассматриваю возможность использования cmocka, unity или cunit. Я учусь использовать микроСи / ОС-III в качестве ОСРВ.
Вот вопрос: как модульное тестирование будет работать с ОСРВ на рисунке? EG: Должен ли я отключить ядро и тестировать модуль как однопоточное приложение и заглушить все / большинство вызовов ядра, или есть лучший способ?
Пример: в µC/OS-III точка входа остается главной. Из main вы вызываете любой код инициализации, а затем вызываете OSStart(), чтобы начать многозадачность. Поэтому, когда я запускаю тестовый жгут, я просто не могу сделать вызов OSStart()
#ifdef UNIT_TEST
test_runner();
#else
OSStart(&err);
#endif
Тогда во всем коде моего приложения в задачах мне просто нужно было высмеивать передачу сообщений и откладывать вызовы в ядро.
Это лучший способ сделать это. Или я бы лучше подошел для запуска ядра, создания задачи для моего тестового бегуна и запуска всех задач из этого как одного потока, или есть какой-то другой хороший подход, включающий порождение других задач из тестового жгута.
1 ответ
Похоже, у вас неправильное представление о модульном тестировании. То, использует ли ваш код ОСРВ, не имеет значения, поскольку модульное тестирование включает в себя тестирование модулей кода, т. Е. Функций Си, изолированно. ОСРВ не будет работать во время вашего теста.
Модульное тестирование также предполагает, что вы тестируете набор требований, определяющих функциональность кода. Целью большинства модульных тестов является предоставление различных форм покрытия вашего кода. Это включает в себя заявление, решение и покрытие принятия решения по нескольким условиям.
Охват операторов показывает, что вы выполнили каждую строку кода в функции.
Охват решения включает в себя показ того, что обе стороны (истина / ложь) всех условий
Множественное покрытие принятия решения по условию (MCDC) используется для проверки сложных решений, т. Е. If (a && (b || c)), и для обеспечения охвата всех вариантов. Тестирование MCDC обычно ограничивается очень важными приложениями, такими как авионика, где отказ может привести к катастрофическим результатам.
Подпрограммы обычно заглушаются, то есть перехватываются и контролируются, чтобы доказать, что каждый был вызван по порядку и что переданные аргументы верны, а различные возвращаемые значения работают правильно.
Я признаю, что не имею никакого опыта работы с инструментами, о которых вы упомянули, но есть ряд коммерческих инструментов модульного тестирования: Cantata, LDRA TestBench, IBM Rational Test Real Time и другие, которые подходят для углубленного модульного тестирования.
Существуют также коммерческие решения для самой ОСРВ. Моя компания предлагает и готовый блок и комплексный тестовый пакет для микроСи / ОС-II и мкС / ОС-III.
Scott Validated Software
Как правило, рекомендуется скрыть вызовы функций, специфичных для ОСРВ, с помощью некоторого уровня абстракции из вашего собственного программного стека. Это дает вам лучшую переносимость, если вы когда-нибудь будете менять платформу, включая RTOS. Просто измените вызов API в одном месте, и все готово.
Переход на этот шаг дополнительной абстракции дает еще одно преимущество, которое имеет отношение к этому ответу: это значительно упрощает модульное тестирование! Чтобы код можно было связать, вы можете имитировать все вызовы функций RTOS для запуска тестов в системе разработки с некоторой минималистичной реализацией API! В зависимости от ваших потребностей эти фиктивные объекты могут либо просто проверить, что переданные аргументы соответствуют ожиданиям. Или для простых вызовов API вы даже можете реализовать некоторые функции, чтобы еще больше расширить тестирование вашего собственного кода.
Очевидно, что это все еще не позволяет вам протестировать весь код со всеми зависимостями. Думаю, для встраиваемых систем это просто невозможно. Но он уже прошел долгий путь по сравнению с отсутствием модульных тестов для модулей, использующих вызовы API RTOS.