Верификация программного обеспечения

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

Разбить на страницы
Показывать лекцию целиком

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

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

Критерий прохождения теста: Все ожидаемые значения 
совпадают с реальными.
    Сценарий тестирования:
    № Шаг сценария Ожидаемый результат
    1 Запустить терминальный клиент и соединиться с системой по адресу 127.0.0.1 Должно появиться приглашение терминала TRANSFER>
    2 Запустить процесс передачи данных при помощи ввода команды SEND DATA Должно появиться приглашение DATA TRANSFER INITIATED и следующими двумя строками
    Enter your credentials…
Login:
    3 Ввести имя учетной записи default Должна появиться строка Password:
    4 Ввести пароль default Должно появиться сообщение
    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)

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

    11.1.4. Таблицы

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

    '                          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

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

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

    +-------------+
INPUTS:                     | a b c d e f |
----------------------------+-------------+
Power_On_Mode               |
 COLD                       | X X       X 
 WARM                       |     X X X
Configuration_Store_Id      |
 0xFFFD                     | X X X X X X 
IR_Access_Mode              |
 1                          | X X X     X 
 0                          |       X
 0xFFFF                     |         X
Reset_Mode                  |
 0                          | X X X X X X 
Reset_Source                |
 0                          |   X       X 
 1                          | X
 2                          |     X X X

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

    Power_On_Mode = COLD
Configuration_Store_Id = 0xFFFD
IR_Access_Mode = 1
Reset_Mode = 0
Reset_Source = 1
Run_Test()

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

    11.1.5. Конечные автоматы

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

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

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

    (рис 11.2) Структурная схема тестируемого конечного автомата

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

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

    (рис 11.3) Структурная схема тестирующего конечного автомата

    Далее приведен пример определения этого тестирующего автомата в тест-плане. Оно будет выглядеть следующим образом:

    STATES DEFINITION:
State1=Начальное
State2=Передача данных
State3=Обработка ошибки

PASS DEFINITION
Pass1=State1->State2 with function call BeginData(Param1)
Pass2=State2->State2 with function call SendData(Param1)
….
Pass5=State2->State3 external with function call ErrorReceived(Message)

    В разделе STATES DEFINITON определены все состояния тестирующего автомата, в разделе PASS DEFINITION - переходы между состояниями. Переход из состояния M в состояние N определяется выражением StateN->StateM. При переходе вызывается функция тестового драйвера, имя которой записывается после строки with function call. Если в функцию должны быть переданы параметры, их имена указываются в скобках. Если какой-либо переход должен происходить при получении внешнего сообщения, это обозначается ключевым словом external. При этом вызывается функция, обрабатывающая полученное сообщение

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

    TESTCASE 1
  Data:
    begBlock=\027
sndBlock[0]='H'
    sndBlock[1]='i'
    errBlock=0
  Scenario:
    Pass1(begBlock)
    Pass2(sndBlock[0])
    Pass2(sndBlock[1])
    Pass2(errBlock)
    Pass5(message)

    В этом примере в секции Data определяются данные для сообщений, передаваемых автоматом, а в секции Scenario - последовательность переходов по состояниям с передаваемыми данными.

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

    11.1.6. Генераторы тестов

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

    Различают следующие способы генерации тестовых примеров:

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

    Первый способ генерации тестовых примеров приемлем для тестирования системы как "черного ящика", но требует, чтобы тест-требования (или системные/функциональные требования) были подготовлены на специальном формальном языке оформления требований, например, RDL (Requirements Definition Language). Затем по требованиям строятся тестовые примеры, которые проверяют функциональность системы с точки зрения требований, т.е. в этом случае достигается основная цель верификации - проверить, ведет ли себя система в соответствии с требованиями.

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

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

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

    11.2. Отчеты о прохождении тестов

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

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

    По результатам анализа отчетов о прохождении тестов могут быть выявлены либо дефекты в самой системе, либо некорректно составленные или противоречивые требования. В обоих случаях результаты анализа служат основой для создания запросов на изменение требований и/или кода системы. После корректного исправления дефектов при регрессионном тестировании неуспешно выполненные тестовые примеры должны выполниться успешно (Рис 11.4).

    (рис 11.4) Генерация отчета о прохождении тестов и изменения по результатам его анализа

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

    11.2.2. Возможные формы представления отчетов о прохождении тестов

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

    В стандарте IEEE 829 отчет о прохождении тестов разделен на три различных документа и описан в разделах 9 (Test log), 10 (Test incident report) и 11 (Test summary report). В эти разделы включены соответственно общий отчет о прохождении тестов, отчет о проблемах, выявленных в результате выполнения тестов, и общая статистика прохождения тестов. В данном курсе отчет о прохождении тестов считается единым документом, разделенным на три части:

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

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

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

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

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

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

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

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

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

  • Идентификатор тестового примера
  • Перечисление не совпавших ожидаемых и реальных выходных значений тестового примера
  • Для каждой пары "ожидаемое-реальное выходное значение" - информацию о совпадении/несовпадении этих значений
  • Сообщение о том, пройден или не пройден тестовый пример
    •

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

    Завершающая часть отчета о прохождении тестов должна содержать краткую итоговую информацию о выполнении всех тестовых примеров, по которым составлялся отчет.

    Обычно эта часть отчета содержит следующую информацию:

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

    Ниже приведен пример этой части отчета.

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

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

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

    Пример такого раздела приведен ниже:

    11.2.3. Автоматическое и ручное тестирование

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

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

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

    Страницы:

    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

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

