Анализ покрытия кода для проектов Embedded C++

100% покрытие филиалов? Это вполне обязательное требование, тем более, что некоторые ветки (например, значения по умолчанию в операторах case для конечных автоматов) не могут быть запущены. Я ожидаю, что есть исключения немного, и если их нет, вам может потребоваться понять, что тестирование покрытия может и чего не может выполнить, прежде чем вы начнете - иначе вы в конечном итоге вырветесь за волосы или, что еще хуже, предоставите неверные данные.

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

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

Перенос кода не так уж и сложен, если вы можете абстрагироваться от аппаратного кода (и, поскольку вы правильно используете C++, это должно быть легко, не так ли? ;-D). Самая большая проблема, с которой вы столкнетесь, - это типы, которые, хотя и лучше определены в C++, чем в C, все же создают некоторые проблемы. Убедитесь, что вы используете файл types.h или аналогичный, чтобы точно сообщить компилятору, какой именно тип вы используете и как его следует интерпретировать.

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

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

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

-Адам

Отказ от ответственности: я работаю в компании, производящей MxVDev.

Как и в случае с Адамом, мы переносим наш встроенный код на систему на базе ПК и делаем большую часть обзора и профилирования там. Я использовал AutomatedQA AQTime и Compuwares DevPartner, оба из которых являются хорошими продуктами,

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

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

Также стоит указать тем, кто просил о 100% покрытии кода, что 100% покрытие кода никоим образом не означает 100% покрытие тестами. Рассмотрим, например, следующую функцию;

int div(int a, int b)
{
return (a/b);
}

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

В прошлом мы использовали Кантата и vectorcast для модульного тестирования и покрытия кода. Мы также используем инструменты Greenhills, и оба эти инструмента работают с инструментами разработки Greenhills. Мы запускаем большую часть нашего теста на симуляторе PPC и просто запускаем тест, который полагается на оборудование на целевом оборудовании через модуль JTAG. Canatata и Vector cast очень похожи с catata, только немного проще в использовании и имеют немного больше функций, но небольшие дополнения имеют большое значение для пользовательского опыта.

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

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

Кроме того, эти инструменты сертифицированы по стандарту RTCA / DO-178B.

См. Покрытие SD C++ Test. Это семейство (ответвлений) инструментов тестирования для различных диалектов C++ (ANSI, GNU, MS ...), которые хорошо работают даже в реальном оборудовании встроенных систем благодаря очень малой занимаемой площади и простоте использования. способ экспорта собранных данных тестового покрытия. Отображение покрытия с графическим интерфейсом пользователя, которое не зависит от вашего реального встроенного оборудования, также будет отображать полную сводку отчета о покрытии.

[Я руководитель компании, которая предоставляет эти инструменты.]