Объяснение

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

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

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

При всей важности собственно требований для определения тестов, они не являются единственным источником информации. Во многих случаях опора только на требования не будет достаточной для формирования тестов. Тестовые наборы должны также учитывать риски, ограничения, технологии, запросы на изменение (изъяны), ошибки и пр.
За дополнительной информацией по разработке идей для тестов обратитесь к разделу Концепции: идеи тестов.

Создание тестового набора важно по нескольким причинам.

• Тестовый набор можно использовать как основу для проектировании и реализации собственно тестов. Время, потраченное на рассмотрение тестового набора, позволяет лучше понять требования к проекту и реализации и сэкономить время на задачах, относящихся к проектировании и реализации.
• Некоторые тесты могут быть особенно сложными или объемными. Такие тесты лучше хорошо изучить заранее, прежде чем их реализовывать, и для этого тестовый набор и артефакты проекта теста могут быть очень полезными.
• Объем тестирования обычно пропорционален числу тестов. К самому процессу тестирования можно будет относиться с большей уверенностью, если объем тестирования будет обоснован с помощью ряда тестовых наборов.
• Мерой полноты тестирования может является учет какого-либо ряда определяющих факторов. Этими факторами могут быть число выделенных тестовых наборов, число реализованных и /или выполненных тестов для каждого тестового набора, а также усилия, потраченные на исследование каждого тестового набора.
• Масштаб и сложность тестирования в какой-то степени можно считать пропорциональными числу тестовых наборов. Создание тестовых наборов позволяет с большей уверенностью оценить усилия, затраченные на тестирование.
• Варианты проектирования и разработки тестов и требуемые для тестирования ресурсы также зависят от числа и сложности тестовых наборов.

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

• Не всякий тест является настолько сложным, чтобы ради него создавать артефакт тестового набора, который подлежит обзору и обновлению. Для простых тестов достаточно краткого описания того, что следует сделать. Очень многие тесты попадают именно в эту категорию. Затраты времени на документирование большого числа простых тестовых наборов могут оказаться излишними.
• Иногда в ходе тестирования обнаруживается, что тесты опирались на ошибочные идеи. Это означает, что тестовые наборы, основанные на этих идеях, будут отброшены. Фактически это будет означать, что вся работа по документированию тестового набора пойдет насмарку, а все отчеты, основанные на нем, потребуется пересмотреть. Поэтому отчеты об охвате тестов лучше основывать на более достоверных источниках, чем тестовые наборы, а тестовые наборы применять внутри коллектива по необходимости.

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

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

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

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

На рисунке стрелками показаны различные пути варианта использования, соответствующие основному и альтернативным потокам выполнения. Основной поток, представленный прямой линией - это самый простой путь выполнения варианта использования. Все альтернативные потоки начинаются от основного и затем отходят от него вследствие какого-то условия. Альтернативные потоки могут снова слиться с основным (потоки 1 и 3), могут отходить от другого альтернативного потока (поток 2) или заканчивать вариант использования, не сливаясь с основным потоком (потоки 2 и 4).

Примеры потоков для варианта использования

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

Примечание: Для простоты в сценариях 5, 6 и 8 показано только одно выполнение цикла, относящегося к альтернативному потоку 3.    

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

Например, для варианта использования на рисунке альтернативный поток 3 соответствует следующему условию:

"Это поток реализуется, если на шаге 2, "Введите сумму", указана сумма, превышающая остаток на счете клиента. Система показывает предупреждение и возвращается к шагу 2 основного потока "Введите сумму", предлагая клиенту повторно ввести сумму."

На основании этой информации можно выделить тестовые наборы, необходимые для выполнения альтернативного потока 3:

Примечание: эти тестовые наборы слишком упрощены, так как нет никакой другой информации. Фактические тестовые наборы не бывают такими простыми.

Более реалистичный пример мог бы быть следующим:

Пример:

Субъекты и варианты использования банкомата.

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

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

Примечание: Для простоты в альтернативных потоках 3 и 6 (сценарии 3 и 7) циклы и их сочетания были опущены.

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

Для того чтобы начать разработку матрицы, определите, какие элементы данных являются обязательными для выполнения сценариев варианта использования. Затем для каждого сценария определите хотя бы один тестовый набор, содержащий соответствующее выполнению сценария условие. Например, в примере матрицы, приведенном далее, V (valid) обозначает условие, которое необходимо для выполнения основного потока, а I (invalid) обозначает условие, вследствие которого вызывается альтернативный поток.  В таблице также встречается обозначение "нд", указывающее, что это условие неприменимо для данного тестового набора.

В матрице шесть тестовых наборов приводят к выполнению четырех сценариев. Для основного потока тестовый набор CW1 называется позитивным тестовым набором. Он проходит по всему пути основного потока без отклонений. Полное тестирование основного потока должно также включать отрицательные тестовые наборы, чтобы убедиться в том, что основной поток выполняется только при наличии всех правильных условий. Эти отрицательные тестовые наборы обозначены как CW2 - 6 (закрашенная ячейка указывает на условие, приводящее к выполнению альтернативного потока).  CW2 - 6 - это отрицательные тестовые наборы для основного потока, но позитивные тестовые наборы для альтернативных потоков 2 - 4, и для каждого из этих альтернативных потоков есть хотя бы один отрицательный тестовый набор (CW1 - основной поток).

