#17: Автоматизация модульного тестирования с Atollic TrueVERIFIER для повышения качества встраиваемых приложений

Анна Сергеева. Автоматизация модульного тестирования с Atollic TrueVERIFIER для повышения качества встраиваемых приложений // Компоненты и технологии. 2015. № 5. С. 88-93

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

Проблема еще более усугубляется тем, что средств целевого тестирования встраиваемых программных приложений на рынке представлено не так уж и много.

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

Опубликовано в разделе "Встраиваемые системы"

Эта же статья на сайте журнала

Введение

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

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

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

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

Кроме того, исходный код, совместимый со стандартом ANSI-C, часто ведет себя по-разному при обработке разными компиляторами или при запуске на процессорах с разной архитектурой. Типичными примерами являются формирование пакетов и упорядочивание структурных единиц, установка разных размеров по умолчанию для определенных типов данных (например, 8 или 32 бита для данных типа “char” ), и т. д.

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

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

Важность раннего обнаружения ошибок

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

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

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

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

Модульное тестирование

Для большинства встраиваемых приложений общепринятые методики тестирования программных приложений не подходят.

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

Модульные тесты - это тесты, которые направлены на конкретные C-функции, и вызывают их с различными комбинациями значений входных параметров, что приводит к различным путям выполнения кода этих функций.

Сложности применения к встраиваемым приложениям

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

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

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

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

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

И, конечно, стоит отдельно отметить, что сама специфика встраиваемых систем усложняет их тестирование.

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

Выбор стратегии

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

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

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

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

Возможности Atollic TrueVERIFIER

Данный инструмент модульного тестирования в полной мере соответствует всем строгим требованиям, предъявляемым к тестированию встраиваемых систем. Он поддерживает такие функциональные возможности, которые позволяют разработчикам встраиваемых систем обеспечивать высокий уровень целевого автоматизированного тестирования [3].

Среди ключевых возможностей Atollic TrueVERIFIER:

• Автоматическое генерирование модульных тестов;

• Ручное редактирование созданных тестовых наборов;

• Проведение функционального тестирования;

• Проведение тестирования совместимости (интеграционное тестирование);

• Автоматическое исполнение тестовых наборов на целевом отладочном оборудовании;

• Оценка качества проведенного тестирования.

Автоматическое генерирование модульных тестов

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

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

Функциональное тестирование

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

На рисунке 1 приведен показательный пример тестирования тривиальной С-функции путем ее многократного вызова с разными входными параметрами. При этом, инструмент тестирования выбирает и генерирует необходимые значения входных параметров (тестовых данных или тестового вектора) самостоятельно, то есть, автоматически.

Рис. 1. Автоматическое генерирование модульных тестов.

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

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

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

Интеграционное тестирование

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

Atollic TrueVERIFIER поддерживает и этот вид тестирования (рис. 2).

Рис. 2. Создание сценариев для интеграционного тестирования.

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

Редактирование сгенерированных тестовых наборов

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

Таким образом, разработчики, выполняющие модульное тестирование, получают целый ряд возможностей дорабатывать тесты вручную. А именно, с помощью специального редактора тестовой конфигурации (рис. 3) Atollic TrueVERIFIER позволяет:

• Редактировать наборы тестовых случаев или их входных параметров;

• Добавлять проверки возвращаемого кода;

• Добавлять код инициализации или завершения работы;

• Применять пользовательские способы обнаружения неисправностей произвольной сложности.

Рис. 3. Редактор тестовой конфигурации для модульного тестирования Atollic TrueVERIFIER.

Панель Project Explorer предназначена для удобной навигации по рабочим файлам. В дереве Test Suite List можно перейти к тому или иному тестовому набору, который необходимо модифицировать. На панели Unit Test приведен перечень доступных модульных тестов в наборе. В нижней панели отображаются результаты проведения тестирования в нескольких представлениях:Test cases (успех/ошибка выполнения конкретных тестовых случаев с конкретными входными данными), Global Variables (исследование влияния на работу функций используемых глобальных переменных), Coverage (измерение тестового покрытия кода).

В редакторе доступно добавление, редактирование и удаление тестов, по мере необходимости.

Дополнительные возможности

Тестовые векторы могут быть экспортированы для переноса во внешние сторонние инструменты (например, в Microsoft Excel) или для обратного импорта в данную систему тестирования.

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

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

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

Автоматическое выполнение целевых тестов

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

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

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

К числу таких инструментов относится и Atollic TrueVERIFIER. Он полностью интегрируется в Atollic TrueSTUDIO, профессиональную среду разработки, компиляции и отладки кода встраиваемых приложений на языке C/C++ [4]. Это позволяет легко синхронизировать разработку кода и тестов и пользоваться преимуществами интеграции со вспомогательными инструментами, такими как JTAG-отладчики.

Как только модульные тесты сгенерированы и помещены в исходный C-код, они автоматически компилируются с помощью интегрированных инструментов сборки встраиваемых приложений, а затем загружаются на целевую отладочную плату для использования в режиме JTAG-отладки (рис. 4). Далее осуществляется выполнение тестов на отладочной плате и динамический анализ прохождения тестов, для измерения достигнутого покрытия кода.

Рис. 4. Взаимодействие инструмента автоматизации тестирования встраиваемых систем с целевой платформой.

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

Рис. 5. Данные о результатах тестирования и достигнутом покрытии кода загружаются в среду разработки.

В примере показан неуспех обработки функции _rMySimpleFunc со входным параметром int x = 24. Результат подсвечен на интерфейсе красным цветом. Как видно из рисунка, ожидаемое (Expected) возвращаемое значение было 1, а в действительности (Output) функция вернула 0. Соответственно, в графе результата (Result) указан неуспех (failure) обработки данного тестового случая.

