|
Выберите рабочие продукты и способ их применения. Помимо этого, обязательно адаптируйте каждый продукт к
особенностям проекта.
В следующей таблице перечислены рабочие продукты тестирования. Эти продукты разделены на рекомендуемые и необязательные
(которые можно использовать только в определенных случаях). Дополнительные замечания по адаптации рабочих
продуктов приведены в разделе об адаптации на странице описания конкретного продукта.
|
Рабочий продукт
|
Назначение
|
Адаптация (Необязательный продукт, рекомендуется)
|
|
Сводка тестового вычисления
|
Обобщает результаты тестирования в первую очередь для использования руководителями проекта и другими
заинтересованными лицами, не входящими в коллектив испытателей.
|
Рекомендуется для большинства проектов.
Если это позволяет специфика проекта, можно просто вести записи результатов тестирования и не
создавать официальные сводки тестовых вычислений. Другими словами, сводки тестовых вычислений могут
быть частью документации по оценке рабочих продуктов. В эту документацию также может входить Оценка итерации или Проверка записи.
|
|
Результаты тестирования
|
Этот рабочий продукт содержит результаты анализа необработанных данных из одного или нескольких
протоколов тестирования.
|
Рекомендуется. У каждой группы испытателей сохраняются более-менее детальные записи о результатах
тестирования. Результаты тестирования, выполненного вручную, записываются прямо в этот рабочий продукт
и дополняются отобранными протоколами автоматизированного тестирования.
В некоторых случаях испытатели сразу переходят от протоколов тестирования к составлению сводки
тестового вычисления.
|
|
Протокол тестирования
|
Вывод необработанных данных, полученных в результате тестирования. Обычно составляется при
автоматизированном тестировании.
|
Необязательный продукт.
При автоматизированном тестировании многих проектов составляются протоколы тестирования. В
некоторых проектах эти протоколы сохраняются, в некоторых - уничтожаются после получения
результатов.
Протоколы сохраняются для следующих целей: если их данные требуются для составления отчетов, если
проводится анализ изменения необработанных данных, полученных при последовательных этапах
тестирования, или если еще не определены рамки общего анализа.
|
|
Набор тестирования
|
Используется для объединения отдельных связанных тестов (тестовых сценариев) в тематические наборы.
|
Рекомендуется для большинства проектов.
Также требуется для определения последовательности выполнения тестовых сценариев, необходимой для
правильного хода теста.
|
|
Список идей тестирования
|
Список идей, нередко сформулированных частично, которые нужно принимать во внимание при тестировании.
|
Рекомендуется для большинства проектов.
В некоторых случаях такой список составляют неформально, а затем на его основе создают тестовые
сценарии или тестовые наборы. После этого список удаляют.
|
|
Стратегия тестирования
|
Содержит план распределения трудозатрат при тестировании той или иной части целевой системы.
|
Рекомендуется для большинства проектов.
В большинстве случаев рекомендуется создавать общие стратеги для каждого продукта или для каждой фазы
разработки продукта. При необходимости, если уже использованные стратегии подходят для данного случая,
их можно использовать повторна. Стратегии можно также разделять на более мелкие по типу тестирования.
|
|
План тестирования
|
Содержит структуру целей, задач, мотиваций, подходов, ресурсов, а также список рабочих продуктов и план
для отдельной итерации.
|
Рекомендуется для большинства проектов.
Для каждой итерации рекомендуется создавать общий план тестирования. Это поможет в разработке четкой
стратегии этой итерации. При необходимости план тестирования можно добавить к Плану итерации.
|
|
План тестирования
|
Содержит основные цели тестирования, его задачи, подходы, ресурсы, а также список рабочих продуктов и
план для отдельного этапа или всего жизненного цикла.
|
Необязательный продукт. Рекомендуется для большинства проектов.
Генеральный план тестирования определяет общую стратегию распределения трудозатрат при тестировании
крупных частей цикла разработки программного обеспечения. При необходимости план тестирования можно
добавить к Плану разработки программного обеспечения.
Решите, нужно ли в дополнение к планам тестирования для отдельных итераций составлять генеральный план
тестирования. Генеральный план тестирования в основном содержит данные логистики и принципы процесса
тестирования. Эта информация обычно относится к жизненному циклу в целом и поэтому редко меняется между
итерациями.
|
|
Тестовые сценарии, Тестовые данные
|
Тестовые сценарии и тестовые данные содержат информацию о реализации теста. В тестовых сценариях
перечислены процедурные аспекты, а в тестовых данных указаны определяющие характеристики.
|
Рекомендуется для большинства проектов.
В разных проектах эти продукты работы получают разный статус. В некоторых случаях они носят
неформальный и временный характер, и группы тестирования опираются в своей работе на другие данные. В
других случаях, особенно при автоматизированном тестировании, тестовые сценарии и связанные тестовые
данные (или их часть) входят в список обязательных продуктов тестирования.
|
|
Тестовый набор
|
Содержит набор входных данных, условий выполнения и ожидаемых результатов.
Создание тестовых наборов позволяет следить за их полнотой и правильностью. Данные из тестовых
наборов можно использовать при планировании и применении трудозатрат на реализацию.
Тестовые наборы особенно пригождаются при высокой сложности входных данных, условий выполнения и
ожидаемых результатов.
|
Тестовые наборы рекомендуется создавать в большинстве проектов, где условия проведения отдельных
тестов сложны или объемны. Тестовые наборы также необходимо создавать, если по контракту они входят
в список обязательных продуктов.
В большинстве других случаев вместо подробных текстуальных тестовых наборов рекомендуется создавать
список идей тестирования и реализованные тестовые сценарии.
В некоторых проектах тестовые наборы содержат общие данные, а детали изложены в тестовых сценариях.
Другой часто применяемый способ - излагать данные тестового набора в виде комментариев к тестовым
сценариям.
|
|
Модель анализа нагрузки
|
Представляет собой тип тестового набора. Используется для определения данных о средней нагрузке. На
основе этих данных производится оценка рисков для качества, связанных с работой системы при
нагрузке.
|
Рекомендуется для большинства систем, особенно если нужно оценить производительность системы при
нагрузке или если существует значительная угроза качеству, связанная с работой системы при
нагрузке.
Обычно не требуется в системах, которые будут развернуты в автономной целевой системе.
|
|
Классы пригодности к тестированию в модели
проекта
Элементы пригодности к тестированию в модели
реализации
|
Если для поддержки тестирования в проект необходимо добавить дополнительные специальные функции,
добавьте в модель проекта классы пригодности к тестированию, а в модель реализации - элементы
пригодности к тестированию.
|
При необходимости.
Заготовки - это общая категория классов тестирования и
компонентов теста.
|
|
Архитектура автоматизации тестирования
|
Содержит архитектурный обзор системы автоматизации с использованием ряда архитектурных
представлений для отражения различных аспектов системы.
|
Необязательный продукт.
Рекомендуется для проектов со сравнительно сложной архитектурой тестирования, если для компоновки
автоматизированных тестов будет задействована большая группа специалистов или если предполагается,
что система автоматизации тестирования будет применяться длительное время.
Иногда архитектура автоматизации тестирования представлена в виде простой диаграммы, доступной для
всех специалистов.
|
|
Спецификация интерфейса тестирования
|
Определяет необходимые функции классификатора (в частности, класса, подсистемы или компонента) для
целей тестирования. Часто встречаются следующие функции: доступ к тесту, функции имитатора, ведение
протоколов диагностики и прогнозирование результатов теста.
|
Необязательный продукт.
Во многих проектах обычно открыт доступ к видимым операциям над классами, пользовательскими
интерфейсами и т.д.
Обычно спецификации интерфейсов тестирования создаются для того, чтобы расширения пользовательских
интерфейсов позволяли инструментам тестирования GUI взаимодействовать с процедурами инструментов и
протоколами диагностических сообщений, особенно в пакетных процессах.
|
В этом разделе приведены рекомендации по выбору способа проверки рабочих продуктов тестирования. Общие указания
приведены в разделе Рекомендация:
Уровни проверки.
Неисправности
Характер проверок на наличие неисправностей зависит от контекста, однако обычно такие проверки бывают
неофициальными, официальными-внутренними или официальными-внешними. Обычно эти проверки
инициируются или, по крайней мере, сопровождаются процессом управления операциями в системе отслеживания
неисправностей. В общем случае уровень формальности проверки определяется серьезностью или последствиями обнаруженной
неисправности. Однако на характер проверки нередко влияет специфика проекта и уровень формальности.
В некоторых случаях стоит отделить устранение неисправностей (также известных как симптомы или сбои) от недоработок -
истинных источников ошибок. В небольших проектах нередко отслеживают только неисправности и попутно устраняют
недоработки. Однако по мере усложнения системы возможно стоит отделить устранение неисправностей от исправления
недоработок. Например, причиной нескольких неисправностей может быть одна и та же недоработка. Поэтому после
исправления недоработки нужно найти все вызванные ей неисправности. Затем нужно уведомить пользователей, обнаруживших
эти неисправности, что недоработка устранена. Это можно сделать только если неисправности и недоработки отслеживаются
отдельно друг от друга.
План тестирования и стратегия тестирования
В любом проекте со сложной структурой тестирования необходимо создать план или стратегию тестирования. В общем случае
нужно создать план тестирования для каждой итерации и общую стратегию тестирования. При необходимости можно составить
генеральный план тестирования. Нередко эти рабочие продукты рассматриваются как неофициальные. Это значит, что
их проверяют, но не утверждают официально. Если информация о тестировании необходима для заинтересованных лиц помимо
испытателей, эти продукты нужно рассматривать как официальные-внутренние или даже официальные-внешние.
Тестовые сценарии
Тестовые сценарии обычно рассматриваются как неформальные. Это значит, что они утверждаются специалистами из
группы тестирования. Тестовые сценарии считаются формальными-внутренними, если их используют многие специалисты
из группы тестирования, либо если эти сценарии применяются повторно или в нескольких разных тестах.
Тестовые наборы
Тестовые наборы создаются группой испытателей и, в зависимости от ситуации, проверяются как неофициальные или
вообще не проверяются. При необходимости тестовые наборы утверждаются другими специалистами из группы проекта (и
рассматриваются как официальные-внутренние) или внешними заинтересованными лицами (и рассматриваются как
официальные-внешние).
Рекомендуется заранее составить список тестовых наборов для официальной проверки. Обычно этот список содержит небольшое
количество самых важных тестовых наборов. Например, если заказчик планирует провести оценку продукта до его выпуска,
список тестовых наборов может служить основой для этой оценки. Такие тестовые наборы рассматриваются как
официальные-внешние.
Рабочие продукты тестирования в проектировании и реализации
Классы пригодности к тестированию расположены в модели проекта, а элементы пригодности к тестированию - в модели
реализации. Также существуют два других связанных (но не относящихся к тестированию) рабочих продукта. Это пакеты в
модели проекта и подсистемы в модели реализации.
Эти рабочие продукты относятся к проектированию и реализации, но создаются специально для поддержки тестирования
продукта. Естественное место их хранения - вместе с рабочими продуктами проектирования и реализации. Обязательно
назовите или иным образом выделите их, чтобы их можно было легко отличить от других рабочих продуктов проектирования и
реализации основной системы. Для проверки этих продуктов используйте те же процедуры, что и для проверки остальных
рабочих продуктов проектирования и реализации.
Перед началом каждой итерации старайтесь четко определить, как будет оцениваться очередной тест и каковы критерии его
успешности. Обсудите эти вопросы с экспертом или группой специалистов, ответственных за утверждение теста.
Ниже перечислены возможные способы утверждения итерации:
-
Участники проекта утверждают итерацию и оценивают процедуру тестирования, проверяя сводки тестовых вычислений.
-
Заказчик утверждает итерацию, проверяя сводки тестовых вычислений.
-
Заказчик утверждает итерацию, основываясь на результатах выполнения набора тестов, выбранных из общего списка
тестов. Этот набор тестов нужно определить заранее, желательно, в начале итерации. Эти тесты рассматриваются как
формальные-внешние и часто называются тестами приемки.
-
Заказчик утверждает уровень качества системы на основании результатов собственных независимых тестов. Специфику
этих тестов следует также четко определить заранее, желательно, в начале итерации. Эти тесты рассматриваются как
формальные-внешние и часто называются тестами приемки.
Это важное решение. Выбор критериев утверждения итераций обязателен для успешного выполнения проекта.
|
