Рекомендация: План тестирования

Обзор

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

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

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

Следующие рекомендации помогают подготовить и сформулировать требования для теста, риски, приоритеты и стратегии теста.

Подготовка требований для теста

Требования для теста указывают, что будет тестироваться. Они относятся к конкретной цели теста. При подготовке требований придерживайтесь следующих общих правил:

Требование должно относиться к наблюдаемой и измеряемой величине. Если требование относится к величине, которую нельзя наблюдать или измерить, то невозможно будет определить, выполнено ли требование.
Требования варианта использования или вспомогательные требования не связаны однозначно с требованиями для теста. Часто варианты использования представляют более одного требования для теста, а вспомогательные требования могут представить одно требование, несколько требований или вообще ни одного (например, требования, относящиеся к маркетингу или созданию пакетов).

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

Требования для функциональных тестов

Функциональные требования создаются на основе описания функционального поведения целевого объекта тестирования. Каждый вариант использования должен быть отражен как минимум в одном требовании. Более подробный список требований может включать хотя бы одно требование для каждого из потоков варианта использования.

Требования для тестов производительности

Требования по производительности возникают на основе изучения поведения, связанного с производительностью целевого объекта тестирования. Обычно производительность оценивается в единицах времени ответа и/или использования ресурсов в разных условиях, а именно:

различная нагрузка и/или состояние системы
различные варианты использования
различные конфигурации

Требования по производительности описаны в вспомогательных спецификациях. При работе с этими материалами обратите особое внимание на следующее:

указания времени, такие как время ответа или временные характеристики
описание числа событий или вариантов использования, которые должны быть выполнены в заданный отрезок времени
сравнение поведения различных элементов
сравнение поведения приложения в различных конфигурациях
надежность работы (среднее время между сбоями, MTTF)
конфигурации или ограничения

Каждый из этих моментов спецификации должен быть отражен как минимум в одном требовании.

Требования для тестов надежности

Источниками для создания тестов надежности являются вспомогательные спецификации, рекомендации по пользовательскому интерфейсу, рекомендации по проектированию и рекомендации по программированию.

При работе с этими материалами обратите особое внимание на следующее:

описание надежности и устойчивости к отказам, ошибкам времени выполнения (например, утечкам памяти)
описание структуры и стиля кода (совместимость со стандартом языка и синтаксис)
описание использования ресурсов

Каждый из этих моментов должен быть отражен как минимум в одном требовании.

Успех тестирования зависит от того, как удается сбалансировать такие факторы, как ограничения ресурсов и риски. Для этого тестирование должно планироваться таким образом, чтобы наиболее важные или рискованные варианты использования или компоненты тестировались в первую очередь. Оценка рисков и профайл работы служат основой для определения приоритетов в ходе тестирования.

В следующих разделах описаны способы определения приоритетов тестов.

Оценка риска и определение приоритетов в тестировании

Определение требований теста - это только часть подготовки к тестированию. Также необходимо определить приоритеты и очередность выполнения работы. Это этап необходим по следующим причинам:

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

В оценке рисков и определении приоритетов тестирования можно выделить три момента:

Оценка риска
Определение профайла заданий
Определение приоритета теста

Для каждого из этих моментов далее приведены соответствующие рекомендации.

Оценка риска

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

Начните с описания степени риска, используя следующие обозначения:

H - неприемлемо высокий риск. Серьезный резонанс для компании. Компания потерпит серьезные убытки, может быть привлечена к ответственности или безвозвратно потеряет репутацию.
M - средний риск, приемлемый, но нежелательный. Минимальный резонанс для компании, компания понесет убытки, но не будет привлечена к ответственности и не потеряет репутацию.
L - приемлемый невысокий риск. Минимальный резонанс для компании или вообще никакого, компания понесет минимальные убытки и не будет привлечена к ответственности. Репутация компания не пострадает.

