ГОСТ Р ИСО/МЭК 9646-2-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 2. Спецификация комплекта абстрактных тестов

Обозначение:

ГОСТ Р ИСО/МЭК 9646-2-93

Наименование:

Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 2. Спецификация комплекта абстрактных тестов

Статус:

Действует

Дата введения:

30.06.1994

Дата отмены:

Заменен на:

Код ОКС:

35.100

Скачать ГОСТ Р ИСО/МЭК 9646-2-93.pdf Скачать ГОСТ Р ИСО/МЭК 9646-2-93.doc

Текст ГОСТ Р ИСО/МЭК 9646-2-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 2. Спецификация комплекта абстрактных тестов

ГОСТ Р ИСО/МЭК 9646-2-93

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ.

МЕТОДОЛОГИЯ И ОСНОВЫ АТТЕСТАЦИОННОГО ТЕСТИРОВАНИЯ

ЧАСТЬ 2

СПЕЦИФИКАЦИЯ КОМПЛЕКТА АБСТРАКТНЫХ ТЕСТОВ

Издание официальное

ГОССТАНДАРТ РОССИИ Москва

ГОСТ Р НСО МЭК 9546-2-93

Предисловие

I РАЗРАБОТАН И ВНЕСЕН Техническим: комитетом ТК 22 «Ик-формацкониая технология»

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 20.12.93 № 262

Настоящий стандарт подготовлен на основе применения аутентичного текста международного стандарта ИСО/МЭК 9646—2—91 «Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 2. Спецификация комплекта абстрактных тестов»

3 ВВЕДЕН ВПЕРВЫЕ

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Госстандарта России

ГОСТ P ИСО/МЭК 96-16-2—03

СОДЕРЖАНИЕ

Назначение -..............

Нормативные ссылки....

Определения ..............

Сокращения

Согласованность

Требовании к соответствию международным стандарт ИСО и р?н^

Че-ила ииях JMKKTT . ............

6.1 Введение . . ............

6 2 Общие требования....

6 3 Рад,дели по соответствию..... .....

Требования к форме ЗСРП

Процесс разработки компактов абстрактных тестов, при подпиши к

ci анзартам ко аттестационному тестированию ....

Грсбокпнкя К ГПОТЦСГЦТВИЮ И форма ЗСРП

Структура гсстов>0го комплекта Я цели тестирований

I IM 1'2

ft 9

12 : <

Основные 1p«6otDRHM . . . . .

Спецификация структуры тес-ToBcito комплекта . Сисинфиняимя имей тестирования

ИМ Сфера действии

10 5 Раздел о соответствии СТКиЦТ

I*> 4

CitcusipHKsiiHfl oGuuu тестовых комплектов Методы абстрактного тестировали* 12.1 Введение

12 2 Общие принципы , . .

12 2 1 Нижи не тестеры

12.2.2 Верхние тестеры ....

12.3 Общая спецификация методов оконечных систем

аСк-тра ктиогп тестирования для TP

г 2 3-1

12 3.2

12 3.3

6 2.3 5

Введение . . ...

Метол локального тестирования

Метел распределенного тестирования

Метол СКООрдинИрОВаННОГО тогтирплаиич Метод удаленного тестирования .

1236 Одноуровневый и агтроекный варианты .

12.4 Варианты <|ДНОПрОТОКС»Л1.яых ТР . _ .

12.1.1 Введение .....

12.4.2 Метод локального одноуровневого -тестирования

12.4.3 Метод рагпредсмеиного одноуровневого тестирования .

12 4 4 Метод сконрлнняропэииого одноуровневого тестирования

12 4.5 Метод удаленного одноуровневого тестирования

12 5 Варианты мнигопротокалысых ТР ......

(2.3.1 Вмени?......... . .

125? Метол тестирования ЛОВ . . . . ...

12 5 3 Метод тестирования РОВ.

125.1 Метол тестирования СОВ......

125.5 Метол тестирования УОВ ........

126 Методы тестирования открытых ретрансляционных систем .

12 6 I Введсиис ....

1?5 2 Метод тестирования по шлейфу .....

■ 2 6 3 Метол поперечяпгл тестяроваяия .

2-1

. 28

. 30

. 31

ГОСТ Р ИСО/МЭК 964 6-2-93

12.7 Выбор метода абстрактного тестирования.....

12.7.1 Введение............

12.7 2 Услуга исчерпывающего тестировакия . . . .

12.73 Функциональная среда ТР . ......

1274 Применимость методов абстрактного тестировании .

12.8 Процедуры скоординированного тестирования . . . .

Спецификация комплектов абстрактных тестов

13.1 Общие положен нм ...........

13.2 Тестовые примеры .........

13.3 Раздел соответствия КАТ..........

13 4 Совместимость с протоколом.........

Спецификация ПАУТ............

Использование специфика цик комплекта абстрактных тестов

Обслуживание тестового комплекта . ПРИЛОЖЕНИЯ

Требования к форме ЗСРП и руководящие материалы по ее заполне кию..................

А.1 Введение .... . . .......

А.2 Взаимоотношения между формами ЗСРП и требованиями к соот

A.I

АЗ

Л!

ветствню

Обидее построен не .

Авторские право

А.5 Тлава первая Идентификация реализации

А.6

А.7

А.»

А 9

Глава вторая. Идентификация протокола.....

Глобальная констатация соответствия......

Другие главы. Функциональные возможности . . . .

А 8.1 Введение -...........

АД? Функциональная возможность *ннкина7ор/отогтчнк» ■ А.8.3 Основные функциональные возможности , . . .

А.8.4 Тайм-ауты и параметры протокола......

A.8.S Протокольные блоки данных.......

А.8Л Параметры ПБД . . ........

ЛАТ Возможности согласования........

А.8 8 Обработка протокольных ошибок .....

А.8.9 Многоуровневые зависимости.......

А й Ю Прочие условия...........

Форматы таблиц ............

А.9.1 Структура таблиц..........

А.9 2 Символы н соглашения.........

А.9 3 Инструкции по- заполнению формы ЗСРП . . . .

Руководство зля разработчиков протоколов по облегчению процесса

аттестационного

B.J

В 2 в.з В 1 В.5 В.б В 7 в.8

Введение

Руководство Руководство Руководство Руководство Руководство Руководство

тестирования

по по по ПО ПО по

Прочие руководства

назначению и области применения . . . .

нормативным ссылкам .....

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

состояниям .......... методам формализованного описания .

Неполные требования к статическому соответствию .

Руководство по общим тестовым примерам D I Введение...........

59-

ГОСТ Р ИСО/МЭК «<>46—2—93

D 2 Описание общих ютовых примеров.........59

D 3 Отношение общего тестового примера к абстрактному .... 59

D.4 Образование абстрактных тестовых примеров из общих тестовых примеров......... . . 59

ГОСТ Р ИСО МЭК 9Мв~2—ВЗ

ВВЕДЕНИЕ

Настоящий стандарт определяет общий подход к спецификации комплектов аттестационных тестов ВОС на том уровне, который не зависит от средств выполнения этих тестовых комплектов (далее—комплекты аттестационных тестов). Этот уровень абстрагирования подходит для стандартизации и обеспечивает сопоставимость результатов, получаемых различными организациями, которые осуществляют прогон соответствующих комплектов выполнимых тестов.

В разделах 6 и 7 напоминается, что к разработчикам протоколов ВОС предъявляются требования, которые должны быть выполнены. прежде чем может быть создана объективная основа для процесса разработки комплекта абстрактных тестов. Выражена необходимость иметь согласованные разделы по соответствию и формы ЗСРП в тех стандартах к рекомендациях МККТТ. которые определяют стандарты по протоколам ВОС.

В разделах Я—16 описан процесс разработки комплекта абстрактных тестов, включая необходимый для использования критерий р-азроботки и руководство по его структуре и области применения:. Определены возможные методы абстрактного тестирования и приведено руководство, помогающее разработчикам тестового комплекта выбрать необходимый (ые) метод(ы) составления конкретного тестового комплекта. Приведены требования и руководство по спецификации абстрактных тестовых примеров. Сюда относится разделение тестовых примеров на тестовые таги и назначение вердиктов результатам тестирования.

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

В стандарте приведены руководящие материалы и требования к обслуживанию тестовых комплектов.

Настоящий стандарт опубликован также МККТТ в виде рекомендации X. 291 (1991).

ГОСТ Р ИСО/МЭК 9646-2—91

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ. МЕТОДОЛОГИЯ и основы АТТЕСТАЦИОННОГО ТЕСТИРОВАНИЯ.

Часть 2 СПЕЦИФИКАЦИЯ КОМПЛЕКТА АБСТРАКТНЫХ ТЕСТОВ

Information technology Open Systems. Interconnection Confo/mance Testing Methodology and Framework Pari 2. Abstract lest suite specification

Дата введения IМИ-1)7-Ot

I НАЗНАЧЕНИЕ

l.L Настоящий стандарт устанавливает требования и содержит руководящие материалы по составлению комплектов аттестационных системно-независимых тестов для одного или нескольких стандартов или рекомендаций МККТТ по ВОС. В частности, они применимы к разработке всех стандартов по аттестационному тестированию протоколов ВОС и ISDN, состоящих из двух частей, включая все версии проектов таких стандартов по аттестационному тестированию.

1.2 Настоящий стандарт применим также к составлению примеров аттестационных тестов по проверке точности выполнения некоторой реализацией соответствующих требований к статическому и/кли динамическому соответствию путем контроля и наблюдения поведения протокола. Методы абстрактного тестирования, содержащиеся в настоящем стандарте, фактически можно использовать для спецификации любого тестового примера, который может быть выражен абстрактно в понятиях контроля и наблюдения протокольных блоков данных и абстрактных сервисных примитивов. Несмотря на это, для некоторых протоколом могут потребоваться тестовые примеры, которые не могут быть выражены в этих понятиях. Спецификация таких тестовых примеров не входит & предмет рассмотрения настоящего стандарта, хотя .может оказагь-

Изданме официальное

ТОСТ Р ИСОМЭК W8-2-W

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

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

1.3 Настоящий стандарт не рассматривает:

а) соотношение между спецификацией абстрактных тестовых компл ектов и методам и* формализованного описания;

Ь) тестирование методами, специфичными для конкретных применений, протоколов или систем, включая тестирование непрото-мольных требований к соответствию;

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

П ри хеч а я не— Настоящий стандарт полностью применим к некоторым, но не осе ' протокола'- физического-уровня. Однако многие wo положения применимы хо всем протоколам

2 НОРМАТИВНЫЕ ССЫЛКИ

Нижеперечисленные стандарты содержат положения, которые путем ссылок на них в Данном тексте образуют положения настоящего -стандарта. Все ссылки предполагают последнее издание указанных стандартов. Комитеты— члены МЭК и ИСО имеют списки международных стандартов, действующих на текущий момент.

ГОСТ 28906-91 (ИСО 7 498 84. ИСО 7498—84 Дон. 1—84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. (См. также рекомендацию Х.200 МККТТ).

ИСО/ТО 8509 87 Системы обработки информации. Взаимосвязь открытых систем. Соглашения по услугам. (См также ре-комеядацию X.210 МККТТ)’.

ГОСТ 34.974—91 (ИСО 8825—87) Системы обработки информации. Взаимосвязь открытых систем. Спецификация базовых правил кодирования для абстрактно-синтаксической мотании версии один (ACH.I). (См. также рекомендацию X 209 МККТТ).

ГОСТ Р ИСО/МЭК 9646—1—93 Информационная технология. Взаимосвязь открытых систем Методология и основы аттестационного тестирования. Часть I. Общие принципы. (См. также рекомендации» X.290 МККТТ).

• До прмеско применения данного документа в качестве государственного станларта распространение его осуществляет секретариат ТК 22 «Информационная технолог я

ГОСТ Р ИСО/МЭК 9*46-2-93

ИСО/МЭК 9646—3 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 3. Комбинированная-древовидная и табличная нотация. (См. также рекомендацию X. 292 МККТТ)’.

3 ОПРЕДЕЛЕНИЯ

Определения терминов, используемых в настоящем стандарте. - по ГОСТ Р ИСО/МЭК 9646-1.

4 СОКРАЩЕНИЯ

В настоящем стандарте используются сокращения по I ОСТ Р ИСО/МЭК 9646—1, а также следующие сокращения:

МЛОВТ — метод локального одноуровневого встроенного тестирования,

МЛ ОТ — метод локального одноуровневого тестирования,

МПТ — метод поперечного тестирования,

МРОВТ — метод распределенного одноуровневого встроенного тестирования,

МРОТ — метол распределенного одноуровневого тестирования.

МСОВТ — метод скоординированного одноуровневого встроенного тестирования.

AJCOT — метод скоординированного одноуровневого тестирования.

МУОТ — метод удаленного одноуровневого тестирования,

МУОВТ — метод удаленного одноуровневого встроенного тестирования,

МФО — метол формализованного описания,

МШТ — метод шлейфового тестирования,

СТКиЦТ — структура тестового комплекта л цели тестирования.

5 СОГЛАСОВАННОСТЬ

5.1 Стандарт или рекомендация МККТТ. определяющие протокол в согласованности с настоящим стандартом, должны удовлетворять всем требованиям, установленным в разделах 6, 7 и в приложении А

* До прямого применения данного документа в хашеетш- государственного стаидартз распространение его осуществляет секретариат ГК 22 «Информационная технология»-.

ГОСТ Р ИСОМЭК 9646 -2-W

Примечание — Такая согласованности является предпосылкой того, что спецификация протокола будет эффективной основой для аттестационного те-сгироаания реализаций

5.2 Спецификация комплекта абстрактных тестов, которая согласуется с настоящим стандартом, должна:

а) представлять собой комплект аттестационных тестов;