Atollic TrueVERIFIER поддерживает измерение покрытия кода на достаточно высоком уровне - MC/DC. (Это уровень качества тестирования, предъявляемый к ПО для систем управления полетами, подробнее рассматривается в следующем разделе.)

Итак, по сути, профессиональные инструменты автоматизации тестирования встраиваемых систем, такие как Atollic TrueVERIFIER, автоматизируют следующие задачи:

• Анализ исходного кода конкретных C-функций для выяснения, какие комбинации значений входных параметров повлияют на ход выполнения этих функций.

• Генерирование тестовых наборов (в исходном С-коде), которые многократно вызывают исследуемые функции с различными комбинациями значений входных параметров, создавая различные пути выполнения этих функций.

• Компиляция исходного кода тестовых наборов и привязка к целевой системе.

• Загрузка тестового набора на целевую отладочную плату в формате двоичного кода, для использования в режиме JTAG-отладки.

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

• Загрузка и визуализация результатов тестирования и достигнутого покрытия кода.

Оценка качества проведенного тестирования

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

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

Анализ покрытия кода

В рамках анализа тестового покрытия кода выполняется с помощью динамического анализа потока исполнения кода. Обычно в ходе анализа проводится исследование, какие части кода были протестированы, и, на основании этих данных, удается измерить качество тестирования [5] [6].

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

• Метод покрытия по строкам или блокам кода;

• Метод покрытия функций кода;

• Метод покрытия вызовов функций;

• Метод покрытия ветвей кода;

• Модифицированный метод покрытия по ветвям/условиям (Modified Condition/Decision Coverage или MC/DC).

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

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

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

В качестве такого достаточно серьезного примера, можно привести стандарт RTCA DO-178B. Он применяется для разработки критичного по безопасности ПО для летательных аппаратов. И требует выполнять тестирование по модифицированному методу MC/DC применительно ко всем наиболее критичным компонентам авиационного бортового ПО, где программная ошибка может привести к катастрофическим последствиям вплоть до потери воздушного судна и человеческих жизней.

Стоимость ошибок и почему так важно их избегать с самого начала

Самое интересное, что приведенный подход применим далеко не только к авиационно-космической отрасли.

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

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

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

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

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

Рисунок 6 иллюстрирует, как Atollic TrueVERIFIER отслеживает поток выполнения функций во время прогона набора тестов.

Рис. 6. Измерение качества тестирования с применением анализа покрытия кода.

В приведенном примере, выражение A проверяется таким образом, что учитываются все результаты обработки вложенных выражений (a, b, c) во всех ветвях кода. Таким образом, данное выражение должно быть протестировано, по меньшей мере, 4 раза.

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

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

Atollic TrueVERIFIER измеряет покрытие кода с применением метода MC/DC, что обеспечивает уровень качества тестирования, требуемый для критичного по безопасности авиационного бортового ПО.

Для каждой тестируемой функции Atollic TrueVERIFIER проверяет, все ли блоки кода выполнены и все ли ветви кода выполнены. Также он проверяет, все ли функции вызваны, все ли вызовы функций были реализованы. И все ли вложенные выражения в составных условных операторах были обработаны.

Эти данные обрабатываются, сопоставляются и отображаются в результирующем отчете, что позволяет легко и удобно выполнять проверку эффективности проведенного тестирования (рис. 7).

Рис. 7. Atollic TrueVERIFIER также измеряет уровень качества проведенного тестирования.

В нижней панели программы на табе Coverage доступен просмотр результатов покрытия как для всех функций (выбор Show All), так и для конкретных сгенерированных наборов и функций, доступных в списке (в примере, сгенерирован единственный набор MySimpleFunc_test0).

В таблице перечислены функции выбранных наборов (Function), результаты оценки покрытия по блокам кода (Block Coverage), покрытия ветвей кода (Branch Coverage) и оценка покрытия по методу MC/DC. Значения приводятся в процентном и абсолютном соотношении. Для удобства восприятия дополнительно реализована цветовая индикация: зеленый (доля объема кода, покрытого модульными тестами), красный (для кода, не охваченного тестированием), белый (для случаев, когда оценка покрытия не может быть выполнена).

Помимо того, что Atollic TrueVERIFIER способен создавать модульные тесты в автоматическом режиме, у него есть и другие достоинства.

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

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

Заключение

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

В то же время, сборка и выполнение модульных тестов на целевом отладочном оборудовании значительно экономит силы и время разработчиков. А эффективность их работы — повышает.

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

Внедрение профессиональных инструментов автоматизации тестирования встраиваемых систем, таких как Atollic TrueVERIFIER, позволяет разработчикам автоматически генерировать наборы модульных тестов и выполнять их в наиболее правдоподобной среде эксплуатации — на целевой отладочной плате.

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

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

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

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

Литература

1. А. Сергеева. Возможности статического анализатора Atollic TrueINSPECTOR для повышения качества встраиваемых приложений. // Компоненты и технологии. 2015. № 4.

2. А. Сергеева. Тестирование работоспособности промышленного компьютера. // Компоненты и технологии. 2014. № 2.

3. Об инструменте Atollic TrueVERIFIER - www.atollic.com/trueverifier

4. О среде разработки Atollic TrueSTUDIO - www.atollic.com/truestudio

5. А. Сергеева. Применение реинжиниринга при проектировании встраиваемых систем. Часть 1 // Компоненты и технологии. 2014. № 9.

6. А. Сергеева. Применение реинжиниринга при проектировании встраиваемых систем. Часть 2 // Компоненты и технологии. 2014. № 10.