После этого составьте список всех вариантов использования и компонентов целевого объекта тестирования. Для каждого варианта использования и компонента укажите степень риска и краткое обоснование.

Оценка риска может выполняться в трех проекциях:

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

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

Далее оценка риска в этих трех проекциях описана более подробно.

Последствия

Для оценки риска по последствиям выберите условие, событие или действие и попробуйте определить его воздействие. Задайте вопрос:

"Что произойдет, если ___________?"

Пример:

"Что произойдет, если при установке программного обеспечения закончится место на диске?"
"Что произойдет, если если соединение с Internet будет утеряно в ходе транзакции запроса?"
"Что произойдет, если если соединение с Internet будет утеряно в ходе транзакции оплаты?"
"Что произойдет, если пользователь введет непредвиденное значение?"

Ниже приведена соответствующая таблица:

Описание	Фактор риска	Обоснование
Недостаточно места на диске при установке	H	Установка программного обеспечения создает первое впечатление пользователя о продукте. Любые нежелательные эффекты из числа перечисленных ниже ухудшат впечатление пользователя о продукте и могут привести к нарушениям в работе системы и программного обеспечения: программное обеспечение устанавливается не полностью (файлы, записи в реестре), что приводит к нестабильности установленного программного обеспечения установка зависает и приводит систему в неработоспособное состояние
соединение с Internet нарушается в ходе запроса	L	Данные или база данных не повреждаются при обрыве соединения. Известно, что обрыв соединения может создать негативное впечатление у пользователя.
соединение с Internet нарушается в ходе покупки	H	Недопустимо, чтобы обрыв соединения или невыполненная транзакция приводили к нижеперечисленным эффектам, вследствие которых возрастают затраты и уменьшается прибыль: повреждение базы данных неполный заказ утерянный заказ или данные повторяющийся заказ
Ввод непредвиденного значения	H	Недопустимо, чтобы невыполненная транзакция приводила к нижеперечисленным эффектам, вследствие которых возрастают затраты и уменьшается прибыль: повреждение базы данных неточность данных

Причина

Оценка риска по причинам противоположна оценке по последствиям. Начните с того, что укажите нежелательное событие или состояние, и определите набор событий, которые могут к нему привести. Задайте вопрос:

"Как могло произойти ___________ ?

Пример:

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

Ниже приведена соответствующая таблица:

Описание	Фактор риска	Обоснование
Отсутствуют файлы приложения и записи реестра	H	Приложение (и система в целом) могут оказаться в нерабочем состоянии. Установка приложения - это первое, с чем сталкивается пользователь. Если установка завершается ошибкой, то какова бы ни была причина, у пользователя складывается негативное впечатление о продукте. Возможные причины: программа установки не скопировала все файлы или не обновила реестр установка была прервана пользователем (отмена или выход) установка была прервана программно или аппаратно (недостаточно места на диске, неподдерживаемая конфигурация и т.д.) установка была прервана по неизвестным причинам сам пользователь удалил файлы приложения и записи реестра Среди всех этих причин только последняя не может быть предусмотрена программой установки.
неполный заказ	H	Неполные заказы выполнить невозможно, что приводит к потере дохода и заказчиков. Возможные причины: Обрыв соединения с Internet из-за действий пользователя (отключение модема, выключение компьютера и пр.) Обрыв соединения с Internet из-за сбоя сети Обрыв соединения с Internet из-за действий сотрудников (отключение модема, выключение сервера и пр.)
Повреждение данных / базы данных	H	Повреждение данных является абсолютно недопустимым. Возможные причины: Транзакция записи в базу данных не была завершена или зафиксирована вследствие вмешательства пользователя Транзакция записи в базу данных не была завершена или зафиксирована вследствие утраты соединения с Internet Пользователь указал неверные данные для транзакции Методы или утилиты доступа к базе данных База данных не была заполнена правильными данными при создании
Повторяющиеся заказы	H	Повторяющиеся заказы увеличивают нагрузку на компанию и уменьшают прибыль из-за дополнительных расходов на доставку, обработку и складирование. Возможные причины: Транзакция записи заказа в базу данных была повторена вследствие событий, вызванных действиями пользователя, например, повторным вводом заказа в отсутствие подтверждения ввода Транзакция записи заказа в базу данных была повторена вследствие событий, не вызванных действиями пользователя, например, восстановление после утраты соединения с Internet, восстановление базы данных
Неточные данные для заказа	H	Все заказы, которые не могут быть выполнены или влекут дополнительные расходы, недопустимы. Возможные причины: Транзакция обработки заказа не была завершена или зафиксирована вследствие вмешательства пользователя Транзакция обработки заказа не была завершена или зафиксирована вследствие утраты соединения с Internet Пользователь указал неверные данные
В операторе указано неверное число записей	H	От точности отчетов зависят бизнес-решения и счета. Возможные причины: Неверный критерий поиска или выбора Неверный оператор SQL Повреждение данных в базе данных Неверные данные в базе данных