Ь') быть определена в тестовой нотации, стандарт изованной ИСО/МЭК или МККТТ;

с) удовлетворять всем требованиям, установленным в разделах 9—14;

d) быть представлена в виде стандарта или рекомендации МККТТ либо при отсутствии такого стандарта или рекомендации она должка быть доступным документом, который находится в стадии стандартизации в ИСО/МЭК или МККТТ и имеет статус, по меньшей мере, «проект комитета», «проект рекомендации» или другой эквивалентный статус.

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

5.3 Рекомендуется, чтобы используемая тестовая нотация представляла собой комбинированную древовидную и табличную нотацию (КДТН). При использовании КДТН комплект абстрактных тестов должен удовлетворять всем требованиям ИСО/МЭК 9646—3.

Л р и ” с ч а н и с — Рснэмьчдзцип X 290 (1988) МККТТ считается устарев-шей; для данной цели.

6 ТРЕБОВАНИЯ К СООТВЕТСТВИЮ МЕЖДУНАРОДНЫМ СТАНДАРТАМ ИСО И РЕКОМЕНДАЦИЯМ МККТТ

6.1 Введение

Смысловое значение соответствия в ВОС рассмотрено в ГОСТ Р ИСО/МЭК. 9646—1. Как предпосылка к составлению комплекта абстрактных тестов необходимо недвусмысленное и объективное понимание требований к соответствию спецификациям по протоколам ВОС или по синтаксису передали. В разделах 6 и 7 изложены требования к разработчикам протоколов обеспечивать такое понимание требов-аний к соответствию.

Дополнительные руководящие материалы приведены в приложении В.

6 2 Общие требования

ГОСТ Р ИСО/МЭК 964€-2-9»

6.2.1 Должно Сыть установлено четкое, различие между требованиями к статическому и динамическому соответствию. Для устранения двусмысленности эти требования должны быть определены отдельно друг от друга.

6.2.2 Должно быть четко определено, что означает соответствие национальному, международному стандарту или рекомендации МККТТ, т. е. должно быть указано, что необходимо реализовать, что разрешено, но нс обязательно реализовывать и что не должно быть реализовано для соответствия этим документам.

6.2.3 Всегда должен быть разрешим вопрос: удовлетворяет ли сеанс связи динамическому соответствию или нет?

Например, должна обеспечиваться возможность просмотра записи активности' ПБД н определения ее действительности относительно соответствующего международного стандарта или рекомендации МККТТ.

6.3 Разделы по соответствию

6.3.1 Каждый национальный, .международный стандарт или рекомендация МККТТ по протоколу ВОС и синтаксису передачи должны иметь раздел, содержащий сведения о соответствии, который должен быть сформулирован ясно и недвусмысленно.

6.3.2 Разделы по соответствию должны различаться по следующим категориям в зависимости от содержащейся в них информации:

а) ссылки на разделы, которые устанавливают требования к динамическому соответствию;

Ь) требования к статическому соответствию, касающиеся реализации протокола;

с) требования к статическому соответствию, касающиеся многоуровневых зависимостей.

6.3.3 Требования к разработке ЗСРП в соответствии с формой ЗСРП должны формулироваться отдельно от требовании к реализации самого протокола.

6.3.4 Раздел «Соответствие» должен также содержать:

а) требование обеспечивать возможность приема всех корректных последовательностей ПБД. поступающих от удаленных партнеров, и выдавать в ответ корректные последовательности ПБД;

Ь) требования обеспечивать возможность выдачи корректных ответов на все некор рентные последовательности полученных ПБД;

с) в протоколах режима-с-устаиовлением-соеди нения—факультативные возможности, обеспечивающие либо инициацию соединения, либо принятие соединения, либо то и другое;

ГОСТ Р ИСО МЭК «646-2-9$

(1) в пр отколах режима-без-устамовления-соедннення — факультативные возможности, обеспечивающие либо передачу ПБД, либо прием ПБД. либо то и другое.

7 ТРЕБОВАНИЯ К ФОРМЕ ЗСРП

7.1 Конкретные требования» которые должны соблюдать поставщики в отношении каждой разрабатываемой ими ЗСРП, должны обычно формулироваться в соответствующем стандарте или рекомендации МККТТ по данному протоколу. В спецификацию этих требований должна входить форма ЗСРП. Форма ЗСРП должна содержаться в отдельной части стандарта или рекомендации МККТТ, определяющих данный протокол.

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

7.3- Форма ЗСРП должна охватывать все факультативные и условные функции, элементы процедур, параметры, факультативные возможности, ПБД, таймеры, многоуровневые зависимости и другие функциональные возможности, идентифицированные в спе цкфикации протокола.

Должно иметь место четко определенное отображение (путем ссылки) формы ЗСРП на требования к соответствию

В приложении А содержатся требования н инструкции по составлению формы ЗСРП.

8 ПРОЦЕСС РАЗРАБОТКИ КОМПЛЕКТОВ АБСТРАКТНЫХ ТЕСТОВ. ПРИВОДЯЩИЙ к стандартам по аттестационному

ТЕСТИРОВАНИЮ

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

8.2 Для целей настоящего стандарта предполагается следующий процесс составления комплекта абстрактных тестов:

ГОСТ Р ИСО/МЭК ММв-2—93

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

Ь) решить, какие из тестовых групп будут необходимы для обеспечения соответствующей сферы применения требований к соответствию (см. 10.2);

с) разработать факультативно цели тестовых групп (общие цели тестирования элементов каждой тестовой группы) (см. 10.3);

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

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

() выбрать метод(ы) тестирования, для «оторого(ых) необходимо определить законченные примеры абстрактных тестов и решить, какие ограничения необходимо наложить на характеристики нижнего тестера и (если это соответствует выбранному (ым) методу (ам) тестирования) верхнего тестера и процедур скоординированного тестирования (см. раздел 11);

g) применить стандартную тестовую нотацию для определения набора абстрактных тестовых примеров, включая структуру тех тестовых пгегов, которые должны использоваться (см. раздел 12);

11) определить взаимоотношения;

I) между тестовыми призерами;

2) между тестовыми примерами н ЗСРП и

3) по возможности, между тестовыми примерами и ДИРПТ. для того чтобы определить ограничения, налагаемые на выбор и параметризацию тестовых примеров с целью их выполнения, а также при необходимости ограничения на порядок их выполнения (см. раздел 15);

i) рассмотреть процедуры обслуживания КАТ (см. раздел 16).

8.3 Предполагается также, что в процессе разработки КАТ будет создана и общая структура стандарта(ов) яо аттестационному тестированию с соответствующими частями, включающими:

а) структуру тестовых комплектов и пели тестирования гСТКнИТ) (см. раздел 10);

Ь) факультативно — общий тестовый комплект (см. раздел II);

с) один или несколько КАТ (см. раздел 13) для одного или не-скольких методов абстрактного тестирования (см. раздел 12);

FOCI P ИСО/МЭК 9646-2-93

d) спецификацию ПАУТ (в случае его применимости) (см. раз-дел 14).

8.4 В разделах 9—16 приведены требования и руководящие материалы. относящиеся к каждому шагу описанного выше процесса.

9 ТРЕБОВАНИЯ К СООТВЕТСТВИЮ И ФОРМА. ЗСРП

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

9.2 В разделах 6 и 7 установлены требования, которые должны обеспечить разработчики протоколов в качестве предпосылки к составлению комплекта абстрактных тестов для конкретного протокола.

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

10 СТРУКТУРА ТЕСТОВОГО КОМПЛЕКТА И ЦЕЛИ ТЕСТИРОВАНИЯ

10.1 Основные требования

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

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

ГОСТ Р НСО/МЭК 9646-2-93

скольких тестовых комплектах или тестовых группах. Сходные тестовые группы могут содержаться в нескольких тестовых группах или в тестовых комплектах вышерасположенного уровня.

J0.I.3 Разработчик комплекта абстрактных тестов должен обеспечить. чтобы один поднабор целей тестирования каждого комплекта абстрактных тестов был связан с тестированием функциональных возможностей, а другой поднабор — с тестированием поведения. Это не обязательно должно приводить к различным тестовым примерам для тестирования поведения и функциональных возможностей, так как не исключена возможность использования одних и тел же тестовых шагов для целей тестирования как поведения, так и функциональных возможностей. Разработчик комплекта абстрактных тестов должен дать разъяснение, каким образом цели тестирования вытекают из спецификации по протоколу или как они с нею связаны. Разработчик тестового комплекта должен также обеспечить перечень сфер действия, охватываемых тестовым комплектом.

10.2 Спецификация структуры тестового комплекта

10.2.1 Чтобы гарантировать, что результирующий комплект абстрактных тестив обеспечивает адекватную сферу действия рассматриваемых требований к соответствию, разработчику тестового КОМП-ieKTS рекомендуется построить структуру тестового ком илек-та в виде гнездующихся тестовых групп метолом нисходящего проектирования.

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

а) тесты функциональных возможностей (для требований к ста т и ч ескому с оот ветст ви ю);

Ь) тесты поведения, относящиеся к действительному поведению;

с) тесты поведения, которые оценивают реакцию ТР на недействительные тестовые события: их можно подразделить на тесты, кас&юшиеся синтаксически недействительных тестовых событий, семантически недействительных тестовых событий и несвоевременных тестовых событий относительно рассматриваемого протокола;

<1) тесты, ориентированные на ПБД, передаваемые в ТР;

с) тесты, ориентированные на ПБД. принимаемые из ТР;

ГОСТ Р ИСО/МЭК 9М8-2-93

I) тесты, ориентированные на взаимодействия между передаваемыми и принимаемыми ПБД;

g) тесты, относящиеся к каждой обязательной возможности;

h) тесты, относящиеся к каждой факультативной возможности;

i) тесты, относящиеся К каждой фазе протокола;

j) изменения в тестовом событии, происходящие в конкретном состоянии;

к) изменения таймироваипя и таймера;

I) изменения о кодировании ПБД;

т) изменения значений отдельных параметров;

п) изменения сочетаний значений параметров.

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

10.2 2 Следующая структура, приводимая в качестве руководящего пособия, представляет собой пример одноуровневого тестового комплекта;

А Тесты функциональных возможностей

А I Обязательные характеристики

А.2 Факультативные характеристики

В Тесты поведения: реакция на действительное поведение со стороны удаленной реализации

В I Фаза установления соединения (если выполняется)

В. 1.1 Ориентация на содержимое -передачи в ТР

В. 1.1.1 Изменение тестового события в каждом состоянии

В. 1.1.2 Изменение таймировання/таймера

В. 1.1.3 Изменение кодирования

В. 1.1.4 Изменение значений отдельных параметров

В.1.1.5 Сочетание значений параметров

В.1.2 Ориентация на содержимое приема из ТР (пункты аналогично В. 1.1)

