![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Часть I. Процесс быстрого тестирования. программного продукта и начальное состояние системы должны быть определены
программного продукта и начальное состояние системы должны быть определены. Как отмечалось в главе 3, работа по составлению плана проведения испытаний долж на предусматривать анализ различных вариантов конфигурации средств тестирова ния и выбор из них конфигураций, пригодных для системных испытаний.
Задача заключается в том, чтобы на стадии проектирования конкретного теста выбрать одну или несколько конфигураций, которые можно использовать для дости жения целей этого теста. Зачастую один и тот же тест нужно выполнить на некото ром множестве конфигураций, чтобы смоделировать различные рабочие условия заказчика. Например, крупный заказчик может использовать преимущественно стан дартные конфигурации операционной системы, процессора, накопителя на жестких дисках, сетевой операционной системы и оперативной памяти — такую конфигура цию можно смоделировать в лабораторных условиях с высокой степенью точности.
Один из способов отслеживания конфигураций предусматривает их описание в плане проведения испытаний с присвоением каждой конфигурации уникальных идентификаторов. В таком случае в плане проведения испытаний гораздо проще ссылаться на одну или несколько избранных конфигураций.
Документ проектов тестов
Назначение документа проектов тестов состоит в том, чтобы собрать в одном месте всю информацию, порожденную в результате различных видов тестовой деятельно сти. Документ проектов тестов может быть представлен в виде электронной таблицы, в виде таблицы текстового процессора или в виде базы данных. Если вы пользуетесь инструментальным средством автоматизированного управления требованиями, его можно применить для сбора информации о проекте теста. Пример записи в докумен те проектов тестов показан в таблице 4.1.
Таблица 4.1. Пример записи в проектном документе тестов
Эта таблица в какой-то степени похожа на матрицу RTM (Requirement Traceability matrix — матрица прослеживаемости требований), которая рассматривалась в главе 2 (см. рис. 2.5). Два первых столбца таблицы должны соответствовать вхождениям в матрицу RTM, остальные столбцы соответствуют данным, описанным в трех преды дущих разделах данной главы.
Как только проектный документ тестов будет готов, его нужно проверить в кон тексте связанных с ним материалов: документа определения требований (техниче-
ского задания), определения входных данных теста и конфигурации средств тести рования. Цели такой проверки связаны с необходимостью убедиться:
• Что рассматриваемым документом проектов тестов были охвачены все техни ческие требования. Если то или иное требование не тестируется, в матрице RTM или в документе проектов тестов должна присутствовать запись, пояс няющая, почему соответствующее требование не покрывается тестом.
• Что каждый тестовый случай поддерживается соответствующими входными данными.
• Что для каждого тестового случая имеется подходящая конфигурация, причем эти конфигурации не являются избыточными.
Документ проектов тестов служит основой для разработки детальной методики тестирования. В результате его пересмотра тесты могут распределяться среди испол нителей группы тестирования для дальнейшей детализации.
|