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

Question

Недавно я начал работать над очень большим проектом на C++, который после завершения 90% реализации определил, что им необходимо продемонстрировать 100% покрытие ветвей во время тестирования.Проект размещен на встроенной платформе (Green Hills Integrity).Я ищу предложения и опыт других пользователей StackOverflow, которые использовали продукты для покрытия кода в аналогичных средах.Меня интересуют как положительные, так и отрицательные комментарии относительно этих типов инструментов.

Answer 1

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

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

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

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

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

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

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

-Адам

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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