В. 1.3 Ориентация па взаимосвязи (пункты аналогично В.1.И

В.2 Фаза передачи данных (пункты аналогично В.1)

В.З Фаза разъединения соединения (если она выполняется) (пункты аналогично В.1)

гост р исо.мэк аде-2—»з

С Тесты поведения: реакция на синтаксически или семантически недействительное поведение со стороны удаленной реализации

С.1 Фаза установления соединения {если она выполняется)

С. 1.1 Ориентация на содержимое передачи в ТР

С. 1.1.1 Изменение тестового события в каждом состоянии

С. 1.1.2 Изменение кодирования недействительного события

С.1.1.3 Изменение значения отдельною недействительного параметра

С. 1.1.4 Изменение сочетания значений недействительных параметров

С. 1.2 Ориентация на содержимое, запрашиваемое ТР для передачи

С. 1.2.1 Значения отдельного недействительного параметра

С. 1.2.2 Недействительные сочетания значений параметров

С.2 Фаза передачи данных (пункты аналогично С.1>

С.З Фаза разъединения соединения (если она выполняется) (пункты аналогично С.1)

D Тесты поведения; реакции на несвоевременные события со стороны удаленной реализации

D.I Фаза установления соединения (если она выполняется) D.1.1 Ориентация на содержимое передачи в ТР

О 1.1.1 Изменение тестового события в каждом состоянии

D. 1.1.2 Изменение таймнрования/таймера

D. 1.1 3 Изменения специального кодирования

D.1.1.4 Изменения значения отдельного основного параметра

D.I.I.5 Изменение Основного сочетания значений параметров

D.1.2 Ориентация на содержимое, запрашиваемое ТР для передачи (пункты аналогично П.1.1)

D.2 Фаза передачи данных (пункты аналогично D.U

D.3 Фаза разъединения соединения (■если она выполняется) (пункты аналогично D.I)

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

ГОСТ Р ИСО'МЭК 9М6-Г-93

ведения, но нс должны преследовать никаких дополнительных целен тестирования.

10.3. С нецифнк а ци я целей тестирования

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

Цели тестирования могут быть сформулированы непосредственно в результате изучения тех разделов рассматриваемон(ых) спецификации (ий), которые относятся к соответствующей тестовой группе. Для некоторых тестовых групп цели тестирования могут быть сформулированы непосредственно из таблицы состояния протокола, для других—из определений кодов ПБД или олисэ* ний конкретных параметров, либо из текста, в котором определяются соответствующие требования к соответствию.

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

Л р н я о ч э н и с — Если разработчик тестовые комплекта реализует формализованное описание рассматриваемого (ых) протокола (ой >. то вели тестирования моги быть получены из него г помощью некоторых зятоматизнрожаи-ных методов. При использовании звтома тизиронаиных методой применимы те же требования Однако е годы, основанные иа формализованном описании, и входят з предмет рассмотрения настоящего стандарта Тем яс истее если для этой цели должен иелольховагься МФО. то же-тлтсльно. чтобы он был стандартный

10 3 2 С целью повышения эффективности тестирования отдельных параметров одного ПБД для одного абстрактного тестового примера могут быть определены комбинированные цели тестирования. Цели'тестирования для недействительного значения пара-

ГОСТ Р ИСО/МЭК 9И&-2—93

метра не должны объединяться с другими целями тестирования действительных или недействительных значений.

10.3.3 Как часть процесса построения СТКиЦТ предложено, чтобы вначале были идентифицированы цели тестирования для каждого конкретного параметра, подлежащего тестированию. На втором этапе могут быть определены комбинации целей тестирования отдельных параметров, относящихся к одному и тому же ПДБ. Если этот этап выполняется, то:

а) должна быть записала комбинированная цель тестирования, объединяющая отдельные цели тестирования и ссылающаяся на мил;

Ь) должно быть дано указание на необходимость разработки для такой номинированной цели тестирования одного абстрактною тестового примера, а не отдельных тестовых примеров для каждой из отдельных объединяемых целей тестирования;

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

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

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

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

П р и м о ч а и н е--Цели тестирования для нетестируемых требований пред-назначены зля информирования разработчика протокола о тех требованиях к соответствию, которые нексгнруемы, указывая пробелы в стандартизованных КАТ

10.4 Сфера действия

Можно пояснить термин «адекватная сфера действия» ссылкой на пример структуры тестового комплекта, приведенный в 102.

2 Зэк. 249

ГОСТ Р МСОМЭК Ш6-2—93

Для этого следует использовать краткие обозначения: буква «х» представляет все соответствующие значения первой цифры в идентификаторе тестовой группы, буква «у» — второй цифры, таким образом, что В.х.у.1 будет обозначать В. 1.1.1. В. 1.2.1, В. 1.3.1, B.2.IJ. B.2.2.I. В.2.3.1, B.3.1.I, В.3.2.1 и В.3.3.1.

При использовании таких обозначений минимальная «адекватная сфера действия» для приведенного выше примера рассматривается следующим образом:

а) для тестовых групп, относящихся к функциональным возможностям (А.1. Л.2):

I) по меньшей мере, одна цель тестирования на каждую соответствующую функциональную возможность;

2) по меньшей .мере, одна цель тестирования на каждый рассматриваемый тип ПБД н каждое основное изменение каждого такого типа с использованием для каждого параметра «нормального» значения или значения по умолчанию;

Ь) для тестовых групп, относящихся к изменению тестового события н каждом состоянии (B.x.y.l, C.x.l.l. D.x.y.l), по меньшей хере, одна цель тестирования на каждое рассматриваемое сочетание состояние/событие.

с) для тестовых групп, относящихся к таймерам и таймкрова-нию (В х.у.2. D.x.y.2), по меньшей мере, одна цель тестирования, относительно истечения каждого определенного таймера;

d) для тестовых групп, относящихся к изменениям кодирования (В.х-у.3, С.х.1-2, D.x.y.3), по меньшей мере, одна цель тестирования для каждого рассматриваемого вида изменения кодирования на каждый соответствующий тип ПБД;

е) для тестовых групп, относящихся -к действительным значениям отдельного параметра (В.х.у.4, D.x.y.4):

1) для каждого рассматриваемого целочисленного параметра те цели тестирования, которые относятся к значениям границы я к одному произвольно выбранному значению из среднего диапазона;

2) для каждого рассматриваемого параметра битового кодирования цели тестирования, для такого количества значений, которое практично для использования, но не меньше числа всех «нормальных» или общих значений;

3) для остальных рассматриваемых параметров, по меньшей мере, одна цель тестирования, относящаяся к значению, отличному от тех, которые считаются «нормальными», и от значений по умолчанию в других тестовых группах.

ГОСТ Р ИСОЛМЭК 9616-2-93

При«ечзние-Тепы действительных значений параметров должны Hurt, сфокусированы на соответствующих заявках, сделанных и ЗСРП:

f) для тестовых групп, относящихся к недействительным значениям отдельного параметра (С.х.1.3. С.х.2.1) ;

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

2) для каждого рассматриваемого параметра битового кодирования те цели тестирования, которые относятся к такому количеству недействительных значений, которое практично дли использования;

3) для всех остальных рассматриваемых параметров типов, по меньшей мере, одна цель тестирования на каждый параметр.

Примечание—Тесты для недействительных значений параметров должны фокy4iHpcjBart.cn из .значениях, не входящих Л диапазон значений, определенный в соответствующей спецификации протокола, а не ил дейпнигелыгых значениях. не входящих в диз-лззон. заявленным в ЗСРП;

g) для тестовых групп, относящихся к комбинациям значений параметров- (В.х.у.5. С.х.Н, С.х.2.2, D.x.y.5):

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

2) по меньшей мерс, одна цель тестирования на набор взаимосвязанных параметров для тестирования произвольной комбинации рассматриваемых значений.

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

2^е

ГОСТ Р ИСО МЭК 9646-2-93

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

При меча н кс—Ра’витке работ по созданию формализованных «столов я области аттестационного тестирований может овеспечигь аналитические «сто. „ты оценки соответствующей сферы действия КАТ. особенно и случае вариаций согтоякнсхобыгнс. отмеченных выше в Ь) Однако я настоянием стандарте <и-сугстзуют рекомендации по каким-либо аналитическим методам.

105 Раздел о соответствии СТКиЦТ

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

а) содержал набор тестовых примеров, соответствующий набору или поднаберу целей тестирования, определенных в этой части СТКиЦТ;

Ь) использовал структуру тестовых комплектов, которая является соответствующим подмножеством всей структуры тестовых комплектов, определенных в части СТКиЦТ.

По имея анис — Только ли иоамиожгетво структуры тестовых комплектом, которое должно иметь место, опушено в тех целях тестирования, которые являются нетестируемыми в выбранном методе абстрактного тестирования. В чаенккти. что может потребоваться для вариантов- встроенных методов тести-ров-ания вслетств-не ограничений, налагаемых ясиолмованнем протокола (ов>, расположсянопНых) иад протоколом, который находится в фокусе целей тестирования;

с) использовал одни и те же соглашения по наименованиям тестовых групп к тестовых примеров;

d) при необходимости поддерживал определенные в СТКиЦТ взаимоотношения между целями тестирования и теми элементами в формах ЗСРП и части ДИРПТ, которые должны использоваться для выбора тестового примерз;

е) удовлетворял требованиям настоящего стандарта, а также ИСО/МЭК 9646-3.

II СПЕЦИФИКАЦИЯ ОБЩИХ ТЕСТОВЫХ КОМПЛЕКТОВ

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

ГОСТ Р ИСО/МЭК Ш-2-e

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

II р а м еч а л и е — Таких образом, общий тестовый пример охватывает набор всех во»мо>к.»ых ХАТ для еоотв<-гствуюмсго{нх| протокола(obj. Те цели итирояеняп. которые исключены нт комплекта общих тестов, могут быть про-тестирован».' только путем нспользодояяя тктов разрешения соответствия, которые* не стандартизованы.

Каждый обший тестовый пример вносит в цели тестирования дополнительные сведения Он может определить основные последовательности событий тела теста и назначить вердикты результатам тестирования.

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

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

Руководящие материалы по разработке общих тестовых примеров приведены в приложении D.

12 MFTO/W АБСТРАКТНОГО ТЕСТИРОВАНИЯ

12.1 Введение

Метод абстрактного тестирования описывает архитектуру абстрактного тестирования, состоящую из нижнего тестера, верхнего тестера и процедур скоординированного тестирования, а также их отношение к тестирующей и тестируемой системам. Каждый метод абстрактного тестирования определяет ПКН и тестовые события (т. е. ДСП и ПБД). которые должны использоваться в абстрактном тестовом примере Для данного метода абстрактного тестирования.

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

12.2 О б щ и е принципы

12.2.1 Нижние тестеры

ГОСТ Р ИСО/МЭК 9М6-2-М

Во всех методах абстрактного тестирования нижний тестер взаимодействует с ТС через кижерасположенного поставщика услуг. Bi качестве поставщика услуг рассматривается физическая среда, расположенная под физическим уровнем.

Приводимая в данном разделе общая спецификация методов абстрактного тестирования ссылается на ТР. в которой самый верхний уровень нумеруется «N_t> («вершина»), а самый нижний уровень—«N в» {«низ»?. Для одно протокольных TP Nt равно Nb Та же нотация используется при ссылках на уровни внутри ТС и внутри нижнего тестера. ТР может реализовать протоколы в уровнях, расположенных ниже «Nt»», однако они не представляют интереса в описаниях методов тестирования. Тем не менее. ТС должна содержать физический уровень. Для всех методов тестирования КАТ определяют тестовые события в ПКН нижнего тестера в понятиях (Nb—1)-АСП и/илн от (N_b) ДО (Nt)-ПБД.

12.2.2 Верхние тестеры

Основное различие между методами абстрактного тестирования состоит в характере верхнего тестера и в его взаимодействии с нижним тестером.

В некоторых методах тестирования реализован второй ПКН для верхнего тестера. В этих методах тестовые события в ПКН верхнего тестера должны определяться в соответствии с определением соответствующих услуг ВОС к спецификацией протоколов ВОС. Действия в ПКН верхнего тестера не должны требовать, чтобы ТС или ТР обеспечивала параметры АСП. ПБД или те функциональные возможности, которые не охватываются соответствующим стандартом или рекомендацией МККТТ ко ВОС.

Если ПКН представляет собой доступный для человека интерфейс. то в качестве ПКН должен служить интерфейс с пользователем ТС.

12.3 Обща» спецификация методов абстрактного тестирования для ТР оконечных систем

12.3.1 Введение

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

12.3.2 Метод локального тестирования (сокращение: Л)

В этом методе:

а) тестовые события в ПКН нижнего тестера определяются в терминах (N_b—1)-АСП н от (N_b) ДО (Ы«)-ПБД;

Ь) тестовые события в ПКН верхнего тестера определяются в терминах (Nt)-АСП;

ГОСТ Р ИСОМЗК М4в-2—93

с) граница верхних услуг ТР должна представлять собой стандартный аппаратный интерфейс, который может использоваться для целей тестирования; тестовые комплекты не должны предъявлять никаких требований к реализации интерфейса в ТС дополнительно к требованиям, предъявляемым спецификацией стандартного аппаратного интерфейса;

d) «спецификация аппаратного верхнего интерфейса ТР должна определять преобразование между соответствующими ДСП и/илн ПБД и их реализацией на интерфейсе;

е) верхний тестер расположен внутри тестирующей системы;

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

Этот метод показан на рисунке 1.

Тестир-^щ^я система

Рисунок I — Метод локального тестирования

12.3.3 Метод распределенного тестирования (сокращение; Р)

В этом методе;

а) тестовые события в 11КН нижнего тестера определяются в терминах (No—1)-АСП йот (N_b) до МО-ПЬД;

Ь) тестовые события в ИКН верхнего тестера определяются в терминах (К|)-АСП;

с) граница верхних услуг ТР должна представлять собой либо интерфейс с пользователем — человеком, либо интерфейс со стан-

1'3

ГОСТ Р НСО.'МЭК 9646-2-93

дартным языком программирования, который может использоваться для целей тестирования; тестовые комплекты не должны предъявлять никаких требований к реализации интерфейса в ТС дополнительно к требованиям, предъявляемым спецификацией интерфейса со стандартным языком программирования при его использовании;

d) должно осуществляться преобразование между соответствующими ДСП и/или ПБД и их реализацией на верхнем интерфейсе ТР;

е) верхний тестер расположен внутри ТС;

