Рекомендация: Тестовый набор
Эта рекомендация посвящена планированию и разработке программного обеспечения для тестирования.
Взаимосвязи
Основное описание

Объяснение

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма, описанная в тексте.

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

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

Сценарий 1 Основной поток      
Сценарий 2 Основной поток Альтернативный поток 1    
Сценарий 3 Основной поток Альтернативный поток 1 Альтернативный поток 2  
Сценарий 4 Основной поток Альтернативный поток 3    
Сценарий 5 Основной поток Альтернативный поток 3 Альтернативный поток 1  
Сценарий 6 Основной поток Альтернативный поток 3 Альтернативный поток 1 Альтернативный поток 2
Сценарий 7 Основной поток Альтернативный поток 4    
Сценарий 8 Основной поток Альтернативный поток 3 Альтернативный поток 4  

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

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

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

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

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

ИД тестового набора Сценарий Условие Ожидаемый результат
ТН x Сценарий 4 Шаг 2 - Запрошенная сумма > Остаток на счете Вернуться к основному потоку на шаге 2
ТН y Сценарий 4 Шаг 2 - Запрошенная сумма < Остаток на счете Не выполнять альтернативный поток 3, выполнить основной поток
ТН z Сценарий 4 Шаг 2 - Запрошенная сумма = Остаток на счете Не выполнять альтернативный поток 3, выполнить основной поток

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

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

Пример:

Диаграмма, описанная в тексте.

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

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

Основной поток Вариант использования начинается с того, что банкомат готов к обслуживанию клиента.
  1. Начало работы - клиент вставляет карточку в устройство чтения банкомата
  2. Проверка карты - банкомат считывает магнитную полосу карты  и проверяет пригодность карты.
  3. Ввод PIN-кода - банкомат просит ввести PIN-код (4 цифры)
  4. Проверка кода счета и PIN-кода - выполняется проверка допустимости счета и правильности введенного для него PIN-кода. В этом потоке счет пригоден для операций и для него указан правильный PIN-код.
  5. Опции банкомата - банкомат показывает меню своих опций.   В этом потоке клиент всегда выбирает опцию получения наличных.
  6. Указание суммы - банкомат запрашивает сумму для выдачи. В этом потоке клиент выбирает одно из стандартных значений ($10, $20, $50 или $100).
  7. Проверка доступа - банкомат отправляет в банковскую систему данные для проверки: ИД карты, PIN-код, сумму и информацию о счете как транзакцию.   В этом потоке банковская система включена и отвечает, что авторизация выполнена успешно, после чего можно выдать наличные и обновить остаток на счете соответственно.
  8. Выдача денег - банкомат выдает наличные
  9. Возврат карты - карта возвращается клиенту.
  10. Квитанция - печатается и выдается клиенту.   Банкомат также обновляет свой внутренний протокол.  

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

Альтернативный поток 1 - непригодная карта На шаге 2 основного потока - Проверка карты, если обнаружена непригодная карта, то она возвращается клиенту с соответствующим сообщением.
Альтернативный поток 2 - нет денег в банкомате  На шаге 5 основного потока - Опции банкомата, если в банкомате нет денег, то опция "Получить наличные" будет недоступна.
Альтернативный поток 3 - недостаточно средств в банкомате  На шаге основного потока 6 - Указание суммы, если в банкомате не хватает средств для выдачи запрошенной суммы, то будет показано соответствующее сообщение, и выполнение вернется к шагу 6 основного потока, Указание суммы.
Альтернативный поток 4 - Неверный PIN-код  На шаге 4 основного потока - Проверка счета и PIN-кода, у клиента есть три попытки для ввода правильного PIN-кода.   

Если введен неверный PIN-код, то банкомат показывает соответствующее сообщение, и если число попыток не исчерпано, то выполнение возвращается на шаг 3 основного потока - Ввод PIN-кода.  

Если и при последней попытке PIN-код указан неверно, то карта задерживается, а банкомат возвращается в состояние обслуживания клиентов. На этом этот вариант использования завершается.
Альтернативный поток 5 - Неверный счет  На шаге 4 основного потока - Проверка счета и PIN-кода, если банковская система возвращает ответ, указывающий, что счет не найден или с него не разрешено снимать деньги, то банкомат показывает соответствующее сообщение, а выполнение возвращается к шагу 9 основного потока - Выдача карты.
Альтернативный поток 6 - Недостаточно средств на счете На  шаге 7 основного потока - Авторизация, если банковская система возвращает ответ, указывающий, что остаток на счете меньше запрошенной клиентом на шаге 6 суммы, то банкомат показывает соответствующее сообщение, а выполнение возвращается к шагу 6 основного потока - Указание суммы.
Альтернативный поток 4 - Превышен лимит ежедневной выдачи  На шаге 6 основного потока - Авторизация, если банковская система возвращает ответ, указывающий, что вместе с запрошенной клиентом суммой был бы превышен лимит ежедневной выдачи средств, то банкомат показывает соответствующее сообщение, а выполнение возвращается к шагу 6 основного потока - Указание суммы.
Альтернативный поток x - ошибка протокола Если на шаге 10 основного потока - Квитанция, не удается обновить протокол, то банкомат переходит в "безопасный режим", в котором все его операции приостановлены. В банковскую систему отправляется соответствующее уведомление о приостановке работы банкомата.
Альтернативный поток y - Выход Клиент может в любой момент прервать транзакцию и завершить операцию. Транзакция прекращается, а карта возвращается клиенту.
Альтернативный поток z - "Взлом" В банкомате установлены датчики, отслеживающие такие показатели, как питание, давление на двери и заслонки, детекторы движения.   Если датчик подает сигнал, то в полицию отправляется сигнал тревоги, а банкомат переходит в "безопасный режим", в котором его функции приостановлены, пока он не будет повторно инициализирован.


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

  • Основной поток - выдача одной из стандартных сумм ($10, $20, $50, $100)
  • Альтернативный поток 2 - нет денег в банкомате
  • Альтернативный поток 3 - недостаточно средств в банкомате
  • Альтернативный поток 4 - Неверный PIN-код
  • Альтернативный поток 5 - Неверный счет
  • Альтернативный поток 6 - Недостаточно средств на счете

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