Вероятность

Оценка риска по вероятности позволяет определить вероятность отказа варианта использования или компонента. Обычно вероятность рассчитывается по внешним факторам, таким как:

Частота отказов
Скорость изменений
Сложность
Источник / автор

Отметим, что при работе с этой проекцией риска, показатели факторов риска связаны с вероятностью отказа, а не с последствиями отказа, как это было при оценке риска по причинам и последствиям.

Эти факторы и вероятность отказа связаны между собой, как показано ниже:

Внешний фактор	Вероятность
Частота обнаружения отказов	Вероятность отказа возрастает с увеличением частоты отказов. Ошибки имеют тенденцию к накоплению, поэтому если увеличивается частота обнаружения или число ошибок в варианте использования или компоненте, то вероятность других ошибок также возрастает. Также следует принять во внимание частоту отказов в предыдущих выпусках, так как если она была велика, то в этом выпуске с большой вероятностью будут обнаружены дополнительные ошибки.
Скорость изменений	Вероятность отказа возрастает с увеличением скорости изменения варианта использования или компонента. Чем больше внесено изменений, тем больше вероятность того, что они содержат ошибки. Всякий раз изменения в коде влекут за собой опасность новых ошибок.
Сложность	Вероятность отказа возрастает с увеличением сложности варианта использования или компонента.
Источник / автор	Знание того, кем и как был написан код, также влияет на вероятность отказов. Применение компонентов сторонних разработчиков обычно снижает вероятность отказа. Однако это справедливо только для проверенных компонентов, отвечающих вашим требованиям или прошедшим формальную проверку или тестирование. Вероятность ошибок меньше у знающих и опытных разработчиков. Однако такие факторы, как работа с новыми инструментами, технологиями или выполнение нескольких ролей повышает вероятность ошибок даже у лучших участников коллектива.

Пример:

Установка нового программного обеспечения
"Были обнаружены изъяны в компонентах, применяемых для реализации вариантов использования 1, 10 и 12, а наши заказчики запросили много изменений в вариантах 14 и 19."

Ниже приведена соответствующая таблица:

Описание	Фактор риска	Обоснование
Установка нового программного обеспечения	H	Мы пишем собственную программу установки. Делает приложение неработоспособным. Установка приложения - это первое, с чем сталкивается пользователь. Если установка завершается ошибкой, то какова бы ни была причина, у пользователя складывается негативное впечатление о продукте.
Установка нового программного обеспечения	L	Мы используем опробованную коммерческую программу установки. Хотя в результате установки приложение оказалось неработоспособным, выбранная программа установки поставляется производителем с мировым именем, который известен в бизнесе уже свыше четырех лет. Наши оценки говорят о том, что продукт отвечает нашим потребностям, и клиенты удовлетворены самим продуктом, производителем и уровнем обслуживания и поддержки.
Высокая частота обнаружения ошибок в вариантах использования 1, 10, 12.	H	Вследствие того, что в прошлых выпусках в вариантах использования 1, 10 и 12 было найдено много ошибок, эти варианты считаются рискованными.
Запросы на изменение в вариантах использования 14 и 19.	H	Большое число изменений в этих вариантах использования увеличивает вероятность возникновения в них ошибок.

Определение операционного профайла

Далее необходимо определить операционный профайл, с тем чтобы оценить риски и определить приоритеты тестов.

Начните с описания уровня операционного профайла, используя следующие обозначения:

H - очень частое использование, много раз в течение заданного интервала времени или многими субъектами или вариантами использования.
M - частое использование, несколько раз в течение заданного интервала времени или несколькими субъектами или вариантами использования.
L - нечастое использование, малое число субъектов или вариантов использования.

Показатель операционного профайла следует выбирать на основании частоты применения варианта использования или компонента:

число раз, которое ОДИН субъект (или вариант использования) применяет вариант использования (или компонент) в течение заданного времени
число субъектов (или вариантов использования), работающих с вариантом использования (или компонентом)

Обычно чем чаще применяют вариант использования или компонент, тем выше его операционный профайл.

После этого составьте список всех вариантов использования и компонентов целевого объекта тестирования. Определите операционный профайл для каждого элемента списка и обоснуйте это значение. В оценке может помочь документ Рабочий продукт: документ анализа рабочей нагрузки.

Примеры:

Установка нового программного обеспечения
Заказ предметов из электронного каталога
Запрос клиентов о выполнении их электронного заказа
Окно выбора элемента

Описание	Операционный профайл	Обоснование
Установка нового программного обеспечения	H	Выполняется, как правило, один раз, но многими пользователями. Приложение не может работать, если оно не было установлено.
Заказ предметов из электронного каталога	H	Это самый частый вариант использования.
Запрос заказчиков о заказе	L	Справки о заказе обычно запрашивают немногие пользователи
Окно выбора элемента	H	С этим окном работают клиенты, помещая заказ, и сотрудники склада, обновляя данные об ассортименте.

Определение приоритета теста

Наконец необходимо определить приоритеты тестов.

Начните с описания степени приоритета теста, используя следующие обозначения:

H - тестирование необходимо
M - тестирование следует выполнить, но после выполнения всех элементов H
L - тестирование может выполняться, но только после тестирования всех элементов H и M

После этого составьте список всех вариантов использования и компонентов целевого объекта тестирования. Определите приоритет для каждого элемента списка и обоснуйте это значение. Ниже приведены некоторые рекомендации по определению индикатора приоритета теста.

При определении приоритета тестов примите во внимание следующее:

индикатор величины риска, указанный ранее
операционный профайл, указанный ранее
описания субъектов (есть ли у них опыт, готовы ли устранять ошибки)
обязательства по контракту (будет ли принят целевой объект тестирования, если какой-либо вариант использования или компонент не будут поставлены)

Ниже перечислены основные принципы определения приоритетов:

Используйте наиболее высокий фактор (риск, операционный профайл и т.д.) для общего приоритета.
Определите наиболее значимый фактор (риск, операционный профайл и т.д.) и используйте его для указания приоритета.
Используйте сочетание всех факторов для указания приоритета.
Для учета всех факторов можно вычислить взвешенный приоритет с учетом весов факторов.

Примеры:

Установка нового программного обеспечения
Заказ предметов из электронного каталога
Запрос клиентов о выполнении их электронного заказа
Окно выбора элементов

Если для указания приоритета используется наибольшее значение:

Элемент	Риск	Операционный профайл	Субъект	Контракт	Приоритет
Установка нового программного обеспечения	H	H	L	H	H
Заказ предметов из каталога	H	H	H	H	H
Запросы клиентов	L	L	L	L	L
Окно выбора элементов	L	H	L	L	H

Если для указания приоритета используется наибольшее значение какого-либо одного фактора (риск):