f) требования к процедурам скоординированного тестирования должны определяться в КАТ, но сами процедуры не должны определяться;

g) если верхний интерфейс ТР является интерфейсом с пользователем — человеком, то оператор ТС удовлетворяет требованиям процедур скоординированного тестирования;

h) если верхний интерфейс ТР является интерфейсом со стандартным языком программирования, то верхний тестер реализован в программных средствах, а оба тестера — верхний н нижний—совместно удовлетворяют требованиям процедур скоординированного тестирования;

Этот метод показан на рисунке 2.

Рисунок 2 —Метод распределенного тестирования

ГОСТ Р исо.мзк we-2-w

В методе распределенного тестирования сами КАТ не должны определяться на интерфейсе с верхним тестером.

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

Примечание — Пока ив прикладном уровне не будет стандартизован интерфейс с прикладными программами дли обеспечения общих средств доступа к услугам прикладного уровня ВОС. практическое использование метола распределенного тестирования будет ограничено использованием интерфейса между пользователей человеком к прикладными программами ВОС (например нни-инаторы передачи файлов, доступа к файлам и управления файлами).

12.3 4 Метод скоординированного тестирования (сокращение: С)

В этом методе:

а) тестовые события в ПКН нижнего тестера определяются в терминах (Кь—1)АСП и/или от (N_b) до (КО-ЛЕД плюс ИБД-АУТ;

Ь) номера (Nt)ACn не используются в спецификации комплекта абстрактных тестов; о существовании верхней границы ТР никаких допущений не делается;

с) верхний тестер расположен внутри ТС;

d) требования к процедурам скоординированного тестирования должны определяться в комплекте абстрактных тестов посредством стандартизованного протокола административного управления тестированием, на который указывает КАТ:

е) верхний тестер должен реализовывать протокол административного управления тестированием и оказывать соответствующее воздействие на ТР;

[) в КАТ должны добавляться тестовые примеры для промер-ки соответствия верхнего тестера требованиям спецификации ПАУТ; такие тестовые примеры не вносят вклада в оценку соответствия ТР.

Относительно ПАУТ:

а) ПАУТ должен быть реализован внутри ТС непосредственно над границей абстрактных услуг на вершине ТР;

Ь) от ТР не требуется интерпретировать ПБД-АУТ, она должна только пропускать их в сторону верхнего тестера и от него;

с) ПАУТ определяется только для тестирования конкретного протокола и поэтому он необязательно должен быть независим от нижерзсположемкого п ротокола;

d) назначение вердиктов тестовым примерам не должно основываться на способности ТР выдавать АСП или параметр АСП на верхней сервисной границе ТР, поскольку это противоречило

ГОСТ Р ИСО/МЭК *646-2-93

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

Этот метод показан на рисунке 3.

Рисунок 3— Метол спортаннровакмпго тестирования

12.3.5 Метод удаленного тестирования (сокращение: У)

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

а) тестовые события я ПКН нижнего тестера определяются в терминах (Къ—П -АСП и/мли от (Nb) до (NJ-llDA;

Ь) номера (Nt)-АСП не используются в спецификации комплекта абстрактных тестов, о существовании верхней границы ТР никаких допущений не делается;

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

ГОСТ Р И СО. М ЭК %46-2-»3

d) абстрактно ТС должна обязательно выполнять некоторые функции верхнего тестера для обеспечения любых используемых действий процедур скоординированного тестирования и пунктов контроля и наблюдения ТР, неформально выраженных или описанных в комплекте абстрактных тесто» для заданного протокола; эти функции не определены и относительно их выполнимости или реализации никаких допущений не делается;

е) нижний тестер должен пытаться обеспечить предполагаемые или неформально выраженные процедуры скоординированного тестирования в ■соответствии с рассматриваемой информацией в ДИРПТ.

Кроме того, чтобы устранить в необходимых случаях пробел в спецификации функционального поведения выше ТР, требуемое поведение ТС должно быть определено в терминах (Nb—1)-АСП пли от (Nt.) до (N_l)-ПБД. которое должно быть наблюдаемо со стороны нижнего тестера. Этот вид неявной спецификации должен означать: «-внутри ТС необходимо что-то делать, чтобы вызвать необходимое поведение».

Возможно, однако, что некоторые из тестовых примеров в КАТ не могут быть выполнены (например передача последовательных неподтвержденных ПБД «данные» и др.).

Даже при такой неявной спецификации управления ТР этим методов» тестирования можно определить управление, но ке наблюдение, выше ТР. В этом состоит основное отличие между данным и другими методами тестирования.

Этот метод показан на рисунке 4.

12.3.6 Одноуровневый и встроенный варианты

Каждый из методов тестирования имеет свой вариант, который может быть применен в одиопротокольных ТР (сокращение: О).

В многопротокольных ТР определен встроенный вариант каждого из методов тестирования (сокращение; В), предназначенный для последовательного во времени тестирования протоколов.

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

ГОСТ Р ИСО/МЭК 9646-2-93

Рисумох 4 — Метод удаленного тестирования

Имена конкретных вариантов методов тестирования должны образовываться следующим образом:

I С I MB | Р I ¹

Например. PO является сокращенном для распределенного одноуровневого метола тестирования, определенного в 12.4.3. а РОВ — сокращением для распределенного одноуровневого встроенного метода тестирования, определенного в 12.53.

12.4. В а р и а кт ы однопротокольных ТР

12.4.1. Введение

В последующем описании методов одноуровневого тестирования. применяемых при тестировании однопротокольных ТР, абстрактная модель ТР называется тестируемым (N)-логическим объектом.

12.4.2 Метод локального одноуровневого тестирования

В методе локального одноуровневого (ЛО) тестирования тестовые события на верхнем аппаратном интерфейсе тестируемого (N)-логического объекта определены в виде (N)-ACn, а в ПКН нижнего тестера — в виде (N—1)-АСП и/мли (X) П5Д.

ГОСТ Р ИСО/МЭК 9М6-2—93

Этот вариант показан на рисунке 5.

Тёс/пирующая система.

Рисунок 5— Метод лощильного одноуровневого тестирования

12.4.3 Метод распределенного одноуровневого тестирования