Критерий прохождения теста: Все ожидаемые значения 
совпадают с реальными.
    Сценарий тестирования:
    № Шаг сценария Ожидаемый результат
    1 Запустить терминальный клиент и соединиться с системой по адресу 127.0.0.1 Должно появиться приглашение терминала TRANSFER>
    2 Запустить процесс передачи данных при помощи ввода команды SEND DATA Должно появиться приглашение DATA TRANSFER INITIATED и следующими двумя строками
    Enter your credentials…
Login:
    3 Ввести имя учетной записи default Должна появиться строка Password:
    4 Ввести пароль default Должно появиться сообщение
    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)

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

    11.1.4. Таблицы

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

    '                          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

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

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

    +-------------+
INPUTS:                     | a b c d e f |
----------------------------+-------------+
Power_On_Mode               |
 COLD                       | X X       X 
 WARM                       |     X X X
Configuration_Store_Id      |
 0xFFFD                     | X X X X X X 
IR_Access_Mode              |
 1                          | X X X     X 
 0                          |       X
 0xFFFF                     |         X
Reset_Mode                  |
 0                          | X X X X X X 
Reset_Source                |
 0                          |   X       X 
 1                          | X
 2                          |     X X X

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

    Power_On_Mode = COLD
Configuration_Store_Id = 0xFFFD
IR_Access_Mode = 1
Reset_Mode = 0
Reset_Source = 1
Run_Test()

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

    11.1.5. Конечные автоматы

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

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

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

    (рис 11.2) Структурная схема тестируемого конечного автомата

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

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

    (рис 11.3) Структурная схема тестирующего конечного автомата

    Далее приведен пример определения этого тестирующего автомата в тест-плане. Оно будет выглядеть следующим образом:

    STATES DEFINITION:
State1=Начальное
State2=Передача данных
State3=Обработка ошибки

PASS DEFINITION
Pass1=State1->State2 with function call BeginData(Param1)
Pass2=State2->State2 with function call SendData(Param1)
….
Pass5=State2->State3 external with function call ErrorReceived(Message)

    В разделе STATES DEFINITON определены все состояния тестирующего автомата, в разделе PASS DEFINITION - переходы между состояниями. Переход из состояния M в состояние N определяется выражением StateN->StateM. При переходе вызывается функция тестового драйвера, имя которой записывается после строки with function call. Если в функцию должны быть переданы параметры, их имена указываются в скобках. Если какой-либо переход должен происходить при получении внешнего сообщения, это обозначается ключевым словом external. При этом вызывается функция, обрабатывающая полученное сообщение

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

    TESTCASE 1
  Data:
    begBlock=\027
sndBlock[0]='H'
    sndBlock[1]='i'
    errBlock=0
  Scenario:
    Pass1(begBlock)
    Pass2(sndBlock[0])
    Pass2(sndBlock[1])
    Pass2(errBlock)
    Pass5(message)

    В этом примере в секции Data определяются данные для сообщений, передаваемых автоматом, а в секции Scenario - последовательность переходов по состояниям с передаваемыми данными.

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

    11.1.6. Генераторы тестов

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

    Различают следующие способы генерации тестовых примеров:

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

    Первый способ генерации тестовых примеров приемлем для тестирования системы как "черного ящика", но требует, чтобы тест-требования (или системные/функциональные требования) были подготовлены на специальном формальном языке оформления требований, например, RDL (Requirements Definition Language). Затем по требованиям строятся тестовые примеры, которые проверяют функциональность системы с точки зрения требований, т.е. в этом случае достигается основная цель верификации - проверить, ведет ли себя система в соответствии с требованиями.

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

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

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

    11.2. Отчеты о прохождении тестов

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

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

    По результатам анализа отчетов о прохождении тестов могут быть выявлены либо дефекты в самой системе, либо некорректно составленные или противоречивые требования. В обоих случаях результаты анализа служат основой для создания запросов на изменение требований и/или кода системы. После корректного исправления дефектов при регрессионном тестировании неуспешно выполненные тестовые примеры должны выполниться успешно (Рис 11.4).

    (рис 11.4) Генерация отчета о прохождении тестов и изменения по результатам его анализа

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

    11.2.2. Возможные формы представления отчетов о прохождении тестов

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

    В стандарте IEEE 829 отчет о прохождении тестов разделен на три различных документа и описан в разделах 9 (Test log), 10 (Test incident report) и 11 (Test summary report). В эти разделы включены соответственно общий отчет о прохождении тестов, отчет о проблемах, выявленных в результате выполнения тестов, и общая статистика прохождения тестов. В данном курсе отчет о прохождении тестов считается единым документом, разделенным на три части:

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

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

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

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

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

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

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

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

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

  • Идентификатор тестового примера
  • Перечисление не совпавших ожидаемых и реальных выходных значений тестового примера
  • Для каждой пары "ожидаемое-реальное выходное значение" - информацию о совпадении/несовпадении этих значений
  • Сообщение о том, пройден или не пройден тестовый пример
    •

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

    Завершающая часть отчета о прохождении тестов должна содержать краткую итоговую информацию о выполнении всех тестовых примеров, по которым составлялся отчет.

    Обычно эта часть отчета содержит следующую информацию:

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

    Ниже приведен пример этой части отчета.

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

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

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

    Пример такого раздела приведен ниже:

    11.2.3. Автоматическое и ручное тестирование

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

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

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^