![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Часть I. Процесс быстрого тестирования. тирования. Некоторые организации, специализирующиеся на тестировании про граммных продуктов, объединяют один или большее число пунктов списка с содер жимым
тирования. Некоторые организации, специализирующиеся на тестировании про граммных продуктов, объединяют один или большее число пунктов списка с содер жимым плана проведения испытаний, тем самым организуя всю тестовую документа цию в одном месте. Это может дать прекрасные результаты, однако в данной книге мы преследуем цель достижения большей модульности комплекта документов, кото рая совпадает с целью упомянутого выше стандарта.
Тот факт, что указанный стандарт направлен на разделение планов проведения испытаний, процедур и результатов, становится очевидным из содержащихся в нем определений следующих документов [22].
План проведения испытаний. Это документ описывает возможности, подход, ресурсы и график исполнения различных видов тестовой деятельности. Он опреде ляет объекты тестирования, функции, которые должны тестироваться, тестовые задания, исполнителей каждого тестового задания, и любой из рисков, требую щий планирования на случай непредвиденных обстоятельств.
Спецификация методики тестирования. Этот документ описывает последовательность действий при выполнении конкретного теста.
Отчетный доклад о тестировании. Этот документ обобщает виды тестовой деятельности и их результаты. Он также содержит оценку соответствующих тестовых объектов.
Спецификация методики тестирования изучается в главе 4 как часть работ, вы полняемых при разработке тестов, а отчетные доклады о тестировании рассматри ваются в главе 5, в которой речь идет о выполнении тестов. В идеальном случае все эти документы должны быть связаны в эффективную, скоординированную систему, которая поддерживает процесс тестирования от начала до конца.
В данном разделе мы проведем анализ содержимого плана проведения испытаний
и оптимизацию его структуры для целей быстрого тестирования. По каждому пункту этого плана мы попытаемся найти приемлемый способ быстро и эффективно удовле творить его требования. Разумеется, некоторые предложенные решения не будут со ответствовать вашим потребностям, но тогда вы должны будете выполнить такой же анализ в контексте собственной среды разработки.
Каждый пронумерованный ниже пункт соответствует пункту эскиза плана, приве денного в предыдущем разделе. Примеры плана проведения испытаний, специфика ции методики тестирования и отчета о тестировании приводятся в третьей части книги.
1. Идентификатор плана проведения испытаний. В долгосрочной перспективеможно сэкономить время, если присвоить всем тестовым документам идентификато ры, которые нетрудно отслеживать. По существу, возможность отслеживания доку ментов позволяет получить следующие преимущества: • Наличие уникального идентификатора каждого тестового документа позволяет воспрепятствовать тому, что кто-либо из исполнителей напрасно затратит вре мя на изучение не того документа, что надо. Таким идентификатором может быть алфавитно-цифровая строка, которая может содержать данные, отобра жающие название продукта, номер версии, дату и любую другую информацию, позволяющую отслеживать этот документ. Рекомендуется отдавать предпочте-
ние идентификаторам, которые вписываются в общую систему управления до кументов.
• Построить хранилище документов (возможно, сетевой дисковый накопитель), которое позволяет исполнителям и руководству быстро находить документы, имеющие отношение к тестированию. Если во время очередного кризиса вам придется отыскивать нужную версию того или иного документа, вы убедитесь, насколько полезным является подобное хранилище документов.
• Построить систему отслеживания документов, поддерживающую управление версиями. В любой момент может возникнуть необходимость внести измене ния в тестовые документы, в том числе планы проведения тестирования. Вы должны иметь возможность донести до исполнителей и руководства последние изменения. Управление версиями может быть таким же простым, как докумен тирование статистических данных на титульном листе документа и поддержа ние актуальной версии, помещенной в хранилище документов.
2. Введение. Цель введения заключается в том, чтобы дать краткую информацию длялюбого исполнителя, желающего воспользоваться планом проведения испытаний. Суть состоит в необходимости указания во вводном разделе плана проведения испы таний исходных документов, служащих входными данными выполняемого тести рования.
Например, можно составить список документов с требованиями и функциональ ных спецификаций для тестируемого программного продукта. При составлении это го списка желательно указать расположения документов (путь в сетевом дисковом накопителе или URL-адрес Web-страницы), что даст возможность быстро получить к ним доступ. Наиболее подходящий способ заключается в помещении в план проведе ния испытаний ссылки на исходный документ, благодаря которой пользователь смо жет переходить из недокументальной копии плана на соответствующие справочные материалы. Преимущество такого подхода связано с возможностью автоматического выхода пользователя на последнюю версию входного документа.
Другим аспектом, который совершенно не связан с обеспечением быстрого поис ка входных документов, является минимизация временных затрат на написание вве дения. Пример, сопровождающий стандарт IEEE Standard 829, содержит цели плана проведения испытаний, предварительные данные о программном продукте, объем тестирования, предусмотренный планом проведения испытаний, и перечень ссылок. Размер такого документа не превышает половины страницы. Если при этом имеются ограничения, оказывающие влияние на процесс планирования, например, срок вы хода продукта на рынок, их можно перечислить здесь же.
3. Компоненты, которые должны тестироваться. Здесь приводятся высокоуровневые списки компонент, которые вы намерены тестировать. В этом разделе будут упо мянуты некоторые из них:
• Идентификатор выпуска/версии тестируемого программного проекта
• Исправления дефектов, обнаруженных в предыдущей версии. Если список де фектов приводится в спецификации функций, необходимо указать ссылку на спецификации функций и не дублировать их здесь
|