В методе распределенного одноуровневого (РО) тестирования тестовые события на верхнем аппаратном интерфейсе тестируемого (N)-логического объекта определены в виде (Nj-АСП, а в ПКН нижнего тестера — в виде (N—1)-АСН и,/иля (М)-ПБД.

Пр и ме ч з и не -■ Метод тестирования РО отличается от метода тестирования «Ю тем. что е-срхинА интерфейс тестируемого (N) логического объекта не является аппаратным интерфейсом.

Этот вариант показан на рисунке 6.

12.4.4 Метод скоординированного одноуровневого тестирования

В методе скоординированного одноуровневого (СО) тестирования тестовые события определены в ПКН нижнего тестера в виде (N —1) АСП и/илм <М-ПБД. плюс ПБД АУТ.

Этот вариант показан на рисунке 7.

12.4.5 Метод удаленного одноуровневого тестирования

В методе удаленного одноуровневого (УО) тестирования тестовые события определены в ПКН нижнего тестера в виде (N—1)-АСП и/или (№>-ПБД.

ГОСТ J> ИСО/МЭК «46-2-5S

Рисунок 6—Метод распределенного одноуровневого тестировании

Рисунок ? — Метол скоординированного одноуровневого тестирования

Этот вариант показан на рисунке 8.

12.5 В лр и а и гы многопротокольных ТР

12.5.1 Введение

Методы встроенного одноуровневого тестирования определены для отдельного протокола внутри многопротокольной ТР, включая спецификацию активности протокола на уровнях выше тести руе-

26-

ГОСТ Р ИСО/МЭК 9646 -2-93

Рисунок в — Menu удаленного одноуровневого теспировання мого. но без спецификации контроля и наблюдения на сервисных границах внутри многопротокольной ТР. Таких» образом, в многопротокольной ТР от протокола (Мь) до протокола (Nt) абстрактные тестовые примеры для тестирования уровня (NJ должны содержать спецификацию ПБД в уровнях с (Ni-M) до 4NM. а также ПБД в уровне (N,).

Примечания

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

Успешное ж-по-илмваиж: метола одноуровневого встроенного тестирования (от уровня (К») до уровня (N;)) называется возрастающим тестированием нио-гоуроввеэой ТР.

Варианты метода встроенного тестирования определены для отдельного тестируемою урэшгя в многоуровневой ТР. Это не означает, что не могут быть доступны сервисные границы внутри многоуровневой ТР: это означает, что такие (рвинны не кеаолыукяся в этих методах тестирования. Таким образом, все уроанч. рзсрэлпжеячые между тестируемым уровнем и самым верхним уровнем, для которого ПБД выражены в качестве тестовых событий и комплекте абстрактных тестов, должны рассматриваться хак часть многоуровневой ТР.

2 Для верхнего уровня многоканальной ТР (NJ ути варианты такие же, хак и обычиие методы одноуровневого тестирования.

12.5.2 Мето^ тестирования ЛОВ

В методе локального одноуровневого встроенного (ЛОВ) тестирования для протокола (Ni) .многоуровневой (от (Мь) до (NJ)

ГОСТ Р ИСО/МЭК 9616-2—93

ТР тестовые события должны определяться в терминах (К)-ДСП над ТР и (N,—I )-АСП и от (NJ до (МО-ПБД над поставщиков (N|—1)-услуги в тестирующей системе.

Этот вариант показан ни рисунке 9.

Рисунок 9 — Пример метода ЛОВТ: тестирование |М) протокола в (N,| до (Nt)-протоколе ТР

12.5.3 Метод тестирования РОВ

В методе распределенного одноуровневого встроенного (РОВ) тестирования для протокола (Nj многоуровневой (от (Nb) ДО (Ni)) ТР тестовые события должны определяться в терминах (Ni)-ACn над ТР и (Nt—1)-АСП и от (NJ до (NJ-ПБД над поставщиком (Ni—1)-услуги в тестирующей системе.

Этот вариант показан на рисунке 10.

12.5.4 Метод тестирования СОВ

Метод скоординированного, одноуровневого встроенного (СОВ) тестирования использует возможности рассмотренных выше методов тестирования ЛОВ и РОВ. Тестовые события должны определяться в терминах (Ni 1)-ДСП. от (NJ до (NJ-ПБД н ПБД-ЛУГ. Протокол ПАУТ должен быть ориентирован на работу с использованием (NJ-услуги.

Этот вариант показам на рисунке II.

12.5.5 Метод тестирования У OR

Метод удаленного одноуровневого встроенного (УОВ) тестирования использует тот же ПКИ, что и метод УО того же уровня, но он отличается от .метода УО тем, что ПБД от (Ni+I) до (Nt) должны быть определены в тестовых примерах для уровня (NJ.

ГОСТ J* ИСО/МЭК 9648-2-93

Рисунок 10—Пример метода РОВТ: тестирование (Ni>-протокола и (\Ч) До (Nil-протоколе ТР

Рисунок 11—Пример мстолз СОВТ: тестирование (NJ-протокола в (Мь) до (Ni)-протоколе ТР

Этот вариант показан на рисунке 12.

12.6 Методы тестирования открытых ретрансляционных систем

ГОСТ Р ИСО/МЭК «646-2-93

Рисунок 12 — Пример мегома УОВТ: течтмроязлнс (Nj-протокола в (Nu) до (К'О-прогоколе ТР

12.6.1 В ведение

Для открытых ретрансляционных систем определены метол тестирования по шлейфу (МШТ) и метод поперечного тестирования

12.6.2 Метод тестирования по шлейфу

Метод тестирования по шлейфу используется для тестирования ретрансляционной системы из одной подсети.

Этот метод тестирования показан на рисунке 13.

Для этого метода имеются два пункта контроля и наблюдения одной подсети в ИДУ, удаленных ат (N)-ретранслятора. Для протоколов режима-с-установлением-соединения этот метод требует, чтобы два тестируемых соединения были соединены шлейфом на удаленной стороне (N)-ретранслятора, однако место установки шлейфа — внутри (X')-ретранслятора или во второй подсети нс определено. Для протоколов режима-без-устаковлення-соединелия этот метод требует, чтобы ПБД замыкались по шлейфу внутри второй подсети и возвращались во второй пункт контроля и маб-.нюдения.

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

ГОСТ Р ИСО/МЭК 9646-2—93

Рисунок F3 —Метод шлейфового тестирования (МШТ>

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

12.6.3 Метод поперечного тестирования

Метод ПТ используется для тестирования ретрансляционной системы, состоящей из двух подсетей.

Этот метод тестирования показан на рисунке 14.

В этом методе тестирования имеются два пункта контроля и наблюдения, по одному на каждую подсеть, в ПДУ, удаленных от (N) -ретранслятора.

Этот метод позволяет тестировать открытую ретрансляционную систему в се обычном режиме раНботы с наблюдением ее поведения в каждой подсети.

12.7 Выбор метода абстрактного тестирования

12.7.1 Введение

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

Методы абстрактного тестирования различаются ио степени контроля и наблюдений той ТР. которую они обеспечивают. Сле-

ГОСТ F ИСО/МЭК 9646-2-93

Ржуипк Н — Метод поперечною тест и рои а и и и (МПТ) довательно, выбор метода тестирования влияет на выразительность поведения в описании тестового примера

(2.7.2 Услуга исчерпывающего тестирования

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

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

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

ГОСТ Р ИСО/МЭК 9646—2—93

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

Если разработан стандартный КАТ, который не удовлетворяет указанным выше требованиям по Обеспечению услуги исчерпывающего тестирования, то в разделе «назначение» должно быть записано следующее-:

«Этот абстрактный тестовый комплект сам но себе недостаточен для обеспечения услуги исчерпывающего тестирования протокола (наименование)».

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

12.7.3 Функциональная среда ТР

Существует взаимосвязь между методами тестирования и конфигурациями реальных открытых'систем, подлежащих тестированию.

В 7.2 настоящего стандарта приведены все сведения о классификации систем и ТР.

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

а) относятся к оконечной или ретрансляционной системе;

Ь) относятся koi всей системе или к ее части;

с) относятся к полностью открытой или к смешанной системе;

d) имени доступные сервисные границы или нет;

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

12 7 4 Применимость методов абстрактного тестирования

Некоторые соображения по применимости методов к различным уровням рассмотрены в приложении В к ГОСТ Р ИСОМЭК 9646—1,

Для рассматриваемого протокола .может быть выбран один или несколько методов абстрактного тестирования.

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

ГОСТ Р ИСО/МЭК 9М6-2-М

12.8 Процедуры скоординированного тестирования

Для эффективного и надежного выполнения аттестационного тестирования необходим некоторый набор правил по координации тестовых процессов; между нижним и верхним тестерами. Основное назначение этих правил состоит в том, чтобы обеспечить нижнему тестеру возможность дистанционного контроля над операциями верхнего тестера теми способами, которые выбраны для прогона тестового комплекта для данной ТР.

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

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

При определении тестовых примеров для методов локального н распределенного тестирования те требования к верхнему тестеру н/илн процедурам скоординированного тестирования, которые могут оказаться необходимыми, не должны превышать требований, приведенных в 12.3.2 и 12.3.3 для методов локального и распределенного тестирования.

13 СПЕЦИФИКАЦИЯ КОМПЛЕКТОВ АБСТРАКТНЫХ ТЕСТОВ

13.1 Общие положения

Комплект абстрактных тестов состоит из набора тестовых примеров и. факультативно, из тестовых шагов для конкретного метода тестирования

Самим тестовым примерам должна предшествовать следующая информация:

а) имя КАТ, дата его создания и номер версии;

Ь) имена (и номера версий) стандарта (ов) или рекомендации (ий) МККТТ, определяющих протокол(ы) (и соответствующие им синтаксисы передачи), которые используются в спецификациях тестовых примеров;

ГОСТ Р ИСО/МЭК 9546-2—93

■с) имена (и номера версий) стандарта(он) или рекомендации (нй) МККТТ по услугам, абстрактные примитивы которых определены в тестовых примерах как контролируемые н/илн наблюдаемые;

J) ими (и номер версии} стандарта или рекомендации МККТТ, определяющей тестовую нотацию;

е) имя необходимого метода тестирования;

1) описание сферы действия тестового комплекта; например функциональные подмножества тестируемого(ых) протокола(ов);

g) описание структуры тестового комплекта в понятиях тестовых групп в их отношения к спецификации (ям) протокола (ов);

h) описание процедур скоординированного тестирования или ссылка на спецификацию ПАУТ (при их использовании в методе тестирования);

i) факультативно перечень тестовых примеров для оценки функциональных возможностей и повеления, которые могут использоваться в тестях основной взаимосвязи;

j) вспомогательная информация для исполнителя тестов и испытательной лаборатории по использован ню ими стандартного комплекта абстрактных тестов (см. раздел 15);

к) идентификация технической поправки (или ее эквивалента в МККТТ I, которая касается стандарта или рекомендации МККТТ, определяющих протокол или синтаксис передачи, н которая учитывается в КАТ.

13.2 Тестовые примеры

13.2.1 Разработчик комплекта абстрактных тестов должен выбрать соответствующую стандартизованную нотацию и определить в ней абстрактные тестовые примеры. Для этой цели рекомендуется использовать комбинированную древовидную и табличную нотацию (КДТН), определенную в ИСО.МЭК 9646—3.

13.2.2 Если стандартный КАТ использует средства дополнительно к средст вам КДТН, определенным в ИСО/МЭК 9646—3, то такие дополнения должны быть документированы в стандартном КАТ и переданы для включения в ИСО/МЭК 9646—3 в вше из-иешений об ошибках либо дополнений в зависимости от их характера.

13.2.3 После выбора тестовой нотации н метола тестирования могут быть определены абстрактные тестовые примеры.

Каждый абстрактный тестовый пример должен:

а) отражать только одну цель тестирования или комбинацию пелен тестирования согласно спецификатору целей тестирования, или отдельный общий тестовый пример при его наличии;

Ь) определять все последовательности тестовых событий, которые охватывают тело теста;

ГОСТ Р ИСО/МЭК 9Ы6—2—93

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

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

е) быть специфицированным с использованием выбранной тестовой нотации и .метода тестирования;

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

13.2.4 Если цель тестирования может быть достигнута только путем системно-зависимых действий в ТР, то невозможно определить абстрактный тестовый пример для этой цели тестирования в стандартном КАТ. Это ограничение должно быть документ ро эано в стандартном КАТ.

П р и м V ч 9 >| II р — Должна быть Указана возможность записи времоюых twron разрешений соотигт<твня для достижения цели тестирования на основе послсдовительного выполнения примерен. Однако такие тесты нс входят в сферу стандартизации.

Если цель тестирования не может быть достигнута по причине специфичного характера метода абстрактного тестирования, это ограничение также должно быть документировано в стандартном КАТ.

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

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

ГОСТ Р ИСО/МЭК 9646-2-93

тестовые примеры; в этот набор должно входить соответствующее холостое состояние тестирования.

Примечание ] — Для использования потребуются, видимо, нс более двух или трех преамбул теста.

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

Примечание 2 — Способность тестового примерз стартовать и закан-чив:пк₽ в Х1ыосг»ч corKniHiin тестирования требуется для того, 'човы можно было прогонять каждый абстрактный тестовый пример индивиду а льна, отдельно т прогона других абстрактных тестовых примеров.

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

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

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

ГОСТ Р ИСО/МЭК 9М8-2-93

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

Если начальное состояние тестирования тела теста является переходным состоянием тестирования, то тело теста не должно прогоняться без предварительного прогона преамбулы теста.

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

При построении структуры шагов теста в пределах абстрактных тестовых примеров разработчик тестового комплекта может извлечь выгоду от использования одних и тех же шагов геста в нескольких абстрактных тестовых примерах.

13.2.7 Разработчик тестового комплекта должен обеспечить, чтобы каждый абстрактный тестовый пример определял в явном виде:

а) каждую последовательность тестовых событий, связанных с вердиктом «прохождение»;

Ь) каждую последовательность тестовых событий, связанных с вердиктом «не завершено».

П р к -.1 «■ «I з и и е ~ Вердикт может относиться к псследовзтельногти тестовых отбытий, представляющих гаки- поьедсяме ТР. которое хот л является зейегвигсльмыи, ио препятствует достижению цели тестирования.

с) Все остальные последовательности тестовых событий, связанные с вердиктом «■безуспешность», определяются либо индивидуально, либо классифицируются путем использования неидентя-фи цируемого тестового события.

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

13.3-Раздел соответствия КАТ

Стандартный КАТ должен содержать раздел соответствия.

ГОСТ Р ИСО/МЭК МИ6-2-03

В разделе соответствия должно быть записано следующее:

«Разработчик теста должен соблюдать требования ГОСТ Р ИСО/МЭК 9646—4. Это особенно относится к требованиям по реализации КВТ. основанного на КАТ.

Испытательные лаборатории, обеспечивающие услуги агтеста-циоиного тестирования для данного комплекта абстрактных тестов, должны отвечать требованиям ГОСТ Р ИСО/МЭК 9^46—5».

13.4 Со в м ест и я ост ь с протоколом

Стандартный КАТ должен представлять в точности те протоколы, соответствие которым проверяется путем аттестационного тестирования. Если при разработке КАТ обнаружены ошибки или неоднозначности в протокольной спецификации, разработчик тестового комплекта должен направить в соответствующую группу ИСО/МЭК или МККТТ извещение об ошибке, которое идентифицирует возникшую проблему. Если между КАТ и протокольной спецификацией обнаружены’различия после того, как КАТ уже стандартизован, то в процессе разрешения соответствия предпочтена должно быть отдано протокольной спецификации.

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

14 СПЕЦИФИКАЦИЯ ПАУТ

При использовании методов скоординированного тестирования (СТ и СВТ) процедуры скоординированного тестирования реализуются путем разработки отдельной части стандарта по аттестационному тестированию ПАУТ.

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

Если часть стандарта по аттестационному тестированию, определяющая ПАУТ, разработана, то для заявки о реализации ПАУТ должна быть предусмотрена форма, содержащая лдзицни для каждого из ПБД-АУТ.

ГОСТ ₽ ИСО.'МЭК 9Ив 2-93

15 ИСПОЛЬЗОВАНИЕ СПЕЦИФИКАЦИИ КОМПЛЕКТА АБСТРАКТНЫХ ТЕСТОВ

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

а) преобразование примеров абстрактных тестов в записи формы ЗСРП для определения необходимости выбора каждого абстрактного тестового примера для конкретной ТР; это преобразование должно быть определено в нотации, подходящей для булевых выражений;

Ь) спецификацию частичной формы ДИРПТ для каждого КАТ; она должна содержать список всех параметров, значения которых требуются в тестовом комплекте; если какой-либо из запрошенных значений параметров будет указан в ЗСРП, запись в форме ДИРПТ для каждого такого параметра должна ссылаться на соответствующую запись в форме ЗСРП.

П р и м с я я ч и г — Остальные аспекты формы ДИРПТ рассматриваются « ГОСТ Р ИСО/МЭК 95 4 5-1. ГОСТ Р ИСО/МЭК 964^-4 и ГОСТ Р ИСО/МЭК 9545-5;

с) преобразование абстрактных тестовых примеров в записи формы ДИРПТ с целью параметризации тестового комплекта, относящегося к конкретной ТР; это преобразование должно идентифицировать те требования к тестированию, которые могут помешать прогону тестовых примеров относительно конкретной ТР; это преобразование должно бить задано в нотации, пригодной для булевых выражений;

d) последовательность, в которой абстрактные тестовые примеры должны использоваться в отчете по аттестационному тестированию протокола (ОАТП) (см. 15.2);

е) любые ограничения, которые могут быть наложены на последовательность выполнения тестовых примеров;

f) идентификация тестовых примеров или тестовых групп, которые должны быть реализованы в СТ, претендующих на соответствие стандартному КАТ;

g) требования к процедурах! скоординированного тестирования или ссылка на спецификацию ПАУТ (если они применимы в выбранном методе тестирования);

h) любая необходимая информация о таймированин.

15.2 Последовательность, в которой должны перечисляться абстрактные тестовые примеры в ОАТП. может быть определена

ГОСТ Р ИСО/МЭК 9646 2-9 3

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

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

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

П ,i в м с ч а к и с — Огикмиланкх последовательности выполнения тестовых при мерою с целью минимизации временя выполнения рассматривается как вопрос |1|»>1мв<1Л1|Тё.1ъ>кХ’гк и не отпеките я к сфер г стэ1иарти.тлцни.

16 ОБСЛУЖИВАНИЕ ТЕСТОВОГО КОМПЛЕКТА

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

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

ГОСТ Р ИСО/МЭК 9646-2-93

ПРИЛОЖЕНИЕ А (обязательнее)

ТРЕБОВАНИЯ К ФОРМЕ ЗСРП И РУКОВОДЯЩИЕ МАТЕРИАЛЫ ПО ЕЕ ЗАПОЛНЕНИЮ

А.1 Введение

Д13 Ферма ЗСРП определяет в явное виде гибкость реализации, допускаемую спецификацией протокола. В табличной форме подробна излагаются: а) факультативные возк-ожмосги реализации, т. с функции, дополнительные к тем. Kojopue обязательны для реализации, и

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

А 1^ Для конкретного протокола форма ЗСРП используется:

а) исполнители ни или поставщиками, который необходимо документировать свою реилкзаиию;

Ь) разработчиками КАТ. которые должны быть уверены в том. что комплект тестов соотпетстпусг допустимой гибкости реализации;

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

А 1.3 Заполненная форма ЗСРП представляет собой ЗСРП для рассматриваемой реализации. ЗСРП вносит свой вклад в процесс оценки соответствия в случаях ее использования:

а) при просмотре статического соответствия;

