Примеры проектирования и разработки тестов

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

• Проектирование тестов

• Разработка детализованных тестовых процедур

• Верификация и отладка тестовых процедур.

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

и в автоматическом режимах; реально получается так, что сначала лучше разработать

и отладить процедуры вручную, а затем добавить возможности автоматизации.

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

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

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

• Определение целей тестирования

• Определение входных данных, необходимых для прогона каждого теста

• Определение конфигурации, необходимой для каждого теста

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

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

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

> На системные испытания

Рис. 15.1. Проектирование и реализация тестов

Процесс проектирования тестов в рассматриваемом примере тесно завязан на формат, определенный в главе 4, который для удобства приводится на рис. 15.2.

Рассматриваемая в данной главе таблица имеет сходство с матрицей прослежи-ваемости требований (Requirements Traceability Matrix, RTM), которая обсуждалась в

330 Часть III. Процесс быстрого тестирования

главе 2 (см. рис. 2.5). Первые два столбца таблицы должны соответствовать записям в RTM-матрице, а остальные столбцы связаны с данными, которые рассматривались в предыдущих трех разделах этой главы. Из-за подобия таблиц разработок и RTM-матрицы пример самой матрицы не приводится.

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

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

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

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

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

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

Рис. 15.2. Пример записи в документе с проектами тестов

Детализованные тестовые процедуры, рассматриваемые в примере, записаны в виде пар " действие/ожидаемый результат". Это означает, что тестировщик должен выполнять определенные действия, такие, например, как щелчок на элементе меню и сравнение результата этого действия с ожидаемым. Если ожидаемый результат полу­ чен, тест считается пройденным; в противном случае результат прогона теста рас­ сматривается как неудачный.

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

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

Основными элементами шаблона тестового случая являются:

• Идентификатор тестового случая — включает номер версии.

• Владелец теста — имя и фамилия того, кто поддерживает тест (это не всегда ав­ тор теста).

• Дата создания последней версии — помогает уточнить, является ли версия теста актуальной.

• Имя теста — описательное название теста, которое упрощает его поиск и пони­ мание его содержания. Не рекомендуется использовать имена, не имеющие смысловой нагрузки, наподобие " xxxLLL0123.tst".

• Расположение теста — полный путь, включая имя сервера.

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

• Цель тестирования — краткое и ясное изложение цели, которая достигается данным тестом. Более подробную информацию можно найти в разделе " Опре­ деление целей теста" главы 4).

• Конфигурация теста — спецификации входных и выходных данных, а также описание среды тестирования.

• Установка теста — по аналогии с процедурой тестирования, описываются дей­ ствия, которые должен выполнять тестировщик, и ожидаемые результаты. Ес­ ли процесс установки автоматизирован, то сама установка может принимать форму единственной команды, например, run setupSC03. pi.

• Процедура тестирования — описание действий, которые должен выполнить тестировщик, и ожидаемый результатов.

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

• Очистка теста — если система переводится в нестабильное состояние или же ей передаются преднамеренно запорченные данные, то при помощи очистки можно выполнить откат.

Примечания:

- Тест потерпел неудачу на шаге 3.

- При возникновении неисправности выдается код ошибки BR1011.

Рис. 15.3. Пример тестового случая

Спецификация тестовой процедуры ТМТ TMT-TPS-10

Идентификатор документа: TMT-TPS-10

Версия: 0.5

Авторы: Крис Браун (Chris Brown)Джеймс Барнс (James Barnes)

Набор инструментальных средств управления тестированием

Версия 1.0