Сценарий 1 - успешное получение денег Основной поток   
Сценарий 2 - нет денег в банкомате Основной поток Альтернативный поток 2
Альтернативный поток 3 - недостаточно средств в банкомате Основной поток Альтернативный поток 3
Сценарий 4 - Неверный PIN-код (остаются попытки) Основной поток Альтернативный поток 4 
Сценарий 5 - Неверный PIN-код (все попытки исчерпаны) Основной поток Альтернативный поток 4 
Сценарий 6 - Неверный счет Основной поток Альтернативный поток 5
Сценарий 7 - Недостаточно средств на счете  Основной поток Альтернативный поток 6

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

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

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

ИД ТН # Сценарий / условие PIN-код Счет # Введенная сумма

(выбранная сумма)

Остаток на счете Наличность в банкомате Ожидаемый результат
CW1. Сценарий 1 - успешное получение денег V V V V V Успешное получение денег.
CW2. Сценарий 2 - нет денег в банкомате V V V V Опция получения денег недоступна, конец варианта использования
CW3. Сценарий 3 - недостаточно средств в банкомате V V V V Предупреждающее сообщение, возврат к этапу основного варианта 6 - Указание суммы
CW4. Сценарий 4 - Неверный PIN-код (остается > 1 попытки) V нд V V Предупреждающее сообщение, возврат к этапу основного варианта 4 , Ввод PIN-кода
CW5. Сценарий 4 - Неверный PIN-код (остается 1 попытка) V нд V V Предупреждающее сообщение, возврат к этапу основного варианта 4 , Ввод PIN-кода
CW6. Сценарий 4 - Неверный PIN-код (все попытки исчерпаны ) V нд V V Предупреждающее сообщение, карта задержана, конец варианта использования

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

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

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

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

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

ИД ТН # Сценарий / условие PIN-код Счет # Введенная сумма

(выбранная сумма)

Остаток на счете Наличность в банкомате Ожидаемый результат
CW1. Сценарий 1 - успешное получение денег 4987 809 - 498 50.00 500.00 2000 Успешное получение денег. Остаток счета обновлен и равен 450.00
CW2. Сценарий 2 - нет денег в банкомате 4987 809 - 498 100.00 500.00 0.00 Опция получения денег недоступна, конец варианта использования
CW3. Сценарий 3 - недостаточно средств в банкомате 4987 809 - 498 100.00 500.00 70.00 Предупреждающее сообщение, возврат к этапу основного варианта 6 - Указание суммы
CW4. Сценарий 4 - Неверный PIN-код (остается > 1 попытки) 4978  809 - 498 нд 500.00 2000 Предупреждающее сообщение, возврат к этапу основного варианта 4 , Ввод PIN-кода
CW5. Сценарий 4 - Неверный PIN-код (остается 1 попытка) 4978 809 - 498 нд 500.00 2000 Предупреждающее сообщение, возврат к этапу основного варианта 4 , Ввод PIN-кода
CW6. Сценарий 4 - Неверный PIN-код (все попытки исчерпаны ) 4978  809 - 498 нд 500.00 2000 Предупреждающее сообщение, карта задержана, конец варианта использования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИД ТН # Нагрузка Условие Ожидаемый результат
PCW1.

1

(одиночный банкомат)

Выполнение транзакции выдачи денег

Выполнение транзакции (время, не зависящее от субъекта) занимает < 20 секунд
PCW2.

2

(1000 одновременно работающих банкоматов)

Выполнение транзакции выдачи денег

Выполнение транзакции (время, не зависящее от субъекта) занимает < 30 секунд
PCW3.

3

(10000 одновременно работающих банкоматов)

Выполнение транзакции выдачи денег

Выполнение транзакции (время, не зависящее от субъекта) занимает < 50 секунд

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

ИД ТН # Нагрузка Условие Ожидаемый результат
SCW1.

2

(1000 одновременно работающих банкоматов)

Блокировка в базе данных - 2 банкомата одновременно запрашивают один и тот же счет

запросы банкоматов помещаются в очередь
SCW2.

2

(1000 одновременно работающих банкоматов)

Недоступна банковская система связи

Транзакция помещается в очередь или аннулируется по тайм-ауту
SCW3.

2

(1000 одновременно работающих банкоматов)

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

Показывается предупреждающее сообщение

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

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

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

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

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

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

ИД ТН # Условие Карта

(V означает допустимую карту)

Устройство чтения карты

(V означает, что устройство работает правильно)

Банковская сеть Ожидаемый результат
ACW1. В сети банка V V V Доступны все варианты использования
ACW2. Вне сети банка V V Только вариант использования снятия денег
ACW3. Не удается прочитать карту V V Предупреждающее сообщение, карта извлечена
ACW4. Карта считается украденной V V Предупреждающее сообщение, карта задержана
ACW5. Карта просрочена V V Предупреждающее сообщение, карта задержана

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

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

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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