![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Примеры проектирования и разработки тестов
В главе 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
|