WikiDer > TTCN-3

TTCN-3

TTCN-3 (Нотация тестирования и управления тестированием, версия 3) это строго типизированный язык тестирования, используемый в проверка на соответствие коммуникационных систем. TTCN-3 написан ETSI в серии ES 201 873,[1] и стандартизированы ITU-T в серии Z.160.[2]TTCN-3 имеет свои собственные типы данных и может быть объединен с ASN.1, IDL и XML определения типов.

Стандартная организация

Стандарт ITU-T TTCN-3 является частью серии Z и состоит из нескольких частей:

  • Z.161 - Базовый язык, определяющий базовую текстовую нотацию
  • Z.162 - Формат табличного представления (TFT) - способ представления тестов в табличном представлении
  • Z.163 - Формат графического представления (GFT) - способ представить тесты графически с представлением, аналогичным MSC
  • Z.164 - Операционная семантика - Определяет, как выполняется TTCN-3
  • Z.165 - TRI - Определяет API, предоставляемый и необходимый для тестера
  • Z.166 - TCI - Определяет API, предоставляемый и требуемый для тестового контроллера.
  • Z.167 - ASN.1 - Определяет, как использовать типы данных ASN.1 в наборе тестов TTCN-3.
  • Z.168 - отображение IDL в TTCN-3
  • Z.169 - Использование схемы XML с TTCN-3

Языковая организация

Модуль
Контейнер верхнего уровня в наборе тестов - это модуль. Обычно это файл.
Компонент
Компонент - это исполняющая сущность. В компоненте выполняется тестовый пример или функция.
Порт
Компоненты взаимодействуют друг с другом или с ТУС через порты, которые сопоставлены друг другу.
Прецедент
Тестовый пример - это последовательность отправки и получения. Когда сообщение отправляется в SUT (Тестируемая система), может быть получено несколько возможных ответов.
Альтернатива
Поскольку тестовый пример представляет собой последовательность стимулов, за которой следует набор возможных ответов, обозначение включает альтернативы. Это компактный способ перечислить все возможные альтернативы сценария.
Шаблон
При отправке или получении информации значение параметров имеет первостепенное значение. Они должны быть определены при отправке и должны быть проверены при получении. Конструкция шаблона направлена ​​на определение значений параметров при отправке или проверку значений параметров при получении. Поскольку параметры могут быть довольно сложными, определение и проверка значений - это не вопрос одной строки. Шаблон позволяет выполнить сложную проверку в одном операторе, чтобы тестовый пример оставался разборчивым.
Вердикт
Вердикт является результатом выполнения тестового примера. Имеет 5 возможных значений: нет, пройден, несовместим, не пройден, ошибка.

Приложения

TTCN-3 использовался для определения наборов тестов на соответствие ГЛОТОК, WiMAX, и DSRC стандартные протоколы.

В Открытый мобильный альянс приняла в 2008 году стратегию использования TTCN-3 для перевода некоторых тестовых примеров в спецификации тестирования активатора в исполняемое представление.[3]

В АВТОСАР Проект способствовал (2008 г.) использованию TTCN-3 в автомобильной промышленности.[4]

В 3GPP Проект способствовал использованию TTCN-3 в мобильной индустрии.[5]

Архитектура

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

  • TE: TTCN-3 Executable - это исполняемая форма набора тестов.
  • TRI: Интерфейс времени выполнения TTCN-3 - это интерфейс между TE и SUT. Он разделен на 2 части:
    • SA: Системный адаптер
    • PA: Адаптер платформы
  • TCI: Интерфейсы управления TTCN-3 - это интерфейс для управления выполнением теста. Он разделен на:
    • TM: Управление тестированием
    • TL: регистрация тестов
    • CD: Кодирование и декодирование
    • CH: обработка компонентов

Пример кода

Это пример TTCN-3 с его графическим эквивалентом в MSC (Таблица последовательности сообщений).

MSC (диаграмма последовательности сообщений) - представление базового сценария TTCN-3 (Test and Testing Control Notation).
модульTestSystem{// Определяем подтип целого числатипцелое числоmyNewType(0..50)// Объявление типа структуры запроса с 2 полямитипзаписыватьЗапрос{myNewTypeparam1,charstringparam2}// Объявление типа структуры ответа с одним полемтипзаписыватьОтвечать{myNewTypeparam1}// Объявление порта связи на основе сообщенийтиппортcEnv_typeсообщение{изЗапрос;вОтвечать;}// Объявить компонент, на котором будет запускаться тестовый примертипкомпонентsSystem{портcEnv_typecEnv;}// Шаблоны определяют значения исходящих параметров// и проверяем входящие значения параметровшаблонЗапросGood_Req:={param1:=42,param2:="Привет !"};шаблонОтвечатьВсе в порядке:={param1:=0};// Определить testcase1, который будет запускаться в компоненте sSystemпрецедентtestcase1()бежитнаsSystem{// Отправляем сообщение запроса с (42, "привет!") В качестве параметровcEnv.Отправить(Good_Req);// Альтернатива для 2 возможных ответовальт{// Получаем ли мы ответ с параметром 0[]cEnv.получить(Все в порядке){// Вынести вердикт!постановление(проходить)}// Или получаем что-то еще[]cEnv.получить{// Неудачный вердиктпостановление(провал)}}}// Управление выполнением тестовых примеров цепочек частей автоматическиконтроль{варвердиктвердикт1;вердикт1:=выполнять(testcase1());}}

Смотрите также

Рекомендации

внешняя ссылка