Введение от автора поста
Имея опыт разработки ПО для ответственных систем более чем 8 лет, хочу познакомить сообщество с некоторыми материалами, связанными с разработкой и верификацией ПО для ответственных систем (аэрокосмическая область, медицина, транспорт и промышленность). Получив согласие на перевод и адаптирование ряда интересных статей у зарубежных коллег решил воспользоваться данным ресурсом. Буду рад, если статья заинтересует наше сообщество. В статье использованы материалы фирмы Vector Software, Inc.
На вопросы отвечу в комментариях или в личку
Какой Вы используете инструмент тестирования?
За последние несколько лет рынок инструментов автоматизированного тестирования был заполнен средствами, претендующими на выполнение одной и той же функции – автоматизированного тестирования. Википедия перечисляет 38 инструментов оценки среды тестирования только для языков программирования С/С++. К сожалению, потенциальные пользователи, изучая описание данных продуктов, а также их упрощенные демонстрационные версии, могут сделать вывод, что большинство инструментов практически одинаковы.
Целью данного документа является предоставление инженерам информации, которую необходимо принимать во внимание при оценке автоматизированных инструментов тестирования ПО, особенно в части автоматизированных инструментов динамического тестирования.
Вы не сможете оценить инструмент тестирования, прочитав его спецификацию
Все спецификации выглядят достаточно однотипно. Ключевые слова одни и те же: «лидер отрасли», «уникальная технология», «автоматизированное тестирование», «передовые методы». Скриншоты похожи друг на друга: гистограммы, структурные схемы, HTML-отчеты и процентные показатели. Все это навевает скуку.
Что такое тестирование ПО?
Все, кто когда-либо занимался тестированием ПО, знают, что оно состоит из многих компонентов. Для простоты будем использовать три термина:
- Системное тестирование – тестирование полностью интегрированного программного приложения
- Интеграционное тестирование – тестирование интегрированных групп программных модулей
- Модульное тестирование – тестирование отдельных модулей исходного кода приложения
Каждый в той или иной степени проводит системное тестирование, в процессе которого он выполняет некоторые действия из тех, которые будет выполнять конечный пользователь. Заметьте, мы говорим о некоторых действиях, а не о «всех возможных». Одна из самых распространенных причин ошибок в приложении – появление непредвиденных и, следовательно, неисследованных комбинаций входных данных.
Не так много людей проводит интеграционное тестирование, и совсем немногие – модульное тестирование. Если вы проводили интеграционное или модульное тестирование, вы знаете, как много тестовых кодов нужно создать, чтобы изолировать отдельный файл или группу файлов от всех остальных в приложении. На наиболее требовательных уровнях тестирования распространена ситуация, когда количество написанного кода для тестирования превышает количество проверяемого кода. В результате, такие уровни тестирования применяются, как правило, к критичным для функциональности и безопасности приложениям в таких сферах как авиация, медицинские приборы, железнодорожная промышленность.
Что значит «автоматизированное тестирование»?
Хорошо известно, что проведение процесса интеграционного и модульного тестирования вручную чрезвычайно дорого и занимает много времени; в результате о каждом инструменте, появляющемся на рынке, «трубят» как об использующем автоматизированное тестирование. Но что это означает — «автоматизированное тестирование»? Слово «автоматизация»разные люди понимают по-своему. Для многих разработчиков автоматизированное тестирование означает возможность нажать кнопку и получить результат – «зеленую галочку», означающую, что код верный либо «красный крестик», означающий ошибку.
К сожалению, такого инструмента не существует. А если бы существовал, вы бы захотели использовать его? Подумайте об этом. Что бы значило, если бы инструмент показал, что ваш код «в порядке»? Значило бы это, что код безупречно отформатирован? Возможно. Значило бы это, что код соответствует вашим стандартам кодирования? Возможно. Значило бы это, что код верен? Определенно нет!
Полностью автоматизированное тестирование недостижимо и, в принципе, нежелательно. Автоматизация должна быть направлена на алгоритмические и трудоемкие части процесса тестирования. Это освободит разработчиков ПО от постоянного создания все более совершенных и сложных тестов.
При оценке инструментов тестирования, возникает логичный вопрос: какую степень автоматизации обеспечивает данный инструмент тестирования? Это основная зона неопределенности при попытке организации рассчитать окупаемость инвестиций в инструменты тестирования.
Анализ инструментов тестирования
Инструменты тестирования в общем обеспечивают разнообразные функциональные возможности. Так как разные инструментарии предоставляются разными компаниями, то функциональность может отличаться при использовании другого инструмента. В соответствии с распространенной системой критериев мы выбрали следующие названия для компонентов, которые могут существовать в оцениваемых инструментах тестирования:
- Анализатор — Данный компонент позволяет инструменту тестирования понять ваш код. Он читает код и создает промежуточное представление кода (обычно в виде иерархической структуры). По сути то же самое выполняет компилятор. Его выходные данные или «данные анализатора», как правило сохраняются в файле на промежуточном языке.
- Генератор кода — Генератор кода использует «данные анализатора» для конструирования исходного кода тестовой программы.
- Тестовая программа — Несмотря на то, что тестовая программа, строго говоря, не является составной частью инструмента тестирования, решения, принятые в процессе построения тестовой программы, влияют на остальные характеристики инструмента тестирования. Поэтому архитектура такой программы имеет большое значение при оценке инструмента тестирования.
- Компилятор — Позволяет инструменту тестирования инициировать компилирование и связывание компонентов тестовой программы.
- Целевой компонент — Позволяет тестовым сценариям выполняться в разнообразном окружении, включая поддержку программ-эмуляторов, симуляторов, встроенных программ-отладчиков и коммерческих операционных систем реального времени.
- Редактор тестов — Редактор тестов позволяет пользователю использовать как скриптовый язык, так и изощренный графический интерфейс пользователя для установки предусловий и ожидаемых значений (критериев прохождения/непрохождения) для тестового сценария.
- Покрытие — Позволяет пользователю получить отчет, какие части кода проверяются тестом.
- Компонент отчётов — Позволяет объединить данные, собранные во время прохождения тестов в единую проектную документацию.
- Интерпретатор командной строки — Обеспечивает дополнительную автоматизацию при использовании инструмента тестирования путем активации инструмента при помощи скриптов, утилиты make и др.
- Регрессионный компонент — Позволяет тестам, созданным для одной версии ПО, перезапускаться для новых версий.
- Интеграционный компонент — Интеграция с инструментами сторонних компаний может быть весомым фактором для принятия решения об инвестиции в инструменты тестирования. Как правило, распространена интеграция с системами конфигурационного управления, с инструментами управления требованиями и инструментами статического анализа.
Следующие разделы более подробнее опишут, как должны оцениваться вышеперечисленные компоненты в рассматриваемом инструменте тестирования.
Виды инструментов тестирования/уровни автоматизации
В связи с тем, что ни один из инструментов тестирования не включает все функциональные возможности компонентов тестирования, описанных выше, и, в связи с существенными различиями между инструментами по степени автоматизации, мы создали следующую широкую классификацию инструментов тестирования. Оцениваемый инструмент можно отнести к одной из следующих групп:
- Ручные — «Ручные» инструменты создают пустой каркас для тестовой программы и требуют от вас ручного написания кода тестовых данных и логической части для выполнения тестового сценария. Как правило, они предоставляют скриптовый язык и/или набор библиотечных функций, которые могут использоваться для таких распространенных процессов как тестовые подтверждения или создания табличных отчётов для тестовой документации.
- Полу-автоматизированные — Полу-автоматизированные инструменты могут иметь графический интерфейс и некоторые автоматизированные функциональные возможности, но все же требуют ручного написания кода и/или разработки скриптов для тестирования более сложных конструкций. Также у полу-автоматизированных инструментов могут отсутствовать некоторые компоненты автоматизированных инструментов, например, встроенная поддержка развёртывания ПО на целевой платформе.
- Автоматизированные — Автоматизированные инструменты имеют связь с каждой функциональной областью или компонентом, перечисленными в предыдущем разделе. Инструменты этой группы не требуют ручного кодирования и поддерживают как все конструкции языка, так и развёртывания ПО на разных целевых платформах.
Неявные различия инструментов тестирования
В дополнение к сравнению характеристик инструментов и уровней автоматизации, важно оценить и сравнить используемые подходы к тестированию. Например, когда вы создаете тестовый проект, инструмент просто загружает файлы в свою интегрированную среду разработки, но не создает тестовую программу или тестовый сценарий пока вы не предпримете определенные действия.
В результате в инструменте тестирования могут быть скрытые недостатки. Поэтому важно не просто загрузить ваш код в инструмент тестирования, но также попробовать построить несколько простых тестовых сценариев для каждого метода в классе, который вы тестируете. Строит ли инструмент полную тестовую программу? Создаются ли заглушки автоматически? Можете ли вы использовать графический интерфейс пользователя для определения параметров и общих данных для тестовых сценариев или вам приходится писать код вручную, как если бы вы проводили тестирование вручную?
Схожим образом поддержка целевой платформы различается по используемым инструментам. Будьте осторожны, если поставщик говорит: «Мы поддерживаем все компиляторы и целевые объекты». Это означает только одно: «Вам придется сделать всю работу, чтобы наш инструмент работал в вашей рабочей среде».
Как оценить инструменты тестирования
В следующих нескольких разделах будет в деталях описано, какую информацию вы должны внимательно изучить при оценке инструмента тестирования ПО. В идеале вам следует подтвердить полученную информацию на практике, протестировав каждый из предлагаемых инструментов.
В связи с тем, что последующий материал в настоящей документации будет носить технический характер, мы хотели бы ввести некоторые условные обозначения. У каждого раздела есть заголовок, который описывает вопрос, который будет рассматриваться, далее пояснение, почему данный вопрос важен, и, наконец, «ключевые моменты», как резюме рассмотренного материала.
Также, говоря об условных обозначениях, мы должны обратить внимание на терминологию. Термин «функция» относится как к функции языка программирования С, так и к методу класса языка программирования С++, термин «модуль» относится и к файлу языка программирования С и к классу языка программирования С++. Наконец, нужно помнить, что почти все инструменты тестирования каким-либо образом поддерживают пункты, упомянутые в «ключевых моментах», ваша задача – оценить уровень автоматизации, простоту использования и степень поддержки.
Анализатор и генератор кода
Относительно просто построить анализатор для языка программирования С; гораздо сложнее построить полноценный анализатор для языка программирования С++. Один из вопросов, на который нужно ответить в процессе оценки, это насколько надежна и хорошо продумана технология анализатора. Некоторые поставщики инструментов тестирования приобретают и перепродают лицензированную технологию анализатора, у других есть анализаторы собственного изготовления. Надежность анализатора и генератора кода может быть проверена при помощи сложных конструкций кодов – типовых образцов кода, который вы будете использовать в своем проекте.
Тест-драйвер
Тест-драйвер это главная программа, контролирующая тестирование. Приведем простой пример драйвера, который протестирует математическую функцию синуса из стандартной библиотеки языка программирования С:
#include <math.h>
#include <stdio.h>
int main () {
float local;
local = sin (90.0);
if (local == 1.0) printf ("My Test Passed!n");
else printf ("My Test Failed!n");
return 0;
}
Несмотря на то, что это довольно простой пример, «ручной» инструмент тестирования может потребовать от вас напечатать (и отладить) этот маленький кусочек кода вручную, полу-автоматизированный инструмент выдаст некий тип скриптового языка или простой GUI для ввода аргумента синуса. Автоматизированный инструмент будет содержать полноценный GUI для построения тестовых сценариев, интегрированный анализ покрытия кода, интегрированную программу-отладчик и интегрированную возможность развёртывания ПО на целевой платформе.
Интересно, заметили ли вы, что в этом драйвере есть ошибка. Она заключается в том, что функция вычисления синуса в действительности использует в качестве входного значения угла радианы, а не градусы.
Использование заглушек для зависимых функций
Построение замещений для зависимых функций необходимо, когда вы хотите контролировать значения, возвращаемые зависимой функцией в процессе теста. Использование заглушек является важной частью интеграционного и модульного тестирования, так как позволяет изолировать тестируемый код от других частей приложения и проще выполнить тестирование интересующей подсистемы.
Многие инструменты требуют ручного создания тестового кода для выполнения заглушкой чего-либо более сложного за исключением возвращения статичной скалярной величины (return0;)
Тестовые данные
Существуют два основных подхода, используемых полу-автоматизированными и автоматизированными инструментами при реализации тестового сценария. Первый – это архитектура управляемая данными, второй – архитектура единичного теста.
Для управляемой данными архитектуры тестовая программа создается для всех тестируемых модулей и поддерживает все функции, определенные в этих модулях. При прогоне теста инструмент снабжает данными информационный поток, такой как файловый дескриптор или физический интерфейс, например, UART.
Для архитектуры единичного теста каждый раз во время прогона теста инструмент создает тест-драйвер и компилирует его в исполняемую программу. Важно отметить пару моментов; во-первых, создание дополнительного кода, требуемого при единичном тесте, а также последующая компиляция займет больше времени при выполнении теста; во-вторых, в итоге вы создаете отдельные тестовые программы для каждого тестового сценария.
Это значит, что оцениваемый инструмент может нормально работать для определенных номинальных сценариев и работать некорректно для более сложных тестов.
Автоматизированное создание тестовых данных
Разные автоматизированные инструменты обеспечивают определенную степень автоматизации создания тестового сценария. Для этого используются разные подходы, некоторые из них приведены ниже в таблице:
- (МММ) Мин-сред-макc тестовые сценарии — МММ тесты проверяют функции на пограничные значения типов входных данных. Код на языках программирования С и С++ часто не защищает себя от входных данных вне допустимого диапазона.
- (EC) Классы эквивалентности — ЕС тесты заключаются в следующем: данные разбиваются на классы эквивалентности, по принципу что программа ведет себя одинаково с каждым представителем отдельного класса. Таким образом проверяются не все возможные данные, а отдельные представители класса.
- (RV) Случайные величины — RV тесты задают сочетания случайных значений для каждого параметра функции.
- (BP) Тесты по веткам условных операторов — BP тесты могут автоматически создавать покрытие высокого уровня по веткам условных операторов.
Размышляя об автоматизированном создании тестовых сценариев, важно помнить, какой цели они служат. Автоматизированные тесты хороши для оценки робастности (надёжности) кода приложения, но не корректности (даже если они обеспечивают высокий уровень покрытия кода). Для корректности вы должны создать тесты, основанные на том, что ожидают от приложения (требования), а не что оно делает (код).
Интеграция компилятора
У интеграции компилятора двоякий смысл. С одной стороны интеграция позволяет автоматически построить компоненты тестовой программы без необходимости ввода параметров компилятора пользователем. С другой стороны интеграция позволяет инструменту тестирования принимать на обработку любые расширения языка, специфические для используемого компилятора. Распространённой является практика, что кросс-компиляторы поддерживают расширения, которые не являются частью стандартов языков программирования С/С++. Некоторые инструменты определяют такие расширения как пустую строку. Это очень грубый подход и главный его минус в том, что он меняет объектный код, создаваемый компилятором. Например, рассмотрим следующую глобальную внешнюю переменную с GCC атрибутом:
extern int MyGlobal __attribute__ ((aligned (16)));
Если рассматриваемый инструмент не поддерживает атрибут при определении глобального объекта MyGlobal, то код будет по-разному вести себя в процессе тестирования и в рабочем состоянии, так как выравнивание не будет одинаковым.
Поддержка тестирования на целевой платформе
В данном разделе мы будем использовать термин «набор инструментов» применительно к среде разработки включая кросс-компилятор, отладочный интерфейс (эмулятор), целевую платформу и операционную систему реального времени (RTOS). Важно выяснить, имеет ли рассматриваемый инструмент отличную интеграцию с вашим набором инструментов и понять, что нужно изменить в инструменте для миграции на другой набор инструментов.
Также важно выяснить уровень автоматизации и надежности интеграции с целевой платформой. Как уже упоминалось ранее, если поставщик говорит: «Мы поддерживаем все компиляторы и целевые платформы», это означает только одно: «Вам придется сделать всю работу, чтобы наш инструмент работал в вашей рабочей среде».
В идеале инструмент, который вы выбрали, должен выполнять тестирование по «одному нажатию кнопки», а все сложности загрузки ПО на целевую платформу и сбор результатов тестов на рабочей машине скрыты за сообщением «Идёт выполнение теста», так что от пользователя не потребуется особых действий.
Дополнительной сложностью тестирования на целевой платформе является вопрос о доступности аппаратных средств. Часто аппаратное обеспечение разрабатывается параллельно с программным обеспечением или имеет место ограничение доступа к аппаратным средствам. Важным моментом является возможность начать тестирование в собственной среде и позднее осуществить переход на реальную целевую платформу. В идеале артефакты инструмента тестирования должны быть независимыми от аппаратного обеспечения.
Редактор тестового сценария
Очевидно, что именно в редакторе тестового сценария вы будете проводить большую часть времени при использовании инструмента тестирования. Если инструмент действительно поддерживает автоматизацию перечисленных пунктов, упомянутых выше, тогда количество времени, затраченного на настройку тестовой среды и связи с целевой платформы будет минимально. Помните о том, что мы говорили в начале – наша цель заключается в том, чтобы инженеры использовали свое время для создания все более совершенных и более полных тестов.
Важный вопрос, на который нужно ответить при оценке – насколько сложно установить тестовые входные данные и ожидаемые значения для нетривиальных конструкций. Существующие на рынке инструменты обеспечивают достаточно простой способ установки скалярных величин. Например, оснащен ли оцениваемый инструмент простым и интуитивно-понятным способом конструирования классов? А как насчет настройки STL контейнера, такого как vector или map. Такие нюансы и необходимо оценивать в редакторе тестового сценария.
Покрытие кода
Большинство полу-автоматизированных и все автоматизированные инструменты тестирования содержат встроенное средство покрытия кода, позволяющее вам увидеть метрики, которые показывают количество кода ПО, выполняемого при запуске ваших тестовых сценариев. Некоторые инструменты предоставляют эту информацию в табличной форме. Другие выдают потоковый граф, а некоторые выдают снабженный комментариями листинг исходного кода. Хотя таблица и является хорошим представлением сводной информации, но если вы пытаетесь добиться 100% покрытия кода, снабженный комментариями листинг – лучший способ. Такой листинг показывает файл исходного кода с окрашиванием для покрытых, частично покрытых и непокрытых конструкций. Это позволяет легко увидеть, какие дополнительные тестовые сценарии нужны для 100% покрытия.
Также важно оценить влияние инструментария, так как к вашему ПО добавляется дополнительный исходный код. Есть два момента, которые необходимо учитывать: один – увеличение размера объектного кода, второй – дополнительные затраты во время выполнения программы. Важно понимать, имеет ли ваше ПО ограничения по памяти или по времени выполнения программы (или и то и другое). Это поможет сконцентрировать внимание на том, что для вашего ПО более важно.
Регрессионное тестирование
При выборе инструмента тестирования, мы должны помнить о двух основных целях. Первая цель – экономия времени тестирования. Если вы дочитали до этих слов, значит, вы согласны с нами. Вторая цель – обеспечить эффективное использование созданных тестов в течение жизненного цикла ПО. Это означает, что время и деньги, вложенные в создание тестов, должны дать в результате возможность многоразового использования тестов (при изменениях ПО в течение времени) и должны обеспечить легкость конфигурационного управления этими тестами. Главное оценить в интересующем вас инструменте, какие отдельные сущности должны быть сохранены для прохождения этих же тестов в будущем, и каким образом контролируется повторный запуск.
Составление отчетов
Большинство инструментов обеспечивают функцию составления отчетов сходным образом. Как минимум, они должны создавать простой для понимания отчет, демонстрирующий входные данные, ожидаемые выходные данные, фактические выходные данные и сравнение ожидаемых и фактических величин.
Интеграция с другими инструментами
Независимо от качества или практической пользы любого отдельного инструмента, все инструменты должны функционировать в среде, объединяющей системы разных производителей. Большие компании затратили огромное количество времени и денег, покупая маленькие компании, разработавшие инструмент, выполняющий «всё для всех». Для этих мега наборов инструментов характерно, что «общая сумма меньше, чем сумма частей». Компании часто взяв 4-5 небольших, но дельных инструмента, интегрируют их в один громоздкий и непригодный к эксплуатации инструмент.
Помимо интеграции с набором инструментов, которую мы уже рассмотрели, самыми полезными видами интеграции для инструментов тестирования является интеграция с инструментами статического анализа, конфигурационного управления и управления требованиями. Все хотят держать артефакты инструмента тестирования в системе управления конфигурацией (для их многократного использования), и большинство людей хотели бы трассировать требования на тестовые сценария.
Дополнительные желаемые характеристики инструмента тестирования
Мы закончили обзор раздела «Анализ инструментов тестирования». Предыдущие разделы описывали функциональное наполнение, которое есть в любом инструменте, считающимся автоматизированным. В следующих разделах мы перечислим некоторые желаемые (и менее распространенные) характеристики, одновременно аргументируя важность этих характеристик. Эти характеристики могут иметь различные уровни применимости к вашему проекту.
Истинное интеграционное тестирование/Многомодульное тестирование
Интеграционное тестирование является продолжением модульного тестирования. Оно используется для проверки интерфейсов между модулями и требует от вас объединения модулей, которые выполняют определенный функциональный процесс. Многие инструменты заявлены как поддерживающие интеграционное тестирование путем связывания объектного кода для реальных модулей с помощью тестовой программы. Этот метод конструирует множество файлов внутри выполняемой тестовой программы, но не обеспечивает возможности активизировать функции внутри этих дополнительных модулей. В идеале вы должны иметь возможность активизировать любую функцию в любом модуле в любом порядке в рамках одного тестового сценария. Тестирование интерфейсов между модулями в целом раскроет множество скрытых допущений и ошибок в ПО. Фактически интеграционное тестирование может быть первым шагом для проектов, у которых нет истории модульного тестирования.
Использование динамических заглушек
Создание динамических заглушек означает возможность динамического включения и отключения собственных функций заглушек. Это позволяет создавать тест для отдельной функции, заглушив все остальные функции (даже если они существуют в том же модуле, что и тестируемая функция). Для очень сложного кода это важнейшая характеристика, существенно упрощающая выполнение тестирования.
Тестирование на уровне библиотеки и приложения
Одной из сложных проблем в системном тестировании является то, что тестовое воздействие, направленное на полностью интегрированное ПО может потребовать от пользователя нажатия на кнопки и переключатели или печати на консоли. Если приложение встроенное, входные данные будет еще сложнее контролировать. Допустим вы можете подавать внешние воздействия на функциональном уровне, схожим с интеграционным тестированием образом. Это позволит вам построить совокупность тестовых сценариев, опирающуюся только на API ПО.
Некоторые из наиболее современных инструментов позволяют вам проводить тестирование таким образом. Дополнительным преимуществом этого режима тестирования является отсутствие потребности в исходном коде для тестирования приложения. Вам всего лишь нужно определение API (как правило, заголовочные файлы). Эта методология дает испытателю автоматизированный и скриптовый способ выполнения системного тестирования.
Agile-тестирование и разработка посредством тестирования (TDD)
Разработка посредством тестирования подразумевает следующее: вместо того чтобы сначала написать код приложения и во вторую очередь протестировать модуль, вы создаете сначала тесты до написания кода приложения. Это новый популярный подход к разработке – разрабатывать сначала тест. Ваш автоматизированный инструмент должен поддерживать этот метод тестирования, если вы планируете использовать методологию гибкой разработки.
Двунаправленная интеграция с инструментами управления требованиями
Если вас заботит связывание требований с тестовыми сценариями, тогда желательна интеграция инструмента тестирования с инструментом управления требованиями. Если вас интересует эта характеристика, важно отметить двунаправленность интерфейса; когда требования помечены в тестовых сценариях, информация тестового сценария, как, например, имя теста и статус прохождения/отказа, переносятся в базу данных требований. Это позволяет вам получить чувство завершенности тестирования требований.
Квалификация инструмента
Если вы работаете в регулируемой среде, такой как гражданская авиация или изготовление медицинских приборов класса III, тогда вы обязаны квалифицировать средства разработки, используемые для построения и тестирования вашего приложения.
Квалификация подразумевает документирование назначения инструмента (его эксплуатационные требования) и результаты тестов, доказывающие, что инструмент работает в соответствии с этими требованиями. В идеале поставщик должен иметь эти материалы в готовом виде, а также историю покупателей, использовавших квалификационные данные в своей отрасли деятельности.
Заключение
Помните, что практически каждый инструмент тестирования встроенного ПО тем или иным образом поддерживает пункты, упомянутые в ключевых моментах. Важно понимать насколько он автоматизирован, прост в использовании и оценить полноценность поддержки.
Автор: cmex
