Часть I. Процесс быстрого тестирования. программного продукта и начальное состояние системы должны быть определены

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

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

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

Документ проектов тестов

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

Таблица 4.1. Пример записи в проектном документе тестов

Эта таблица в какой-то степени похожа на матрицу RTM (Requirement Traceability matrix — матрица прослеживаемости требований), которая рассматривалась в главе 2 (см. рис. 2.5). Два первых столбца таблицы должны соответствовать вхождениям в матрицу RTM, остальные столбцы соответствуют данным, описанным в трех преды­ дущих разделах данной главы.

Как только проектный документ тестов будет готов, его нужно проверить в кон­ тексте связанных с ним материалов: документа определения требований (техниче-

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

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

• Что каждый тестовый случай поддерживается соответствующими входными данными.

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

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