Ь) в врои&себ выбвра leers а качестве средства адаптаций комплекта &ы-полнимых тестов к факультативный функциям, обеспечиваемым реализацией;

с) в процессе анализа результатов в качестве справочного документа.

ЗСРП может использоваться также для оценки возможности взаимодействия двум реализаций Это можно осуществить путем сравнения факультативных функций и параметров, -заявленных в ЗСРП.

А 1.4 Каждая группа, определяющая протокол, несет ответственность за техническое содержание формы (форм) ЗСРП, относящейся (ихся> к обслужи-веемому (им) ею протоколу (ам)

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

А.2 Взаимоотношения между формами ЗСРП и требованиями к соответствию

А.2.1 Форма ЗСРП представляет собой набор вопросов, относящихся к функциональным возможностям протокола. Функциональная возможность протокола — это набор функций, которые должны обеспечиваться реализацией. Требования к статическому соответствию, излагаемые в спецификации прото-кола ВОС. определяют правила реализации >тиж функциональных возможностей.

Каждый вопрос, (млн позиция) формы ЗСРП должен указывать статус каждой возможности а соответствии с указанными правилами

Статус может означать:

а) обязательно — функциональная возможность должна быть реализована я соответствии со специфика иней протокола;

ГОСТ Р ИСОМЭК 9646-2-93

Ь) факультативно — Функциональная возможность может быть реализовала. н в случае реализации она должка соответствовать спецификации протокола: функциональные возможности могут быть булевыми выражениями, взаимно исключающими или выбранными (как описано в раздел А.З ГОСТ Р ИСОМЭК 9Мв-1).

с) запрещено — существует требование не использовать эту возможность в данном контексте (относится только к требованиям динамического соответствия при их применении, включенным в форму ЗСРП};

dj нелон пенимо — в данном контексте никакие требования не могут быть изложены;

с) условно — требонанке к данной «функциональной возможности зависит от выбора других позиций факультативных возможностей или условий; форма ЗСРП не МОЖС1 -определить заранее определенного статуса этой функциональной возможности, она может указывать статус (обязательно, факультативно, запрещено или неприм еним о) только и зависимости от оценки предиката или условного выражения.

Л2 2 В патицли формы ЗСРП должно быть предусмотрено место для записи заявки поставщик* ТР относительно обеспечения в ТР соответствующей функциональной возможности. Это обеспечение- может быть сформулировано в с лед уюте и виде:

а) функциональная возможжасть реализована;

Ъ) функциональная возможность не реп лило вана;

cj прочие специфичные для протокола возможности реализации.

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

А23 Если обязательная функциональная возможность не обеспсоенз, это означает несоответствие (см. раздел А 7).

Если функциональная возможность не обеспечена, может быть записав аоп рос оценки тех действий, которые выполняет реализация при получении ПБД., относящегося к этой возможности, в зависимости «и того, что определяет спецификация протокола:

а) выбор действий, которые могут быть выполнены.

Ь) не определяет выполняемых действий

А24 Должно существовать четкое отображение (путем ссылок) формы ЗСРП из требования к статическому соответствию согласно 7 3

А.2.5 Элементы колонки «статус» формы ЗСРП в неявном виде определяют проверки, которые должны выполняться при просмотре статического соответствия. Форма ЗСРП может также определить дополнительные специфичные проверки, которые должны выполняться при просмотре статического соответствия (см. Л 8 10).

А.З Общее построение

А 3.1 Форма ЗСРП должна -разрабатываться как обязательная часть соответствующего стандарта или рекомендации МККТТ по протоколу ВОС. либо как отдельная рекомендация МККТТ. Применимы соответствующие (ИСО/М-ЭК или МККТТ) правила построения стандарта или рекомендации МККТТ

А.3.2 В разделе «Введение» должно быть записано следующее:

«Для оценки соответствия коинр-егиой реализации необходимо иметь констатацию тех функциональных возможностей, которые рсализоманы дли данно го протокола ВОС. Такая констатация называется «заявкой о соответствии реализации протоколу (ЗСРП)».

ГОСТ Р ИСО/МЭК 9646—2—93

АЛЗ В разделе «Назначение» должно быть записано следующее;

«Настоящий [стандарт или ^екомелдаоия MKKTTJ содержит форму ЗСРП (для протокола <нмя>, указанного а < ссылкам) согласно соответствующим руководящим материалам, приведенным в ГОСТ Р ИСО/МЭК 96-16—2»

А.3.4 В разделе «Нормативные Ссылки» должны содержаться следующие ссылки:

ГОСТ Р ИСО/МЭК 9646—1 «Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 1. Общие принципы» (см также рекомендацию Х.2М (1991) МККТТ):

ГОСТ Р ИСО/МЭК 96-16- 2 «Информационная технология Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 2 Спецификация комплекта абстрактных тестон» (см также рекомендацию X.S91 (1991) МККТТ).

В этом |ia.iAe.tc должны содержаться также ссылки на соответствующий стандарт или рекомендацию МККТТ, определяющие протокол

А .35 В разделе «Определения» должно быть записано:

«Настоящий (стандарт или рекомендация МККТТ| использует следующие термины, определенные в ГОСТ Р ИСО/МЭК 9646— I:

а} фЮфма ЗСРП;

Ы заявка о соответствии реализации протоколу (ЗСРП)-,

с) просмотр статического соответствия».

П р и мечение — Позиций с) необходима только в том случае, если в форме ЗСРП действительно упоминается просмотр статического соответствия (см. А* 1<!)

А 3.6 Должен быть включен раздел, отражающий требовании к соответствию относительно ЗСРП в следующей редакции:

Поставщик протокольной реализации, которая заявлена на соответствие <ссылха>, должен заполнят** копию формы ЗСРП, приведенную в приложении <Х>. и предусмотреть информацию, необходимую* для идентификации как поставщика, так и реализации».

Кроме того, в разделе «Соответствие» спецификации протокола должно быть записан^:

«Поставщик протокольной реализация, которая заявлена на соответствие (соответствующему стандарту или рекомендации МККТТ( должен заполнить копню формы ЗСРП. содержащейся в «^ссылка на часть стандарта, содержащую форму ЗСРП>. приложение <Х>. н предусмотреть информацию, необходимую для идентификации как поставщика, так к реализации»

А3.7 Сама фюрма ЗСРП должна содержаться в приложении Это пряло женис должно содержать фактическую форму, заполненную поставщиком или клиентом исгтытагслыюй лаборатории. В следующих разделал определяются требования к такому приложения! и содержится руководство по его составлению.

А.4 Авторское пряно

Формы ЗСРП должны заполняться разработчиками -реализации в отпечатанном виде (скопированном или воспроизведенном) в соответствующем стандарте или рекомемдашии МККТТ. Здесь возникает вопрос об авторском праве относительно текста такой части стандарта или рекомендации МККТТ

В приложении с формой ЗСРП должна содержаться в виде -сноски следующая запись с указателем скоски в заглавии приложения (например «Приложение А*»):

«Авторское право относительно форм ЗСРП»

ГОСТ Р ИСО/МЭК WS-2-9J

«Пользователи настоящего стандарта могут свободно воспроизводить фор му ЗСРП данного приложения с тем. чтобы ее можно было использовать и со огветсгвуюсцнх целях и в дальнейшем опубликовать заполненную ЗСРП».

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

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

А.5 Глава первая. Идентификация реализации

В первой главе фактической ЗСРП должна идентифицироваться реализация. а также поставщик и клиент испытательной лаборатории

В административных целях «а титульном листе самой ЗСРП должна содержаться идентификация:

а) реализации той системы, в которой она содержится;

Ь) поставщика системы и,''или. клиента испытательной лаборатории, который должен проверять реализацию;

с) лицо для контакта в случае возникновения каких-либо вопросов относительно содержимого ЗСРП;

d) взаимоотношение ЗСРП с «заявкой о соответствии системы» Данией системы.

В форме ЗСРП не обязательно задавать точный формат таблицы для такой информация Однако должна бить констатирована необходимость такой информации. и эго должно быть записано в стиле вышеуказанного абзаца.

Прим е ч д н к е — Испытательная лаборатории может предуюмотреть форму титульного листа

А.6 Глава вторая. Идентификация протокола

Вторая глава идентифицирует гот стандарт или рекомендацию МККТТ, к которому может быть применила форма ЗСРП Сюда огноептен ргнметрацкопх ный номер ИСО/МЭК или МККТТ и полное его(ее) название Эта глава должна быть включена в форму ЗСРП.

Должны быть в явном виде идентифицированы различные веренв. к которым может быть применима форма ЗСРП имеете с колонками «статус» и «обеспечение» при необходимое™ Если протокол ВОС предусматривает параметр версии, то во второй главе должна быть дана ссылка на другую позицию формы ЗСРП. где дана воддобная информация о статусе и оцепенейии такого параметра {в. возможно, о его согласовании).

А.7 Глобальная констатация соответствия

В форму ЗСРП должен быль включен вопрос; реализованы или кет все обязательные функциональные возможности?

Должно быть добАвлсно примечание, смысл которого следующий:

«Отлег «Нет» на этот вопрос означает несоответствие протокольной спецификации Необеспеченные обязательные функциональные возможности должны быть иленгифипирртшим п ЗСРП с пояснением причин несоответствия реализации»

А.8 Другие главы. Функциональные возможности

А 8 I Введение

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

ГОСТ Р ИСО/МЭК 9646-2-93

Перечисленные ниже темы являются общими зля многих протоколов ВОС. но они должны быть приспособлены к каждому конкретному -протоколу зля построения соответствующих глав формы ЗСРП.

А.8.2 Функциональная возможность «и и и и и а то p/о тв ст-ч н к»

Позиции формы ЗСРП могут использоваться для определения способности реализации инициировать взаимодействие, реагировать на взаимодействие, ими-цинровамное другой системой, либо выполнять то и другое. Способ, по которому организованы позиции формы ЗСРП для отработки этих двух режимов (например два набора колонок на одну таблицу или два набора таблиц), должны быть указаны для читателя. Такие позиции рекомендуются дли асимметричных протоколов.

А.83 Основные функциональные возможности

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

Эти «блоки» рассматриваются как основные функциональные возможности. Они определяются (с указанием их статуса) в требованиях к статическому соответствию рассматриваемой протокольной спецификации В зависимости от характера протокола основные функциональные возможности могут соответствовать лаб«> группе ПБД. подлежащих совместной реализации, либо некоторому аспекту, общему для нескольких ПБД.

Требования к Динамическому соответствию, относящиеся к каждой основной функциональной вбуибжийега. Wc йбспрымЕоДятс* 6 форме ЗСРП.

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

Форма ЗСРП должна содержать позицию для каждой гх-новной функциональной возможности независимо от ее статуса.

А.8.4 Т ай м-а ут ы и параметры протокола

Позиции формы ЗСРП могут использоваться для перечисления всех тайи-зу юн и протокольных параметров, определенных в спецификации протонема. Для каждого нз них должны быть определены допустимые иля обязательные длительности. типы данных и значения (или диапазон .значений). Должна быть предусмотрено место для указания обеспечивав г-ых -эле -вигов или значений Такие элементы реко-скдуютсн в каждо * уместном случае.

A. S5 Протокольные блоки данных

В форме ЗСРП должны быть предусмотрены позиции для идентификации ПБД Эти позиции должны охватывать вес ПБД. определенные для данного протокола п группируй-ые по их основ»ы ■ фувкииочальни ' воз^ожностии в каждом случае их при еиисс-сти Крозе того, статус и обеспечение должны указываться отдельно при передаче и криеме каждого ПБД (см. А.8.2).

Примечание—Б разделе «Соответствие» может (но не обязательно) содержаться информации о статусе «факультативно» конкретных протокольных элементов (ПБД, параметров ПБД). В некоторых протоколах статус «факультативно* отдельных элементов протокола размешают в основной части спецификации (требования к динамическому соответствию) с гем, чтобы их можно было включить в раздел «Соответстаис».

ГОСТ Р ИСО/МЭК 8646-2-вЗ

А я 6 Параметры ПБД

Позиции формы ЗСРП могут использоваться для перечислении тех параметров каждого ПБД. для которых существует гибкость реализации. Такие позиции рекомендуется использовать в каждом уместном случае

П ри м е ч а и нс— Если какой-то параметр должен всегда иметь место, всегда относиться к конкретному типу и всегда обослечшзть определенный диапазон значений, он нс обязательно должен быть документирован описываемым ниже способом

Для каждого документируемого параметра з форме ЗСРП должны быть предусмотрены:

а) его статус, основанный на значении конкретного предиката в каждом направлении (г с. передача и прием);

Ь) .место для отпета па вопрос: обеспечивается этот параметр в каждом направлении или пет?;

с) длины, диапазоны значений и,'млн типы данных, допускаемые в каждом направлении спецификацией соответствующего протокола ила синтаксиса передачи;

d) место .тля указания значений, обеспечиваемых в каждом направлении передачи

С точки зрения диапазона значений существуют два вида параметров: с гибкостью реализации н без гибкости реализации.

