Верификация программного обеспечения (стр. 21 )

Сценарии тестирования для автоматического тестирования часто описывают на том или ином языке программирования. Например, методы в тестирующих классах 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)

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

Таблицы

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

'  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()

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

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

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

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

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

Рис. 17 Структурная схема тестируемого конечного автомата

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

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

Рис. 18 Структурная схема тестирующего конечного автомата

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

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: