Ўзбекистон республикаси ахборот технологиялари ва коммуникацияларини ривожлантириш вазирлиги муҳаммад ал-хоразмий номидаги

Рис. 14 Структурная схема тестирующего конечного автомата 
Далее приведен пример определения этого тестирующего автомата в тест-плане. Оно 
будет выглядеть следующим образом: 
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: 

---

122 
Pass1(begBlock) 
Pass2(sndBlock[0]) 
Pass2(sndBlock[1]) 
Pass2(errBlock) 
Pass5(message) 
В этом примере в секции Data определяются данные для сообщений, передаваемых 
автоматом, а в секции Scenario – последовательность переходов по состояниям с 
передаваемыми данными. 
При тестировании конечных автоматов при помощи обычных тестирующих классов 
можно использовать аналогичный подход. 
1.1.6. Генераторы тестов 
В некоторых случаях для упрощения процедуры тестирования используются 
специальные инструментальные средства, автоматически генерирующие тестовые примеры. 
Эти системы различаются по используемым методам генерации тестовых примеров, а 
получаемые тестовые примеры различаются по областям применимости. 
Различают следующие способы генерации тестовых примеров: 

по формализованным требованиям; 

случайным образом; 

по программному коду. 
Первый способ генерации тестовых примеров приемлем для тестирования системы как 
«черного ящика», но требует чтобы тест-требования (или системные/функциональные 
требования) были подготовлены на специальном формальном языке оформления 
требований, например RDL (Requirements Definition Language). Затем по требованиям 
строятся тестовые примеры, которые проверяют функциональность системы с точки зрения 
требований, т.е. в этом случае достигается основная цель верификации – проверить, ведет ли 
себя система в соответствии с требованиями.
К сожалению, этот путь достаточно трудоемок и экономия времени от автоматической 
генерации тестов зачастую сводится на нет необходимостью в выделении дополнительного 
времени на перевод всех требований в формальную форму. В связи с этим рекомендуется 
применять данный метод только для тестирования систем, требования на которые могут 
быть сравнительно легко формализованы с использованием того или иного языка, например, 
системы поддержки коммуникационных протоколов. 
Второй метод генерации тестовых примеров – на основе случайных данных. В этом 
случае не может идти и речи о систематизированном тестировании и гарантиях качества 
системы. Такой подход может применяться только в случае необходимости проверить 
поведение системы в случае передачи в нее большого количества неверных данных или 
определить количественные параметры поведения системы под большой нагрузкой. 
Третий метод тестирования основан на анализе исходных текстов системы и построения 
тестов, которые выполняют каждое логическое условие и каждый оператор системы. В 
результате достигается очень высокий уровень покрытия программного кода. Однако, в этом 
случае тесты проверяют не то, что система должна делать в соответствии с требованиями, а 
то, как она делает то, что уже запрограммировано. Перед тестировщиком в этом случае стоит 
задача анализа программного кода системы на соответствие требованиям, что зачастую 
представляет собой задачу не менее сложную, чем ручное написание тестов для проверки 
требований. Обычно рекомендуется вначале написать все тесты по требованиям, а затем, в 
случае необходимости, воспользоваться генератором тестов по программному коду. При 
этом целью использования генератора будет не достижение максимально возможного 
покрытия любой ценой, а анализ причин непокрытия при выполнении тестов требований, и, 
в случае необходимости, коррекции требований. 

---

123