Элемент	Риск	Операционный профайл	Субъект	Контракт	Приоритет
Установка нового программного обеспечения	H	H	L	H	H
Заказ предметов из каталога	H	H	H	H	H
Запросы клиентов	L	L	L	L	L
Окно выбора элементов	L	H	L	L	L

Если для определения приоритета учитывается вес факторов:

В таблице H = 5, M = 3, L = 1. Общее взвешенное значение свыше 30 - это элемент тестирования с высоким приоритетом, от 20 до 30 включительно - со средним приоритетом, и ниже 20 - с низким приоритетом.

Элемент	Риск (x 3)	Операционный профайл (x 2)	Субъект (x 1)	Контракт (x 3)	Взвешенное значение	Приоритет
Установка нового программного обеспечения	5 (15)	5 (10)	1 (1)	5 (15)	41	H (2)
Заказ предметов из каталога	5 (15)	5 (10)	5 (5)	5 (15)	45	H (1)
Запросы клиентов	1 (3)	1 (2)	1 (1)	1 (3)	9	L (4)
Окно выбора элементов	1 (3)	5 (10)	1 (1)	1 (3)	17	L (3)

Стратегия тестирования

Стратегия тестирования описывает общие подходы и цели какого-либо аспекта тестирования.

Хорошая стратегия тестирования включает следующее:

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

Тип теста и цели

Четко сформулируйте тип теста и его цель. Если эта информация указана явным образом, то не возникает путаницы и непонимания, особенно если есть очень похожие тесты. Цель должна четко определять, зачем проводится этот тест.

Примеры:

"Функциональный тест. Функциональный тест, посвященный проверке выполнения указанных вариантов использования, реализованных в целевом объекте тестирования, в его пользовательском интерфейсе."

"Тест производительности. Тест производительности системы, посвященный измерению времени ответа системы в вариантах 2, 4 и с 8 по 10. В этих тестах нагрузка создается одним субъектом, выполняющим эти варианты использования, и никакая другая нагрузка при этом на тестовую систему не возлагается."

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

Этап тестирования

Четко обозначьте этап, в ходе которого будет выполняться тестирование. Ниже перечислены этапы, в течение которых выполняются распространенные тесты:

	Этап тестирования
Типы тестов	Единица	Интеграция	Система	Приемка
Функциональные тесты (конфигурация, функции. установка, защита, объем данных)	X	X	X	X
Тесты производительности (профайлы производительности отдельных компонентов)	X	X	(X) необязательные, или когда в тестах производительности системы выявлены ошибки
Тесты производительности (нагрузка, пиковая нагрузка, конкуренция)			X	X
Надежность (целостность данных, структура)	X	X	(X) необязательные, или когда в других тестах выявлены ошибки

Методика

Методика описывает, как будет реализован и выполнен тест. Включите в описание то, что будет тестироваться, основные действия, которые требуется выполнить в ходе теста и способы оценки результатов.

Пример:

Функциональный тест:

Для каждого потока событий в варианте использования определяется представительный набор транзакций, каждый из которых относится к действиям, выполняемым субъектом в ходе работы с вариантом использования.

Для каждой транзакции будут разработаны хотя бы два тестовых набора, первый из которых будет отражать позитивное условие, а второй - отрицательное (неприемлемое) условие.

В первой итерации будут тестироваться варианты использования с 1 по 4 и 12, а именно:

Вариант использования 1:

Вариант использования 1 начинается с того, что субъект уже вошел в систему и работает с главным окном, и заканчивается, когда пользователь выбирает действие Сохранить.

Каждый тестовый набор будет реализован и выполнен с помощью Rational Robot.

Проверка выполнения и оценка результатов для каждого тестового набора будет выполнена следующим способом:

Выполнение сценария теста - были ли все тестовые сценарии выполнены полностью и успешно?

