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

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). Затем по требованиям строятся тестовые примеры, которые проверяют функциональность системы с точки зрения требований, т.е. в этом случае достигается основная цель верификации - проверить, ведет ли себя система в соответствии с требованиями.

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

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

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