При отсутствии гибкости реализации в форме ЗСРП должен быть задан только один ‘вопрос: о/кспсчнвзется ли этот параметр с полным диапазоном своих значений?

При наличии гибкости реализаций в форме ЗСРП должен быть задан дополнительным вопрос. Например, «неограниченный» параметр ПБД вызывает в форме ЗСРП вопрос: какой максимальный размер реализовал?

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

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

Для протоколов, использующих синтаксис передачи, который не строго определяет размеры передаваемых параметров (нэпри.мер ACH.I), следует пояснить. охватывают лв определенные размеры кодирование.

А.В.7 Возможности согласования

Позиции формы ЗСРП могут использоваться для описания факультативных возможностей согласования, предусмотренных в протоколе, и может быть предусмотрено место для указания, какие из них реализованы Такие позиции рекомендуется предусматривать в каждом уместно* случае.

А.8.8 Обр а б о г к а протокольных ошибок

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

А.8 9 Многоуровневые зависимости

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

ТОСТ Р ИСО/МЭК 9Ш-2-И

А8Ю Прочие условия

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

А.9 Форматы таблиц

А.9.1 Структура таблиц

Отдельные разделы формы ЗСРП должны быть представлены в виде одной .или нескольких таблиц. Структура этих таблиц должка соответствовать структуре требований к статическому соответствию и к темям, перечисленным в А 8.

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

Каждая строка должна пересекать следующие колонки:

а) заранее отпечатанная колонка слева со ссылочными номерами каждой строки. Эта колонка должна обеспечивать способ однозначной ссылки на каждый возможный ответ формы ЗСРП. Должны быть предусмотрены способы ссылок на отдельные ответы для определения последовательное reft:

!) ссылка на подраздел с наименьшим номером, охватывающий соответствующую позицию;

2) знак «косая черта, «/».

3) ссылочный номер строки, в которой содержится ответ,

4) только в том случае, если в строке, идентифицированной ссылочным ио мером. содержится несколько ответов, каждая возможная позиция косвенно помечается а, Ь, с и т. д., слева направо, и эта буква присоединяется к послед лова тельностн;

Ь) одна заранее отпечатанная колонка для наименования позиции каждой строки,

с) один или несколько наборов колонок: для определения статуса элемента н его обеспечении; один набор к» каждый контекст, в котором должно быть определено обеспечение (например для передали н приема); в каждом таком наборе колонок может содержаться;

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

2) другая колонка э необходимых случаях для определения предиката, на котором базируется статус «условно» (см также Л 9 25 и Л9.2.6);

3) заранее отпечатанная колонка, в которой даются ссылки на соответствующие требования к статическому соответствию или не другие разделы соот-ве1авующ.ей(нх) спецификации (нА) по протоколу или синтаксису передачи {обязательно предусмотреть подходящие ссылки, предпочтительно — в таких, колонках)'.

4} колонка «обеспечение», в которой «ожег быть дан ответ ня вопрос: обеспеччиа-ст ли реллизаиня данную позицию в конкретном контексте (обязательная колонка).

11 соответствующих случаях гожст быть предусмотрено место для указа-пня в каждом контексте вида реализованного «необеспечення» -типа «примять и проигнорировать», «принять и отклонить-* и др.;

ГОСТ Р ИСО/МЭК 9616-2 -93

5) в соответствующих случаях заранее отпечатанная колонка «допустимые значения», устанавливающая любые необходимые ограничения или предписания на типы/ялины/диапазоны обеспечиваемых значений, в соответствии со спецификацией протокола или синтаксиса передачи;

6) в соответствующих случаях колонка «обеспеченные значения», з которой могут быть указаны обеспечиваемые диапазоны значений, а также в необходимых случаях типы и длины;

7) место справа, где при необходимости могут быть введены дополнительные колонки, позволяющие пользователю формы ЗСРП заяисыпать комментарии

На рисунке А.1 приведены примеры возможной реализации рассмотренных таблиц.

D.5.I Реализуемые классы

Реализуемые классы
Ссылочк ыЯ номер	Класс	Ссылка	Слит УС	Обеспечение
0	Класс 0	14.1	Ф !
	Класс 1	14 2	У-1
2	Класс 2	ИЗ	Ф’
3	Класс 3	14.4	У2
4	Класс 4	не	У2

ф1 —по меньшей мерс, одия из этих классов должен быть обеспечен у.Ь —ЕСЛИ класс 0. ТО ф ИНАЧЕ х

y.J ЕСЛИ класс 2, ТО ф. ИНАЧЕ х

класс 0—D.5J/1)

класс 2 = ПЛ 1/2

D.b I Обеспечение ПБД

Обвгпечиейсиыс ПБД
Ссылочный ноне»	ПБД	Ссылка	Перед,внаем и*		Привимпсиме
Ссылочный ноне»	ПБД	Ссылка	Curve	ООг^печеичс	Curve	ОС^спенение
1	ЗС	15.1	Ф		О
2	ПС	15.1	О		уЗ
3	дн	15.2	О		О

у 3: ЕСЛИ передается ЗС, то о. ИНАЧЕ н^н передача 3C=D.5l/a

ГОСТ Р ИСО/МЭК 9646-2—93

D.63 I Параметры XY-ПБД

Обмавчпммы* вараиетри
Ссылочных ММ«р	Пераието	Ссылке	Статчс	Обесле» енв	Значения
					Допустимые	Овеет* чйоаеиые
1 2 3	размер данных тайм-аут класс	15£ 15.7 15.8	0 Ф 0		128. 266, 512 1—3600 сек 0—4	«К

Рисунок А.1 — Примеры таблиц формы ЗСРП

А.9Д Символы и- соглашения

А,9.2 I Для колонки <Статус» предусмотрены следующие стандартные символы:

а) о или О для обязательных функций;

Ь) ф или ф для факультативных функций (булевы);

с) х или X для запрещенного использования;

<!| н/н, Н.П ила — (тире) для неприменимых функций:

е) у или У для условных функций (см. А 9 2^)

А.92Д Для колонки <Обсспсяснм» предусмотрены следующие стандартные символы:

я) д. Л или Да для реализованных возможностей;

Ь) и. Н или Нет для. нереализованных возможностей.

Должно баять предусмотрено место для кожглта пни того факта, что обеспечение миялокного не требуется в тех случаях, когда статус оценивается кэк «исприменнмо* Должно быть также предусмотрено место для примечаний к таким ситуациям, когда ответ требует обоснования или пояснения.

А 9.2.3 Приведенные выше соглашения должны быт», достаточными для форм большинства протоколов. Оян нечувствительны к буквенному регистру, поэтому 3 ОДНОМ II YQM же смысле могут НСЛОДЪЯЗВатЬСЯ «как строчные, так и прописные буквы При необходимости дополнительных соглашений их количество должно сводиться к минимуму и они должны содержаться п каталогах ИСО/МЭК СТЭНДЖ?! для исключения противоречий с другими разработками.

А 9.2.4 Дополнительные соглашения можно использовать для взаимоисключающих млн выбираемых из набора факультативных возможностей, «помеохля после <ф> (для факультативов) точку с последующим целым числом.

Таблица A.I - Группа взаимосвязанных факультативных возможностей

Позиция	Статут
Позиция А	ф.4
Позиция В

Позиция С I ф.4

ф4 — требуется обеспечение, гео меньшей мерс, одной нз этих факультативных возможностей

ГОСТ Р ИСО/МЭК 96*6—2—вв

В таблице АД приведен пример группы на трех факультативных возможностей. взаимосвязанных в том -смысле, что в реализации должна быть обеспечена, по меньшей мерс, одна из факультативных возможностей труппы с номером 4. S форме ЗСРП должно констатироваться в явном виде, желательно в виде сноски к соответствующей таблице, какие конкретно требования предъявляются к каждой пронумерованной труппе; должна обеспечиваться, по меиь-шей мере, одна либо только одна и ас более из факультативных возможностей, либо какое-то другое требование.

А.92.5 Условные требования должны выряжаться одним из следующих способов:

а) в колонке «Статус» пишется буква, «у» со знаком двоеточия, после чего в отдельных строках указывается одно или несколько безусловных состояний, для каждого из которых о колонке «Предикат» указывается предикат иля отрицание предиката (си А.9.2Л); отрицание может обозначаться оператором «Л».

Таблица А.2— Условные требования с использованием предикатов

Позиция

Статус

Предикат

Позиция А

у: о

П1

Ло 1

Позиция В

Г о

п2

В таблице AJJ показаны два примера, смысл которых состоит в следующем:

I) позиция А является обязательной, если ml имеет значение «истинно», н факультативной, если ч] Имеет анйчмшб «ложно»;

2) позиции В является обязательной, если и2 имеет значение «истапМО», но по соглашению она неприменима, если- п2 имеет значение «ложно»; в форме ЗСРП должно быть разъяснение этого соглашения, если оно 'используется:;

Ь) в колонке «Статус» пишется буква «у» с последующим целым числом, что даст ссылку ил выражение условного статуса (см. А9^7), записанного в каком-то месте формы ЗСРП, и в зтом случае колонка «Предикат» может быть опушена.

Та блица А.З—Сссылки нл выражения условного статуса

Полиция	Оатус
Позиция А'	у\|
Позиция В	У2

В таблице АЛ приведены дна примера, где статус каждой позиции определяется Путем оценки указывав¹,-.ого условного выражения

П ри м е ч а н в о—Для условных требований может быть использовав се-•лантичесхи эквивалентный альтернативный синтаксис при условии, что ок предусмотрен в каталоге ИСО/МЭК СТКМПК21

А.9.2.6 В качестве предиката может использоваться одно из следующих:

а) явная ссылка на элемент Да/Нет формы ЗСРП (в колонке «Статус») с использованием формата, определенного в А.9 lb); если «Да», то предикат имс-

ГОСТ Р ИСО/МЭК 9646-2-93

ст значение •истинно», в прегнаном случае он имеет значение <.юж*о». Например, «А 1.2.3.Л10а*- —это предикат, который ссылается на первую позицию для ответа в 10-й строке таблицы в A J 2.3;

Ь) имя предиката, которое в форме ЗСРП приравнивается одному из следующих:

I) явной ссылке на запись «ДаДЗет» в форме ЗСРП, например «л1» определяется выражением

<п! =А.1.2.3Я0ф>;

21 выражению соотношения, содержащего ссылку на запись формы ЗСРП и коленке «Значение»-, например <rt2>. где п2 определяется выражением:

«□2= (v2>3)>,

где v2 определяется выражением

<v2=A.1.2.3/i0b>,

которое ссылается на вопрос, требующий отвела в виде целого числа;

3> выражению предиката, т. с. булевскому выражению, содержащему, предикаты, например «пЗ», где «3 определяется выражением

«пЗ = (п! И НЕ п2) ИЛИ (v3<2)>.

синтаксис и семантика которого должны быть такими же. кая и для булевых выражений в КДТН (см. ИСО/МЭК 9646—3).

А.9.2.7 Выражения условного статуса представляют собой выражения типа ЕС^ОИ-ТО-ИНАЧЕ», которые оценивают безусловный статус в зависимости ог значения выражения предиката 1ыи предикатов,, которые следуют за <ЕС.’1И»_ При необходимости выражение «ЕСЛм-ТОИНАЧЕ» может быть организовано гнездовых способом.

Например, у] и у2 могут быть определены СЛЕДУЮЩИМ образом:

¥1: ЕСЛИ п) ТО о ИНАЧЕ ф;

у2. ЕСЛИ (П1 И НЕ п2) ИЛИ (v3<2) ТО о ИНАЧЕ Н/И

Для выражений условного статуса может быть использован любой падхо-хиший синтаксис. однако во избежание ненужного множества синтаксисов рекомендуется использовать синтаксис, каталогизированный ИСО/МЭК CTKU /ПК21

А 9.3 Инструкции по заполнению формы ЗСРП

•Форма ЗСРП должна содержать дополнительный раздел, в котором:

а) для потенциального пользователя поясняются цель и структура документа;

Ь) поясняются используемые символы, сокращения и термины а сочетании с соотдстсзвующими ссылками;

с) длин четкие инструкции по заполнению формы ЗСРП;

d) определены места." где пользователь может записать дополнительную информацию

ГОСТ Р НСО/МЭК 9646-2-93

ПРИЛОЖЕНИЕ В (справочное)

РУКОВОДСТВО ДЛЯ РАЗРАБОТЧИКОВ ПРОТОКОЛОВ ПО ОБЛЕГЧЕНИЮ ПРОЦЕССА АТТЕСТАЦИОННОГО ТЕСТИРОВАНИЯ

B.I Введение

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

Руководящие материалы в данной приложении по обязательным и факуль-газизным нозмпжностйы реализации должны изучаться в сочетании с требованиями и руководящими материалами гео форме ЗСРП. приведенными в приложении А.

В 2 Руководство но назначению н области применения

В2Л Точность формули роли н разделов «Назначение и область применения» определяет точность всей остальной части соответствующего стандарта или рекомендации МККТТ. Требования, установленные и стандарте нлн рекомендации МККТТ. должны соответствовагл назначению и области применения и наоборот

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