Сценарий 4 - это пример того, когда только одного позитивного и одного отрицательного тестового набора недостаточно для сценария. Для того чтобы полностью протестировать сценарий 4 - неверный PIN-код, требуется как минимум три позитивных тестовых набора:

• введен неверный PIN-код, и остаются еще попытки, при этом альтернативный поток вливается в основной поток на шаге 3 - Ввод PIN-кода
• введен неверный PIN-код, и все попытки исчерпаны, при этом альтернативный поток приводит к задержанию карты и завершению варианта использования
• Введен правильный PIN-код, когда все попытки исчерпаны.  При этом альтернативный поток переходит в основной поток на шаге 5 - указание суммы.  

Обратите внимание, что в матрице не были указаны никакие значения условий (фактических данных). Такой способ создания матрицы тестового набора позволяет увидеть, какие условия будут тестироваться. Также сразу видно, указано ли достаточное число тестовых наборов, так как они выделены символами V и I (или в нашем случае - подсветкой ячеек). В таблице видно, что для некоторых условий нет подсвеченных ячеек, следовательно, не указан тестовый набор, например, для сценария 6 - нет счета или неверный тип счета, а также сценария 7 - недостаточно средств на счете.

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

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

• Сценарий 6 - Счет не найден или неверный тип счета: счет не найден или недоступен
• Сценарий 6 - Счет не найден или неверный тип счета: не разрешено снятие денег со счета
• Сценарий 7 - Недостаточно средств на счете: запрошенная сумма превышает остаток на счете

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

• Недопустимая карта (утерянная, украденная, из недопустимого банка, с поврежденной полосой и пр.)
• Невозможность чтения карты (устройство чтения отказало или с ним утеряна связь)
• Счет закрыт, заблокирован или недоступен по другой причине
• Недостаточно денег в банкомате для выдачи указанной суммы, отличается от CW3 тем, что деньги еще остались, но их мало
• Не удается связаться с банковской системой и получить ее подтверждение
• Банковская сеть вышла из строя или отказало питание в ходе транзакции

Для идентификации функциональных тестовых наборов выполните следующее:

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

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

Создание тестового набора на основе вспомогательных спецификаций

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

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

• Создание тестового набора для тестирования производительности
• Создание тестового набора для тестирования защиты и прав доступа
• Создание тестового набора для тестирования конфигурации
• Создание тестового набора для тестирования установки
• Создание тестового набора для прочих нефункциональных тестов

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

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

• создайте хотя бы один тестовый набор для каждого положения вспомогательной спецификации, относящегося к критериям производительности. Критерии производительности могут выражаться как время на одну транзакцию, число транзакций или пользователей, или процентные соотношения.
• создайте хотя бы один тестовый набор для каждого критически важного варианта использования. Критические варианты использования перечислены в указанных документах и в документе анализа рабочей нагрузки и должны оцениваться с помощью показателей производительности. См. Рабочий продукт: документ анализа рабочей нагрузки.

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

Поимо указанных критериев производительности выделите особые условия, которые влияют на время отклика, а именно:

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

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

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

Ниже приведены примеры различных типов тестов производительности:

Для тестирования нагрузки:

Для тестирования отказоустойчивости:

Создание тестового набора для тестирования защиты и прав доступа

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

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

Придерживайтесь рекомендаций, уже описанных выше для функциональных тестовых наборов.

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

Примеры тестовых наборов для защиты и прав доступа:

Создание тестового набора для тестирования конфигурации

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

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

• Создайте хотя бы один тестовый набор для каждой критически важной конфигурации. Для этого определите обязательные программные и аппаратные конфигурации в среде целевого объекта тестирования и определите их приоритеты, чтобы наиболее важные были протестированы в первую очередь:
  • Поддержка принтера
  • Сетевые соединения - локальная и глобальная сеть
  • Конфигурации сервера - драйверы сервера, аппаратное обеспечение сервера
  • Прочее установленное на рабочем столе и/или сервере программное обеспечение
  • Все версии программного обеспечения
• Создайте хотя бы один тестовый набор для каждой конфигурации, в которой вероятны неполадки. В их число входят:
  • Аппаратное обеспечение с наименьшей производительностью.
  • Сопутствующее программное обеспечение, для которого ранее уже были выявлены неполадки, связанные с совместимостью.
  • Клиенты, работающие с сервером по самым медленным сетевым каналам.
  • Ситуации недостатка ресурсов (медленный процессор, недостаточно памяти или места на диске и пр.)

Создание тестового набора для тестирования установки

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

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

• Установка с носителя, например, с дискеты, CD-ROM или файлового сервера.
• Новая установка.
• Полная установка.
• Выборочная установка.
• Обновление системы.

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

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

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

Примеры:

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

В большинстве случаев эти тестовые наборы создаются на основе или посредством объединения уже имеющихся тестовых наборов.

Создание тестового набора для тестирования приемки продукта

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

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

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

Создание проверочных тестовых наборов для регрессионного тестирования

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

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

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

Определение данных тестов для тестового набора

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

Работа с тестовыми данными описана в документе Рекомендация: тестовые данные.