Способы проверки показа окон и данных объектов должны будут проверить, что главные окна системы будут показаны, а данные записаны и отображены целевым объектом тестирования в ходе теста.

Будет изучена база данных целевого объекта тестирования (Microsoft Access), сначала до теста, потом после теста, в ходе чего будет проверена правильность данных, измененных в ходе теста.

Тест производительности:

Для каждого варианта использования будет реализован и выполнен представительный набор транзакций, указанный в документе анализа рабочей нагрузки, в Rational Suite PerformanceStudio (сценарии vu) и Rational Robot (сценарии GUI).

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

Перегрузка: 750 пользователей (15 % руководство, 50 % отдел продаж, 35 % отдел маркетинга)

Повышенная нагрузка: 350 пользователей (10 % руководство, 60 % отдел продаж, 30 % отдел маркетинга)

Расчетная нагрузка: 150 пользователей (2 % руководство, 75 % отдел продаж, 23 % отдел маркетинга)

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

Продолжительность рабочей нагрузки, создаваемой тестовыми сценариями, составляет один час (если не оговорено противное в документе анализа рабочей нагрузки).

Проверка выполнения и оценка результатов для каждого прогона теста (с указанной нагрузкой) будет выполнена следующим способом:

Выполнение теста будет отслеживаться по гистограммам состояний (для проверки правильности обеспечения требуемой нагрузки в ходе теста)

Выполнение сценария теста - были ли все тестовые сценарии выполнены полностью и успешно?

Запись и оценка времени ответа будет представлена в следующих отчетах:

Процентные соотношения производительности

Время ответа

Критерии завершения

Критерии завершения формулируются для двух целей:

определить, соответствует ли качество продукта поставленным требованиям
определить, была ли успешно выполнена программа тестирования

Формулировка критериев завершения должна включать следующие элементы:

измеряемые функция, поведение или условие
способ измерения
критерии или степень соответствия измерению

Пример 1

Все запланированные тестовые наборы были выполнены
Все выявленные изъяны были устранены в той степени, в какой это было необходимо
Все запланированные тестовые наборы были выполнены повторно, при этом все выявленные изъяны были устранены в той степени, в какой это было необходимо, и никаких новых изъянов выявлено не было

Пример 2

Все приоритетные тестовые наборы были выполнены.
Все выявленные изъяны были устранены в той степени, в какой это было необходимо.
Все изъяны серьезности 1 или 2 были устранены (со статусом устранен или отложен).
Все приоритетные тестовые наборы были выполнены повторно, при этом все выявленные изъяны были устранены в той степени, в какой это было необходимо, и никаких новых изъянов выявлено не было.

Пример 3

Все запланированные тестовые наборы были выполнены.
Все выявленные изъяны были устранены в той степени, в какой это было необходимо.
Все изъяны серьезности 1 или 2 были устранены (со статусом подтвержден или отложен).
Все приоритетные тестовые наборы были выполнены повторно, при этом все выявленные изъяны были устранены в той степени, в какой это было необходимо, и никаких новых изъянов выявлено не было.

Особые рекомендации

В этом разделе должны быть указаны все факторы или зависимости, которые могут повлиять на программу тестов, описанную в стратегии тестирования. Они могут включать:

ресурсы персонала (например, доступность или потребность в дополнительных ресурсах для поддержки или участия в тесте)
ограничения, например, доступность или ограничения оборудования, или потребность в специальном оборудовании
особые требования, например, расписание тестов или доступ к системам

Примеры:

Для работы с базой данных требуется помощь администратора или проектировщика базы данных, чтобы создать и обновить тестовые данные.
Тестирование производительности должно выполняться с серверами в существующей сети (в которой также может быть поток данных, не относящийся к тесту). Тестирование должны быть запланировано на нерабочие часы, чтобы исключить этот посторонний поток данных в сети.
Для выполнения полнофункционального тестирования целевой объект тестирования должен быть синхронизирован с действующей системой (или синхронизация должна быть смоделирована)