а) определение процедур обмена данными, которые должны выполняться во время обмена данными:

о) требований, которые должны выполнять поставщики реализаций этих процедур;

с) руководство ио реализации этих процедур.

Руководство по реализации процедур не должно содержать дополнительны.» требований и не имеет никакого отношения к соответствию Если такое руководство предусмотрено, то и назначении следует рассмотреть зги вопросы и’ указать, чем руководство может отличаться от требований спецификации Такое различие намного легче определить, если руководство отделить от требований. Рекомендуемый способ такого отделения, установленный в Директивах ИСО/МЭК,— поместить в примечаниях и приложениях.

В.2.3 Должно быть ясно, ни что распространяется данный стандарт или оскомсядаиия МККТТ

В? 4 Должно быть ясно, при каких условиях применим паяный стандарт или рекомендация МККТТ.

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

Лучше всего было бы составить спецификацию по протоколу таким образов. чтобы ее требованиям удовлетворяла -отдельная взаимодействующая сторона («первичней» взаимодействующая сторона в данном случае! к выгоде од ной или нескольких других взаимодействующих старой («вторичных.» взаимодействующих сторон) В >1чм случае, если дне (или более) взаимодействующие стороны предположительно обмснимаются данными в соответствии со -спецификацией, то эта спецификация сначала применяется к одной стороне, интер претируи ее как «первичную» •сторону, а затем —к другой(вм> сторонкам).

ГОСТ Р НСО/МЭК 9646-2-83

Это гарантирует точность в обнаружении неправильно действующей стороны а случае отклонения процедуры or нормы

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

BJ6 Аспекты. иолючаемыс из назначения, должны быть ясно указаны.

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

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

В2.Т Все факультативные функции, по возможности, должны быть точно определены и разделе «Назначение».

Факультативные возможности подставляют собой одну из самых трудоемких. но. к сожалению, необходимых частей спецификаций по протоколу. Они находятся между стандартизованными и нестзидарттюваяными Более подробно они будут рассмотрены ниже. Здесь же важно отметить, что Ути факультативные возможности не должны быть запрятаны глубоко в спецификации, з о них необходимо ясно сказать в самом начале Если количество и подробные свойства факультативных возможностей делают их непрактичными, следует серьезно поставить вопрос: действительно лк необходима такая сложность? Можно ли в целях упрощения специфика пин некоторым образом струп пировать-детализированные факультативные возможности (вйПрНМер В КЛАССЫ)?

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

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

ВЛ Руководство по нормативным -ссылкам

В 3.1 Стандарты и рекомендации МККТТ по протоколам ВОС должны: ссылаться на эталонную модель ВОС, на соответствующие стандарты и рекомендации МККТТ по'услугам к на другие соответствующие стандарты и ре-когендацнн МККТТ по протокольным соглашения и. руководящим матернв-чаж или методам фур налы юзанного описания

В.3.2 Следует ясно указать, должно ли соответствие данному стандарту или рекомендации М.ККТТ по протоколу означать соответствие какой-либо частя какого-то другого стандарта или рекомендации МККТТ.

В3.3 Следует ясно указать, означаем ли каждая ссылка конкретную версию указываемого стандарта или рекомендации МККТТ или каждую последующую версию.

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

5-1

ГОСТ Р ИСОМЭК 9646—2—93

В.4 Руководство ло ’требованиям н факультативным возможностям

В 4.1 Статус каждого требования должен быть недвусмысленным.

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

84 2 Должна обеспечиваться возможность соответствия сеанса обмена данными всея обязательным требованиям к динамическому соответствию

В43 Должны быть четко сформулированы условия, при которых применимы условные требования.

В4 4 Сведения об этих условиях должны быть доступны для разработчика и поставщика.

В 15 Должна быть исключена возможность путаницы между факультативными требованиями к динамическому соответствию и факультативными требованиями к статическом у соотиетстаию

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

В4б Если спецификация содержит «торговый перечень» факультативных возможностей и существуют ограничения, налагаемые на допустимые сочетания таких факультативных возможностей, то ути ограничения должны быть четко определены Она должны содержать идентификацию любых взаимных исключений и любых минимальных н максимальных пределов допустимого диапазона факультативных возможностей

В.4.7 Если в спецификации не приведено никаких правил по выбору фа-ку№тш?!ГЫХ РОТЯФжиф^’ей, В назначении следует указать, что стандартизации подлежат только общий диапазон н отдельные факультативные возможности, но не их выбор.

В43 Узаконенные факультативные возможности должны быть исключены. Эго те факультативные возможности, которые допускают альтернативные и несовместимые версии одного и того же свойства, соответствие которого заявлено в одном и том же стандарте или рекомендации МККТТ. И хотя сами по себе они ие препятствуют объективному пониманию соответствия, они могут нарушить цели ВОС.

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

В 4 10 Если в спецификации существуют запреты, их смысл должен быть достаточно точным.

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

В.5 Руководство по протокольным блокам данных

В 5.1 Допустимый набор типов ПБД-и кодов параметров должен быть ясно оговорен.

ГОСТ Р ИСО/МЭК 9646-2—93

В5.2 Допустимый диапазон значений должен быть четко указан для каждого параметра.

В.5 3 Вее значения, которые выходят за рамки установленного допустимого диапазона, должны бить якно определены как недействительные.

Если этого не сделано, некоторые будут считать, что sth значения не определены. но допустимы, а другие будут считать, что они недействительны.

В.5.4 Должно быть ясно, допустимы или нет неопределенные типы ПБД

Надежнее все неопределенные типы ПБД объявить недействительными.

В.55 Критически важные и неопределенные значения следует явно указать, в назначении как неопределенные.

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

В5.7 Должна обеспечиваться возможность определить: должна ли в таких случаях выполняться определенная процедура. Если не должна, то се не следует привлекать, поскольку ома но имеет значения.

Иногда при приеме недействительного ПБД сознательно выполняется та же процедура, что и яря приеме действительного ПБД в такой же ситуации. Например процедура может инчего нс выполнять, пока не будет принят ПБД конкретного типа, игнорируя псе остальное. В таких случаях, видимо, нс имеет* значения, что ошибка пройдет незамеченной. ‘В некоторых других случаях может ставиться задача подвергнуть ошибочные ситуации специальной обработке, но неправильный выбор процедуры приводит к тому, что ее действия нельзя отличить от действий в безошибочных ситуациях.

В5.8 Если при кодировании ПБД какие-либо поля заявлены как резервные, должно быть ясно указано, какие значения. при необходимости, допустимы или недопустимы в этих полях

В5.9 Если взаимосвязанные параметры могут быть переданы в отдельных: ПБД та должен быть точно и явно определен набор разрешенных взаимосвязей между значениями этих параметров.

В510 Если кодирование параметров допускает их определение в любом порядке, а формат ПБД налагает ограничения на этот порядок, то эти ограничения должны быть четко указаны. Должно быть ясно, что если разрешено множество различных упорядочений, то следует протестировать большую геред-ставительную выборку различных упорядочений Поэтому дополнительная сложность аттестационного тествроммня должна быть адекватно компенсирована: некоторым пройм ущесци»1 в предоставлении такой свободы

В 5.31 Порядок обработки би тов., октетов к г. д. в мижерасположелном протоколе должен быть четки определен.

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

B5.I2 Взаимосвязи между СБД и ПБД должны быть четко определены.

В.6 Руководство по состояниям

B6I Протокольные процедуры часто определяются путем использования метода конечных Состояний в формализованном млн неформализованном виде. Спецификации этих состояний часто является неполной.

В 62 Каждое состояние должно быть четко определено.

ВБ.З При наличии событий, которые могут произойти только в подмножестве возможных состояний. Возможное появление такого события должно отличаться от его действительного появления.

В.б4 Запрашиваемые действии н переходы состояний должны быть определены для каждой возможной пары состояние,/событие. В частости, нх следует определять как возможные, но недействительные пары сюстояние/событне.

ГОСТ Р ИСО/МЭК 9646-2-85

В.7 Руководство по методам формализованного описания

8.7 I Следующие требования применимы только к тем стандартам и рекомендациям МККТТ, которые содержат формализованное описание Точные недвусмысленные спецификации могут быть составлены без использования методов формализован но/о описания (МФО), но в сложных стандартах и рекомендациях МККТТ, таких как формализованные описания протоколов, подобные методы настоятельно рекомендуются. Ко сами они могут «отдать проблемы относительно соответствии

В7 2 Должно быть ясно указано, составляет ля формализованное описание существенную масть соответствующего стандарта я рекомендации МККТТ или оно предназначено тюльке з качестве руководства.

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

8.7.3 МФО должны быть четко определены, быть стабильными и за них должны быть даны соответствующие ссылки

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

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

Проблема обычно состоит в том. что формализованное описание описывает внутреннее поведение идеализированной реализации, а не наблюдаемое требуемое внешнее поведение Протестировано может быть только наблюдаемое внеш нее поведение, и поэтому тюльки оно может составлять требования для целей соответствия Бывает полезно, что для определения требований к руководства для разработчиков используются различные МФО.

8.8 Прочие руководства

Ин-формапия, которая может выглядеть очевидной, должна быть, тем нс менее, приведена.

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

ГОСТ Р ИСО/МЭК ЭМв—2-М

ПРИЛОЖЕНИЕ С (справочное)

НЕПОЛНЫЕ ТРЕБОВАНИЯ К СТАТИЧЕСКОМУ СООТВЕТСТВИЮ

С-1 Некоторые спецификации по протоколам не обеспечивали полной спе-цификаини требований к статическому соответствию.

CJ В этом случае следует обратиться к форме ЗСРП для выяснения вопроса, какие существуют требования к статическому; соответствию.

С.3 При отсутствии стандартной формы ЗСРП разработчик КАТ может принять для себя и ясно заявить, что все те возможности, которые явно не ох-качены в требования?; к статическому соответствию, являются факультативными.

С.4 Чтобы минимизировать возможные проблемы, разработчик КАТ может определить. что:

з> при получении аттестуемой реализации:

I) должно быть реализовано все. что явно указано как обязательное;

21 не опущено ничего, если только это явно не указано как факультативное. даже при наличии общего положения типа «если не специфицировано, то факультативно»;

Ь) при передаче аттестуемой реализации:

I) должно быть реализовано все. что явно указано как обязательное;

2) может быть опущено все, что явно не определено как факультативное, возможно из-за общего положения тина: «если нс специфицировано, то факультативно».

ГОСТ Р ИСО/МЭК 9646 — 2—9$

ПРИЛОЖЕНИЕ D (справочно?)

РУКОВОДСТВО ПО ОБЩИМ ТЕСТОВЫМ ПРИМЕРАМ

D1. Введение

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

02. Описание общих тестовых пример оз

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

Тело теста должно:

а) -быть определено с использованием метода тестирования РО или УО для того, чтобы исключить необходимость определять поведение любых других протоколов., кроме находящихся и -фокусе тестировании, н тем самым обеспечить как можно большую независимость метода тестировании;

Ь) назначать вердикты и теле теста согласно 13,2.6.

0.3 Отношение общего тестового примера к абстрактному

Если общие тестовых: примеры определены а соответствии с руководством, содержащиеся к данном приложении, то основные различия между общим и. абстрактным тестовыми приорамн будут состоять « следующем-

а) абстрактный тестовым пример содержит спецификацию преамбулы и постамб-улы теста;

Ь) используемый для тела теста метод тестирования может отличаться

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

0.4 Образование абстрактных тестовых примеров из общих тестовых примеров

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

£>.4.2 При преобразовании общему тестового примера о абстрактный тестовый пример разработчик КАТ должен сохранять начальное состояние тестирования для данного тела теста, а также последовательность тестовых событий, определяющих полные маршруты через тело теста, вместе с соответствующими вердиктами.

ГОСТ Р ИСО/МЭК 9646-2-93

УДК 681.324 : 006.354

П85

Ключевые слова: информационная технология, взаимосвязь открытых систем, методология, основы аттестационного тестирования. спецификация комплекта абстрактных тестов, системно-независимые тесты, точность выполнения, статическое соответствие, динамическое соответствие, тестовый пример, протокольные блоки данных, абстрактные сервисные примитивы ОКСТУ Ж»’

Редактор fi М. Лысенкика Технический редактор О. Н. Никитина

Корректор Н- Л. Шнайдер

Слепо J илО 47.01?» Подо, н not СТ.О» 9». Усл. п л. 3.?2. Усд пр. Отт 3.95. Уч.-НЭД л <10

Тир. ЭМ >кд. С 117»._____________________________________

Ордене «Зи»к Пе*»м» Ихмтыытяо стоилдртоя. ютотб. моссм. колохши» пер., и.

Калужская тепогоаФк» стаииртов ул. МоСкоккая. 256 Зэк 239

allgosts.ru

Превью ГОСТ Р ИСО/МЭК 9646-2-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 2. Спецификация комплекта абстрактных тестов