Документация, сопровождающая процесс верификации и тестирования (тест-планы)

11.1. Тест-планы

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

На основании тест-требований составляются тест-планы - программы испытаний (проверки, тестирования) программной реализации системы. В отличие от тест-требований в тест-плане описываются конкретные способы проверки функциональности системы, т.е. то, как должна проверяться функциональность. Как правило, тест-план состоит из отдельных тестовых примеров, каждый из которых проверяет некоторую функцию или набор функций системы. Для каждого тестового примера однозначно определяется критерий успешного прохождения ( pass/fail criteria ), при помощи которого можно судить - соответствует ли поведение системы заданному в требованиях или нет (Рис 11.1).

Рис. 11.1. Место тест-планов среди проектной документации

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

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

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

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

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

11.1.2. Возможные формы подготовки тест-планов

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

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

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

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

11.1.3. Сценарии

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

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

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

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

Сообщение "Загрузка" пропадает через приемлемое время

Степень приемлемости здесь будет зависеть от терпеливости тестировщика, и обеспечить повторяемость тестирования будет затруднительно. Более удачной формой описания той же самой ожидаемой реакции будет

Сообщение "Загрузка" исчезает с экрана не более, 
чем через 10 секунд после появления.

Ниже приведен пример описания тестового примера в виде сценария, предназначенного для ручного тестирования:

Группа тестов: Работа с учетными записями

Тестовый пример: 1289-15

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

Тест-требования: 8.5.8.1, 8.5.8.2

Предусловия для теста: Система должна быть приведена 
в состояние "Максимальная защита" и сброшена 
в настройки по умолчанию.

Критерий прохождения теста: Все ожидаемые значения 
совпадают с реальными.

Enter your credentials…
Login:

Default user blocked - system set to High security

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

Сценарии тестирования для автоматического тестирования часто описывают на том или ином языке программирования. Например, методы в тестирующих классах Microsoft Visual Studio Team Edition представляют собой именно пошаговые описания действий, которые необходимо выполнить тестовому окружению для проведения тестирования. Возможна и более близкая к естественному языку форма подготовки тестовых примеров. Например, при тестировании логической функции с уровнем покрытия MC/DC и описании тестовых примеров на одном из диалектов Visual Basic Script возможно записать сценарий тест-плана в такой форме:

'----------------------------------------------------------------
'                         TEST CASES                                        
'----------------------------------------------------------------
' 8 testcases
'                          1  2  3  4  5  6  7  8
' -----------------------------------------------
' computed                 -  -  0  0  0  -  -  -
' good1                    0  1  0  0  0  0  0  0
' computed2                -  -  -  -  0  -  -  -
' good2                    1  1  1  0  0  1  1  1
' delay                    -  -  -  -  -  0  -  -
' pack1                    1  1  1  1  1  1  0  0
' pack2                    0  0  0  0  0  0  0  1
' -----------------------------------------------
' output_message           1  0  0  1  0  0  0  1


'-------------------------------------------------------------------
' Testcase #1:
Call Test_Message_Call (-, 0, -, 1, -, 1, 0, 1)
'-------------------------------------------------------------------
' Testcase #2:
Call Test_Message_Call (-, 1, -, 1, -, 1, 0, 0)
'-------------------------------------------------------------------
' Testcase #2:
Call Test_Message_Call (0, 0, -, 1, -, 1, 0, 0)
'-------------------------------------------------------------------' Testcase #4:
Call Test_Message_Call (0, 0, -, 0, -, 1, 0, 1)
'-------------------------------------------------------------------' Testcase #5:
Call Test_Message_Call (0, 0, 0, 0, -, 1, 0, 0)
'-------------------------------------------------------------------' Testcase #6:
Call Test_Message_Call (-, 0, -, 1, 0, 1, 0, 0)
'-------------------------------------------------------------------' Testcase #7:
Call Test_Message_Call (-, 0, -, 1, -, 0, 0, 0)
'-------------------------------------------------------------------' Testcase #8:
Call Test_Message_Call (-, 0, -, 1, -, 0, 1, 1)

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