4.4.6. Генераторы тестов

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

Различают следующие способы генерации тестовых примеров:

• по формализованным требованиям;

• случайным образом;

• по программному коду.

Первый способ генерации тестовых примеров приемлем для тестирования системы как «черного ящика», но требует чтобы тест-требования (или системные/функциональные требования) были подготовлены на специальном формальном языке оформления требований, например RDL (Requirements Definition Language). Затем по требованиям строятся тестовые примеры, которые проверяют функциональность системы с точки зрения требований, т.е. в этом случае достигается основная цель верификации – проверить, ведет ли себя система в соответствии с требованиями.

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

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

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

4.5. Отчеты о прохождении тестов

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

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

По результатам анализа отчетов о прохождении тестов могут быть выявлены либо дефекты в самой системе, либо некорректно составленные или противоречивые требования. В обоих случаях результаты анализа служат основой для создания запросов на изменение требований и/или кода системы. После корректного исправления дефектов при регрессионном тестировании неуспешно выполненные тестовые примеры должны выполниться успешно (Рис. 19).

Рис. 19 Генерация отчета о прохождении тестов и изменения по результатам его анализа

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