Методика тестирования конформности реализаций протоколов информационного обмена

Размещено на http://www.allbest.ru/

Методика тестирования конформности реализаций протоколов информационного обмена

Авторы:

Еременко В.Т., Богачев Д.Г.

This article is about conformance testing method protocols of informational exchange and conceptual architecture of the attestation testing process.

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

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

К разработанным методам тестирования относятся:

- тестирование конформности (соответствия) или аттестационное тестирование;

- тестирование производительности;

- тестирование совместного функционирования;

- тестирование взаимодействия;

- тестирование функциональности;

- мониторинг.

Тестирование на соответствие (конформности) заданной спецификации (аттестационное тестирование) является наиболее стандартизированным и широко распространенным методом проверки корректности реализации протокола. Стандартизация тестирования конформности осуществляется международными организациями ETSI, ITU-T и ISO. Основным стандартом является стандарт ISO 9646, главная идея которого состоит в том, что спецификации каждого протокола должны содержать комплект тестовых сценариев его проверки. Вследствие своей узкоспециальной направленности эти комплекты не являются общедоступными и, как правило, бесплатно не распространяются. Такой тестовый комплект состоит из отдельных тестовых сценариев, каждый из которых проверяет определенную функцию из спецификации протокола. Результат выполнения сценария получает одно из трех значений: успешное (passed), неубедительное (inconclusive) или неудачное (failed).

Рекомендация МСЭ-Т X.290 делит все требования конформности какой-либо рекомендации по протоколу на две группы - требования к статическому соответствию и требования к динамическому соответствию.

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

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

Аттестационное тестирование включает проверку тестируемой реализации требований как к статическому, так и к динамическому соответствию. Аттестованной признается система, удовлетворяющая всем указанным требованиям к соответствию.

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

При выборе архитектуры тестирования обычно учитывается два основных фактора:

1) тестируемая реализация должна рассматриваться как «черный ящик», т. е. без учета ее внутренней структуры;

2) система тестирования должна быть распределенной и обеспечивать возможность тестирования из удаленной ЭВМ. Следствием этих факторов явилось то, что разрабатываемые архитектуры тестирования сами, в свою очередь, основыва-ются на эталонной модели взаимодействия открытых систем.

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

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

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

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

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

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

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

Концептуальная архитектура процесса тестирования протоколов взаимодействия открытых систем приведена на рис. 2.

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

Инструментальным средством для такого тестирования весьма удачно служит специализированный язык написания тестов TTCN. TTCN является абстрактной нотацией для написания тестовых сценариев и стандартизирован ETSI и ISO, как часть стандарта ISO 9646. Для получения исполняемого файла с тестовым сценарием требуется специальный компилятор, который зависит от типа прибора (т.е. компилятор TTCN одной системы тестирования не совместим ни с какими другими системами).

Литература

стандартизированный протокол информационный

1.Аничкин, С.А. Протоколы информационно-вычислительных сетей [Текст]: справочник / С.А. Аничкин, С.А. Белов. - М.: Радио и связь, 1990.- 504 с.

2.ITU-T Recomendation X.290-1993. OSI conformance testing methodology and framework for protocol recommendations for CCITT applications.

3.ISO 9646-1-1994. Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования.

Размещено на Allbest.ru