– 4  –

ТЕСТИРОВАНИЕ ВЗАИМОДЕЙСТВИЯ ОТКРЫТЫХ СИСТЕМ

Взаимодействие двух реальных систем можно охарактеризовать поня­тием соответствия, если оно удовлетворяет требованиям Рекомендаций OSI ITU или ISO, в состав которых включены положения, определяю­щие протоколы взаимодействия и синтаксис преобразования, а также комплекс взаимосвязанных положений, совместно определяющих ре­жим работы открытых систем при их взаимодействии. Поэтому соот­ветствие реальной системы стандартам выражается на двух уровнях, представляющих соответствие каждой отдельно взятой Рекомендации и набору стандартов. Если же процесс взаимодействия основан на сово­купности Рекомендаций в виде функционального стандарта или профи­ля, концепция соответствия может быть расширена до специфических требований этих документов, если они не противоречат требованиям базовых (протокольных) Рекомендаций. Рассмотрим вопросы тестиро­вания на примере рекомендаций [34], включая некоторые аспекты сер­тификационного тестировании

 

4.1. ТРЕБОВАНИЯ СООТВЕТСТВИЯ

 

Согласно рассматриваемым далее рекомендациям, требования соответ­ствия могут представлять собой:

•     обязательные требования, которые должны выполняться во всех случаях;

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

•     дополнительные требования, которые могут быть выбраны для конкретного процесса при условии, что выполняются все требо­вания, применимые к данному параметру спецификации.

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

Используемые здесь термины «необходимые средства» и «дополни­тельные средства» следует рассматривать в контексте затрагиваемой области Рекомендации CCITT; например, во многих случаях необходи­мые средства являются обязательными для сетей, но не для DTE.

Более того, требования соответствия в Рекомендации CCITT или ISO могут быть выражены результатом:

•     положительно, если они предписывают, что должно быть сделано;

•     отрицательно, если они предписывают, что не должно быть сде­лано.

Наконец, требования соответствия можно подразделить на две группы:

•     требования соответствия по статике;

•     требования соответствия по динамике.                          

Рассмотрим эти требования в связи с сформулированным понятием со­ответствия ВОС.

 

4.1.1.  Требования соответствия по статике

 

Требования соответствия по статике — это требования, которые опреде­ляют совокупность допустимых характеристик реальной системы по CCITT или ISO и представляют собой минимально допустимый набор параметров, обеспечивающих процесс сетевого взаимодействия. Они могут быть заданы на широком уровне, например, подобном PDU, сгруп­пированном в функциональные группы или классы протоколов, или на детализированном уровне, подобном диапазону значений, которые дол­жны поддерживаться для определенных параметров или синхронизи­рующих устройств.

Требования соответствия по статике в Рекомендациях OSI CCITT и ISO могут быть двух видов:

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

•     требования, определяющие многоуровневые зависимости, напри­мер, те, которые определяют допустимые характеристики распо­ложенных ниже уровней OSI системы, в которой происходит процесс выполнения протокола

 

4.1.2.  Требования соответствия по динамике

 

Требования соответствия по динамике — это требования, которые опре­деляют допустимый режим OSI согласно CCITT или ISO. Они образуют основную часть спецификации каждого OSI протокола и определяют набор допустимых режимов реальной системы или процесса взаимодей­ствия систем. Этот набор допустимых режимов полностью определяет максимальную совокупность характеристик, связанных с использованием OSI протокола в соответствующем процессе его выполнения, либо в реальной открытой системе.

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

 

4.1.3.  Отчет соответствия выполнения протокола

 

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

В PICS должно быть строгое разграничение следующих категорий информации:                                                                                    

•     информация, связанная с обязательными, дополнительными и ус­ловными требованиями соответствия по статике самого протокола;

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

По окончании выполнения в системе всего набора взаимосвязанных OSI протоколов для каждого протокола необходимо сформировать PICS, a также составить документ о соответствии системы. В этом документе должны быть перечислены по пунктам все протоколы, для которых предоставлен PICS.

 

4.1.4.  Процесс взаимодействия и соответствие

 

Несмотря на то, что соответствие представляет собой необходимое усло­вие, само по себе оно не является достаточным для того, чтобы гаранти­ровать требуемое взаимодействие. Даже если два процесса выполнения отвечают одной и той же спецификации OSI протокола, может возник­нуть ситуация, когда они не в состоянии полноценно взаимодейство­вать. Поэтому рекомендуется проведение пробного взаимодействия. Успешное взаимодействие двух или более реальных открытых сис­тем более вероятно в том случае, когда они все соответствуют одной и той же подгруппе Рекомендаций OSI CCITT или ISO или одному разделу Рекомендаций OSI CCITT или ISO.

Для подготовки двух и более систем к успешному взаимодействию рекомендуется провести сравнение документов о соответствии системы и PICS этих систем. Если PICS указывают, что были выполнены разные подгруппы или версии Рекомендаций OSI CCITT или ISO, природа раз­личий и их значение для взаимодействия должны быть обязательно установлены, а исследование должно быть проведено как для опций в самих протоколах, так и для совместного использования протоколов в OSI системе. Более подробную информацию, способствующую налажи­ванию взаимодействия между двумя системами можно получить путем сравнения с другой соответствующей информацией, включая отчеты о тестировании и PIXIT. Сравнение может быть сосредоточено на:

•     дополнительных механизмах, призванных функционировать в об­ласти уже известных неоднозначных случаев или недостатков, еще не откорректированных в Рекомендациях CCITT или ISO, или в других реальных открытых системах, с которыми необходимо вза­имодействие, например, решение многоуровневых проблем;

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

Сравнение может быть выполнено для двух отдельных систем, двух и более типов продуктов или только для PICS, двух и более специфика­ций поставки оборудования, разрешения на соединение и т. д.

 

4.2. СООТВЕТСТВИЕ И ТЕСТИРОВАНИЕ

 

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

 

4.2.1. Виды тестирования на соответствие

 

Различают четыре типа тестирования в зависимости от требуемой сте­пени (глубины) обеспечения соответствия:

•     базовое тестирование взаимодействия, которое обеспечивает доказательство соответствия тестируемой реализации в случае от­сутствия доказательств от противного;

•     тестирование характеристик, когда проверяется утверждение, что имеющиеся характеристики ШТ удовлетворяют требованиям со­ответствия по статике и характеристикам, заявленным в PICS;

•     тестирование поведения, при котором стремятся обеспечить все­объемлющее тестирование для полного диапазона требований со­ответствия по динамике, определенных Рекомендациями CCITT или ISO в пределах характеристик ШТ;

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

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

Для тестирование ШТ с целью установления достаточного соответ­ствия при организации взаимодействия без последующего тщательного тестирования существуют базовые тесты взаимодействия (BIT). Эти те­сты могут быть использованы:

•     для обнаружения серьезных случаев несоответствия;

•     в качестве предварительного этапа для определения того, необхо­димо ли проводить дальнейшее тестирование характеристик и поведения;

•     для проверки адресации и других положений, связанных со сре­дой тестирования;

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

BIT не могут быть использованы:

•     когда они проводятся сами по себе, в качестве основы для заявки на установление соответствия поставщиком услуг;

•     для определения причин неисправности связи.

Стандартизированные BIT всегда выводятся из набора тестов характе­ристик и поведения, включая стандартизированную абстрактную тесто­вую последовательность.    

                                                                    

Тестирование характеристик

 

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

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

•     для более полной проверки согласованности PICS с IUT;   

•     в качестве основы для заявки при проведении тестирования на соответствие совместно с тестированием поведения.

В то же время тестирование характеристик не может использоваться:

•     когда оно проводится само по себе для заявки на соответствие от поставщика услуг;

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

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

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

 

Тестирование поведения

 

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

Тестирование поведения стандартизировано как основная часть стан­дартизированной ATS и включает тесты действительного поведения IUT в ответ на действительное и недействительное поведение средства тес­тирования нижнего уровня.

 

4.2.2. Оценка порога разрешения

 

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

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

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

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

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

•     для исследования проблем, возникающих при выполнении стандартизированной ATS.

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

 

4.2.3. Дополнительная информация о выполнении протокола

 

Чтобы протестировать процесс выполнения протокола, лаборатории те­стирования потребуется информация относительно ШТ и его среды те­стирования в дополнение к информации, предоставленной в PICS. Эта дополнительная информация о выполнении протокола для тестирова­ния предоставляется клиентом, после чего лабораторией тестирования заполняется бланк PIXIT, который может содержать следующее:

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

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

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

•     другую административную информацию (например, данные об иден­тификации ШТ, ссылки на родственный PICS и т. д.).

PIXIT не должна противоречить родственному PICS, и для каждой ATS, проводимой для ШТ, существует одна PIXIT. Составитель ATS, исполни­тель и лаборатория тестирования могут вносить изменения в бланк PIXIT.

 

4.2.4. Обзор процесса оценки годности

                       

Процесс оценки годности (рис. 4.1) представляет собой полный процесс проведения процедур тестирования, которые необходимы для того, что­бы добиться соответствия системы или процесса выполнения одной или более Рекомендациям OSI CCITT или ISO. Данный процесс включает три этапа:                                                                                       

1.   подготовку к тестированию;

2.   выполнение тестирования;

3.   предоставление отчетов о тестировании.

В соответствии с данным делением на первом этапе осуществляется:

•    создание документа о соответствии системы, PICS и PIXIT;

•     выбор метода абстрактного тестирования и ATS, основанных на этих документах;

•     подготовка SUT и средств тестирования. На втором этапе:

•     определяется соответствие по статике, которое осуществляется путем анализа PICS касательно соответствия по статике;

•     выбирается тест и осуществляется параметризация, которые ос­нованы на PICS и PIXIT;

•     проводится один или более «процессов тестирования».

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

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

Процесс тестирования включает три следующих типа тестов:          

•     BIT (дополнительно);

•     тестирование характеристик;                                                        

•     тестирование поведения,

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

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

            

4.2.5. Анализ результатов и заключение о тестировании

        

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

Заключение о тестировании может быть типа «прошел», «не про­шел» или «неубедительно»:

•     «Прошел» означает, что полученный результат тестирования от­вечает требованиям соответствия, для данной процедуры тести­рования, и отвечает Рекомендациям CCITT и Международным стандартам.

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

•     «Неубедительно» означает, что наблюдаемый результат тестиро­вания таков, что не может быть дано ни одно из вышеназванных заключений и поэтому полученный результат тестирования сви­детельствует о соответствии требованиям данной процедуры тес­тирования и отвечает соответствующим Рекомендациям CCITT и Международным стандартам.

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

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

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

• отчете о тестировании системы (SCTR), который создается всегда и представляет собой краткий обзор соответствия SUT, включая краткое содержание заключений, сделанных во время процесса оценки годности;

• отчете о тестировании соответствия протоколов (PCTR), один из которых создается для каждого протестированного в SUT протокола. В последнем отчете документируются все результаты процедур тестиро­вания и дается ссылка на паспорт соответствия, который содержит полу­ченные результаты тестирования. PCTR, а также на все документы, связанные с проведением процесса оценки годности для данного протокола.

 

4.3. ОСНОВНЫЕ ПОКАЗАТЕЛИ РЕЗУЛЬТАТОВ  ТЕСТИРОВАНИЯ

 

К основным показателям результатов тестирования относятся: повторя­емость, сопоставимость и доступность. Рассмотрим данные показатели более подробно.

Повторяемость результатов. Для достижения цели надежного тес­тирования соответствия очевидно, что результат выполнения процеду­ры тестирования в IUT должен быть одним и тем же, независимо от времени выполнения тестирования. Однако на практике может возник­нуть ситуация, когда невозможно выполнить полную последователь­ность тестов соответствия и получить результаты, идентичные получен­ным в ином случае. Несмотря на это, на уровне процедуры тестирования, очень важно чтобы были предприняты все усилия для минимизации возможности получения различных результатов при проведении проце­дур тестирования в разных условиях.                                 Сопоставимость результатов. Стандартизация всех процедур, свя­занных с тестированием соответствия, должна приводить к созданию согласованных с IUT и сопоставимых заключений о тестировании неза­висимо от того, проводится ли тестирование поставщиком, пользовате­лем или лабораторией тестирования. Существует большое количество факторов, которые следует учитывать при достижении этой цели, наи­более важными из которых являются следующие:

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

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

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

•     бланк для отчета тестирования соответствия;

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

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

 

4.4. МЕТОДЫ ТЕСТИРОВАНИЯ

 

В настоящее время имеется большое разнообразие систем передачи, от­личающихся как структурой построения, так и характером протекания в них информационных процессов, что в значительной степени опреде­ляется протоколами взаимодействия открытых систем и по этой причи­не требует применения различных способов их контроля. Учитывая дан­ное обстоятельство, не вызывает сомнения необходимость создания методов тестирования, которые могли бы использоваться в соответствии с имеющимися возможностями контроля тестируемой системы. Для решения данной задачи CCITT разработал рекомендации Х.290 - Х.294, являющиеся сегодня фундаментальной основой современных техноло­гий тестирования сетей телекоммуникаций. Для применения данной идеологии не только для тестирования, но и при измерениях и анализе параметров сети вначале рассмотрим основные характеристики SUT, затем в абстрактных терминах определим возможные методы тестиро­вания и, наконец, дадим рекомендации по использованию последних с целью диагностирования и прогнозирования поведения сети. При этом для соблюдения строгости изложения будем различать управление и наблюдение как составляющие тестирования, рассматриваемые со сто­роны входа и выхода контролируемого объекта или процесса.

 

4.4.1. Классификация открытых систем для тестирования соответствия

 

Как было отмечено выше, тестирование взаимодействия открытых сис­тем в первую очередь определяется характеристиками SUT, из которых наиболее важными являются:

•     основное функциональное назначение системы (конечная систе­ма или регенерирующая система);

•     используемые для выполнения этих функций протокольные уровни OSI;

•     возможность альтернативного применения отличных от OSI про­токолов.

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

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

•     конфигурации 2, которая соответствует частично (N) открытой

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

• конфигурации 3, в которой OSI протоколы используются на уров­нях от 1 до 3 (сетевые регенерирующие системы) или от 1 до 7 (прикладные регенерирующие системы).

Все другие системы могут рассматриваться в виде комбинаций приведен­ных базовых конфигураций, например, семиуровневой системы, сочета­ющей конфигурации 1 и 2 (рис. 4.3) и отражающей альтернативное ис­пользование OSI и лежащих выше уровня N отличных от OSI протоколов.

 

4.4.2.  Определение IUT

                                   

IUT представляет собой часть реальной открытой системы, которая дол­жна быть изучена посредством тестирования процесса выполнения од­ного или более связанных OSI протоколов на одном или на соседних уровнях модели. При этом IUT могут быть определены для конфигура­ций SUT типа 1 и 2 либо как однопротокольные IUT (должен быть протестирован один протокол SUT), либо как многопротокольные IUT (необходимо протестировать комбинацию определенного количества процессов выполнения протоколов в SUT). Очевидно, что IUT, опреде­ляемый в открытой регенерационной системе, будет включать, по край­ней мере, уровень, который обеспечивает функцию регенерации. Когда в одной системе присутствуют как OSI, так и иные протоколы, ШТ определяются для OSI модели(ей) функционирования, а тестирование отличных от OSI протоколов не рассматривается, считая, что оно выхо­дит за рамки задачи тестирования.

Предметом согласования между лабораторией, проводящей тестиро­вание, и клиентом в этом случае является часть SUT, которая в даль­нейшем будет рассматриваться как ШТ.

 

4.4.3.  Методы абстрактного тестирования

 

Все существующие методы тестирования можно рассматривать исходя из методологии абстрактного тестирования, базирующейся на эталон­ной модели OSI, а также входных или выходных контрольных точек (РСО) конечных систем (семиуровневых или частично (N) открытых систем) или однопротокольных IUT.                                                      

Рекомендации CCITT и Международные стандарты, определяющие OSI протоколы, регламентируют допустимое поведение (требования со­ответствия по динамике) протокольного объекта в виде PDU и ASP, имеющих место выше и ниже этого объекта. Поэтому поведение (N)-объекта определяется в терминах (N)-ASP и (N — 1)-ASP (последние включают (N)-PDU).

Если IUT охватывает более одного протокольного объекта, поведение также может быть определено в терминах ASP выше и ниже IUT, вклю­чая, естественно, и PDU.

Базой развития методов абстрактного тес­тирования послужила архитектура концепту­ального тестирования, приведенная на рис. 4.4 и являющаяся фактически архитектурой активного тестирования «черного ящика» путем определения поведения IUT.

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

 

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

•     границей услуг в рамках OSI модели, где осуществляется наблю­дение и управление тестовыми событиями;

•     набором тестовых событий (ASP или PDU), которые наблюдаются и контролируются в этой точке;

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

Все разнообразие контрольных точек представлено на рис. 4.5, из кото­рого можно заключить, что теоретически существует большое количе­ство точек, отражающих в той или иной степени различную глубину исследования поведения ШТ. В настоящее время имеется возможность выбора из всего набора возможных контрольных точек тех, которые определяют конечное число методов абстрактного тестирова­ния, использующих эти точки в стандар­тизированных абстрактных последова­тельностях тестирования (ATS).

В зависимости от того, по какому па­раметру осуществляется тестирование, следует различать характер управления и наблюдения. Так, при тестировании по ASP оно будет включать PDU, выполня­емые в соответствии с этими ASP. В то же время для PDU на уровне N нижние ASP управлению и наблюдению не будут подвергаться. Тогда РСО могут быть представлены в виде мо­дели двух очередей:

•     выходной — для управления тестовыми событиями, которые бу­дут отправлены по направлению к IUT;

•     входной — для наблюдения тестовых событий, полученных от ШТ.

Активность ASP ниже IUT может наблюдаться и управляться соответ­ствующим воздействием на тестируемую систему через расположенный ниже сервис-провайдер, предполагая, что его услуги достаточно надеж­ны для осуществления удаленного управления и наблюдения.

В тех случаях, когда активность ASP над IUT неуправляема и ненаблюдаемая, следует говорить о скрытой активности.

Несмотря на то, что SUT не должны обеспечивать доступ к границам услуг, возможное обеспечение и расположение границ этого доступа по отношению к протоколу IUT являются факторами, которые следует принимать во внимание при определении методов абстрактного тести­рования, так как они могут использовать преимущества такого доступа для определения ATS в терминах соответствующих ASP. В этом случае не имеет значения, получен ли доступ к границам через точки доступа услуги (SAP) или через какие-либо контрольные точки.

 

4.4.4.  Функции абстрактного тестирования

 

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

Средство тестирования нижнего уровня представляет собой сред­ство, которое во время выполнения тестирования позволяет осуществ­лять через сервис-провайдера непрямое управление и наблюдение ниж­ней границы услуг IUT. Этот сервис использует один или более OSI уровней или только физическую среду и расположен под нижним про­токольным уровнем, являющимся основным объектом тестирования.

Средство тестирования верхнего уровня — это средство, которое во время абстрактного тестирования обеспечивает управление и наблюде­ние верхней границы услуг IUT.

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

 

4.4.5.  IUT конечных систем

 

Для IUT, определенных в рамках SUT конечных систем, выделяют че­тыре класса методов абстрактного тестирования, два из которых ис­пользуют контрольные точки между средством тестирования верхнего уровня и IUT (локальный и распределенный методы тестирования), а два других метода используют только одну контрольную точку под сред­ством тестирования нижнего уровня (координированный метод и метод удаленного тестирования). Все эти методы основаны на воздействии и наблюдении ASP ниже IUT и PDU, взаимодействуя с IUT посредством отдельного от SUT средства тестирования нижнего уровня, возможно, взаимодействующего с управлением и наблюдением ASP над IUT.

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

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

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

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

Координированный метод и метод удаленного тестирования. В отли­чие от рассмотренных выше методов тестирования координированный метод и метод удаленного тестирования характеризуются использова­нием одной контрольной точки, которая расположена ниже средства тестирования нижнего уровня, не требуя доступа к верхней границе услуг ШТ. При этом в координированном методе тестирования (рис. 4.6с) процедуры координации выполняются посредством стандартизи­рованных протоколов управления тестированием (ТМР), а средство тес­тирования верхнего уровня представляет собой реализацию соответству­ющего ТМР.

В методе удаленного тестирования могут возникнуть или быть не­формально выражены в ATS некоторые требования к процедурам коор­динации тестирования, однако в Рекомендациях отсутствуют предполо­жения относительно возможности их осуществления или реализации. Здесь нет средства тестирования верхнего уровня как такового, но не­которые его функции могут выполняться SUT.

Этот метод иллюстрируется на рис 4.6d, где пунктирные линии озна­чают, что в ATS описываются только желаемые эффекты процедур ко­ординации тестирования.

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

 

4.4.6.  IUT систем регенерации

 

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

Очевидно, что каждый из рассмотренных методов предпочтительней в каких-то определенных случаях и имеют свою область применения, а именно:

•     локальные методы тестирования — тестирование SUT, имеющих два аппаратных интерфейса (например, трансиверов);

•     распределенные методы тестирования — только тестирование IUT, которые имеют верхний интерфейс, доступный либо для челове­ка-пользователя, либо для программного обеспечения средства тестирования верхнего уровня со стандартизированным програм­мируемым языковым интерфейсом;

•     координированные методы тестирования — тестирование, где есть возможность выполнения стандартизированного ТМР в средстве тестирования верхнего уровня в SUT над IUT;

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

•     метод одноуровневого тестирования — лучше всего использовать для тестирования большинства требований соответствия протоколов;

•     вложенные варианты методов тестирования — одноуровневое те­стирование для всех протоколов многопротокольного ШТ.

Для семиуровневых открытых систем предпочтительными методами тестирования являются соответствующие одноуровневые вложенные методы тестирования, используемые с приращением (incrementally) и со следующими контрольными точками:

•     если возможно — верхним интерфейсом прикладного уровня, обес­печенным семиуровневой открытой системой;

•     последовательно каждая управляемая и наблюдаемая в средстве тестирования нижнего уровня, начиная с самого нижнего объек­та тестирования (протокола IUT) и далее вверх точка доступа ус­луги (SAP) или соответствующая контрольная точка, если SAP как таковой нет.

 

4.4.7.  Тестирование протоколов OSI

 

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

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

Канальный протокол. Для тестирования протоколов канального уров­ня необходимо учитывать, что:

•     локальный одноуровневый метод тестирования применим, толь­ко если IUT имеет стандартизированный аппаратный интерфейс верхнего уровня;

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

Сетевой протокол. Для тестирования сетевых протоколов использова­ние тех или иных методов зависит от того, является ли IUT конечной системой или открытой ретрансляционной системой, так как для обес­печения сетевой услуги при использовании некоторых подсетевых тех­нологий необходимо более трех протоколов, причем каждый из этих протоколов может быть протестирован отдельно или в сочетании с дру­гими протоколами. Рассматривая уровень в целом, сетевая и канальная ASP могут быть подвергнуты управлению и наблюдению, поэтому для конечных систем применимы все четыре одноуровневых (не вложен­ных) метода тестирования. Однако, ввиду того, что услуга канала пере­дачи данных не является сквозной, средство тестирования нижнего уров­ня должно быть присоединено к SUT посредством одного канала. Для ретрансляционных систем применим как метода тестирования по шлей­фу, так и метод двустороннего тестирования.

Транспортный протокол. Для тестирования транспортного протокола применимы вложенные координированный и распределенный методы, а также метод удаленного тестирования.

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

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

2.   удаленным и распределенным одноуровневыми вложенными ме­тодами тестирования протокола представления данных и ASE, для того, чтобы протестировать его в специфическом прикладном контексте.

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

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

Уровень приложений. В данном случае тестирование может быть за­дано абстрактно в терминах примитивов услуги, независимо от того, существует ли какое-либо ассоциируемое с ними понятие о SAP или нет. Допуская, что между примитивами ASE и эффектами существует некоторое соответствие и их можно наблюдать и/или управлять ими, тестирование может быть определено в терминах этих примитивов. При некоторых обстоятельствах Рекомендации CCITT или международные стандарты, определяющие прикладной контекст приложений, могут устанавливать непротокольные требования соответствия, которые дол­жны выполняться как результат обмена протоколами. Однако такие требования должны быть достаточно четкими и дистанцироваться от нормальных требований соответствия протоколов, возможно даже в от­дельные Рекомендации CCITT или международные стандарты. Тестиро­вание непротокольных требований соответствия будет в общем требо­вать использования зависящих от данного приложения методов тестирования и, таким образом, выходить за пределы действия рассмот­ренных методов. При тестировании специфических ASE в прикладном контексте, который включает ACSE, РСО ниже средства тестирования нижнего уровня будет охарактеризована набором возможных ASP, ко­торые могут иметь в ней место. Последние будут включать оба ASR — ACSE и представления данных.

 

4.5.  ПОСЛЕДОВАТЕЛЬНОСТИ ТЕСТИРОВАНИЯ

 

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

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

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

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

 

4.5.1. Абстрактная и исполняемая процедуры тестирования

 

Абстрактная процедура тестирования создается исходя из цели тести­рования (или комбинации целей тестирования, как определено состави­телем последовательности тестирования) и соответствующих OSI CCITT Рекомендаций или Международных стандартов. Такая процедура:

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

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

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

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

•     использует стандартизированную запись тестирования для спе­цификации всех последовательностей тестовых событий;

•     может состоять из этапов тестирования, каждый из которых пред­ставляет собой последовательность тестовых событий;

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

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

Исполняемая процедура тестирования выводится из абстрактной про­цедуры и находится в форме, которая позволяет ей быть выполненной системой тестирования в сочетании с SUT.                                           

Здесь и далее по тексту термины «абстрактная» и «исполняемая» последовательности используются для описания последовательностей тестирования, которые включают абстрактные и исполняемые процеду­ры тестирования, соответственно.                                                         

4.5.2. Структура и связь рекомендаций тестирования

 

Выше были изложены общие концепции и определения, которые отно­сится к созданию спецификаций и тестированию протокола, а также к стандартам тестирования ВОС.

Далее будут рассмотрены вопросы создания спецификации ATS и реализации тестирования, включая связь рассмотренных Рекоменда­ций с процессами создания абстрактных и исполняемых последователь­ностей тестирования и отчетов о тестировании, которая представлена на рис. 4.8.

 

4.6. МЕТОДЫ И СТРУКТУРА ТЕСТИРОВАНИЯ q ВЗАИМОДЕЙСТВИЯ ОТКРЫТЫХ СИСТЕМ

 

В соответствии с Рекомендацией Х.291 спецификация абстрактной тес­товой последовательности (ATS) должна:

•     отражаться в системе обозначений теста по CCITT или ISO/IEC;

•     отвечать требованиям, изложенным в Х.290;

•     являться Рекомендацией CCITT или ISO/IEC, а при отсутствии таковой должна быть общедоступным документом, находящимся в процессе стандартизации в CCITT или ISO/IEC.

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

В качестве системы обозначений рекомендуется использовать TTCN, так как в этом случае ATS будет соответствовать рассматриваемым да­лее методам тестирования.

 

4.6.1. Требования к соответствию OSI

 

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

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

•     четко определять, что подразумевается под соответствием Реко­мендации CCITT и Международному стандарту в плане того, что должно быть проделано, что разрешено, но не обязательно и что не должно быть выполнено для данного соответствия. Каждая СС1ТТ Рекомендация или Международный стандарт, которые определяют OSI протокол или синтаксис, должны включать недвусмыс­ленно выраженный пункт соответствия, проводящий разграничения между следующими категориями информации:

•     ссылками на пункты, которые формулируют динамические тре­бования соответствия;

•     статическими требованиями соответствия в том, что касается выполнения протокола;

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

Требование к созданию PICS по бланку PICS должно быть сформулиро­вано отдельно от требований к выполнению протокола как такового, при этом пункт соответствия должен включать:

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

•     требование правильно реагировать на все неверные полученные последовательности PDU;

•     в протоколах, ориентированных на связь, — опцию поддержки начала связи, принятия связи, либо обе опции;                       

•     в протоколах без установления соединения — опцию поддержки передачи PDU, прием PDU или и то и другое.

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

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

Бланк PICS точно определяет разрешенное спецификацией протоко­ла выполнение и подробно описывает в табличной форме:

•     опции, дополнительные тем, которые обязательны для выполне­ния;

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

В некоторых случаях бланк PICS используется:

•     исполнителями или поставщиками при необходимости докумен­тирования процесса выполнения;

•     составителями ATS, которым нужно гарантировать, что структу­ра тестовой последовательности соответствует разрешенной;

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

Окончательный бланк PICS для рассматриваемого процесса выполне­ния вносит вклад в процесс оценки соответствия, где осуществляется:

•     определение соответствия по статике;

•     отбор средств тестирования в качестве средств адаптации Осуще­ствимой Тестовой Последовательности к опциям, поддерживаемым процессом выполнения;                                                                   

•     процесс анализа результатов и формирования контрольного доку­мента.

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

Ниже изложены требования и руководство к структурированию бланка PICS, а также вопросы ограничений по его использованию. Из-за боль­шого разнообразия протоколов представить общий бланк PICS не пред­ставляется возможным, однако некоторые общие правила могут быть применены к любой спецификации OSI протокола.

 

4.6.2. Взаимосвязь между бланками PICS и требованиями к соответствию

 

Бланк PICS представляет собой набор вопросов, связанных с возможно­стями протокола, являющимися, в свою очередь, набором функций, которые необходимо обеспечить в процессе его выполнения. При этом требования соответствия по статике OSI протокола определяют правила для процесса реализации его возможностей. Каждое задание или ввод­ная часть бланка PICS должны указывать статус каждой функции про­токола в соответствии с этими правилами. Статус может быть:

•     обязательным, когда эта возможность запрашивается для выпол­нения в соответствии со спецификацией протокола;

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

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

•     не применимым, когда ни одно требование не может быть выра­жено в предложенном контексте;

•     условным, когда требование по возможности зависит от выбора „г. >.     других выборочных или условных единиц; бланк PICS не может

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

Введение в бланк PICS должно иметь область для записи предписания поставщика IUT относительно обеспечения возможностей протоколов в процессе их выполнения в виде:

•     возможности выполнения;

•     невозможности выполнения;

•     других относящихся к протоколу категорий поддержки.

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

Введение в статус бланка PICS точно устанавливает процедуры, кото­рые нужно провести во время определения соответствия по статике, в то время как в бланке PICS определяются дополнительные специаль­ные процедуры, которые нужно провести во время определения соот­ветствия по статике.                                                                               

Бланки PICS должны быть представлены в форме, отпечатанной в соответствии с CCITT Рекомендацией или Международным стандартом, что поднимает вопрос об авторском праве в том, что касается текста данной части CCITT Рекомендации или Международного стандарта. Поэтому в приложении бланка PICS должна иметь место сноска на пер­вой странице, где определяется, что «В этом приложении пользователи данной Рекомендации могут свободно воспроизводить бланк PICS с тем, чтобы его можно было использовать для намеченной цели, а также мо­гут в дальнейшем придавать огласке законченный вариант PICS».

Первый раздел (Идентификация выполнения) PICS должен устанавли­вать:

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

•     поставщика системы и/или клиента лаборатории тестирования, которые будут тестировать процесс выполнения;

•     контактное лицо на случай возникновения каких-то вопросов от­носительно содержания PICS;

•     взаимодействие PICS с Предписанием Соответствия Системы для данной системы.

Второй раздел (Идентификация протокола) определяет CCITT Рекомен­дацию или Международный стандарт, к которым может быть приме­ним бланк PICS в виде номера ссылки CCITT или ISO/IEC, а также полное заглавие. Если OSI протокол предоставляет ссылку на вариант, то второй раздел также должен ссылаться на другое введение в Бланк PICS, где представлена подробная информация по статусу и поддержке подобного параметра и возможно его согласование.

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

При адаптации к большинству OSI протоколов в PICS могут быть отражены рассматриваемые ниже вопросы:

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

Основные возможности. Несмотря на определение статуса, бланк PICS должен иметь вводную часть для каждой основной возможности. При этом все функциональные возможности протокола могут быть разделе­ны на большие «блоки» процессов выполнения (т.е. функциональные наборы, сервисные классы, сервисные элементы, классы протоколов). Если это так, то бланк PICS должен предоставить для каждого такого «блока» статус соответствия возможности и обеспечить пространство для предписания поддержки исполнителя. Подобные определения дол­жны быть включены в отдельные разделы бланка PICS, за исключени­ем случая, когда протокол содержит только один подобный «блок». Так как такие «блоки» ссылаются на основные возможности и формулиру­ются в требованиях соответствия по статике в спецификации протоко­ла, в зависимости от его вида основные возможности могут соответство­вать группе PDU с целью совместного выполнения или же какому-то глобальному аспекту, схожему с несколькими PDU.

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

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

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

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

•     статусом, основанным на установлении каждого направления в виде отсылка/получение;

•     пространством, для определения того, поддерживается или нет данный параметр по каждому из направлений;

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

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

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

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

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

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

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

•     колонкой слева для присвоения каждому ряду номера ссылки с целью обеспечения однозначности ответов в пределах бланка PICSb следующей последовательности:

■   обращение к наименьшему подпункту, включающему соответствующий пункт,

■   обозначение слэш «/»,

■   номер ссылки ряда, в котором появился ответ; если только в ряду появляется более одного ответа, идентифицированного номером ссылки, то каждый вероятный ввод неявно маркиру­ется а, Ь, с, и т. д. слева направо, и буква прилагается к после­довательности;

•     одной колонкой для обозначения пункта для каждого ряда;

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

•      совокупность в свою очередь может содержать:

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

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

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

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

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

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

■   пространство справа, в которое при необходимости могут быть вставлены дополнительные колонки для предоставления возмож­ности пользователю бланка PICS внести свои комментарии.

Пример возможных таблиц бланка PICS представлен в табл. 4.1 — 4.3.

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

•     m или М для обязательного;

»     о или О для выборочного (Булевы);                             

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

•     n/a, N/A или - (тире) для не' применимого;

•     с или С для условного требования. Для колонки поддержки:

•     Y, у или ДА для выполнимой;             

•     N, n или Нет для невыполнимой.

Кроме этого должно быть отражен факт того, что заявление о поддержке

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

Приведенные условные обозначения должны быть достаточными для

 

Таблица 4.1. Выполняемые классы

бланков большинства протоколов, а в тех случаях, когда требуются до­полнительные условные обозначения, их номер должен придерживать­ся абсолютного минимума и быть внесен в каталог ISO/IEC JTC1/SC21во избежание конфликтов с параллельными раз­работками. Для взаимоисключающих или выбо­рочных опций внутри набора может быть исполь­зовано дополнительное условное обозначение «о».

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

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

•     установлением в колонке статуса «с» с двоеточием и последую­щим одним или более обозначением статуса на отдельных лини­ях, каждая из которых содержит утверждение или отрицание, обозначенное оператором ( ˆ);

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

Таблица 4.5. Условные тре­бования во время использо­вания утверждений

Данные случаи иллюстрирует табл. 4.5, где пункт А является обязательным, если pi верен, и дополнительным, если pi неверен;

■   пункт В обязателен, если р2 верен, и по договору не применим, если р2 неверен.

Таблица 4.6. Ссылки на условные выражения статуса

Условные требования во время использования утверждений. В качестве примера в табл.4.6 при­ведены два варианта, в которых статус каждого пункта определен посредством ссылочного условного обозначения. При этом для выражения требований

может исполь­зоваться эквивалентный альтернативный синтаксис при гарантии, что он занесен в каталог ISO/lEC JTC1/SC21, а утверждение (Предикат) должно быть в виде:

• определенной отсылки в виде Да/Нет бланка PICS (в колонке под­держки), причем когда имеет место «Да», то утверждение True (Верно), в противном случае оно False (Неверно); например, «А.1.2.3/10а» является утверждением, которое ссылается на от­вет в первом пространстве на 10 строке таблицы, найденной в § А.1.2.3;

•     названия утверждения, которое где-либо еще в бланке PICS при­равнивается к одному из следующих:

■   определенная отсылка к вводу Да/Нет бланка PICS, например «pi», где pi определено равенством:

«р1=А.1.2.3/10а»

■   выражение взаимосвязи, включающее в себя ссылку к вводу бланка PICS в колонке Значений, например «р2», где р2 опре­делено равенством:

«p2=(v2>3)>, a v2 определено равенством:                                                    

«v2=A.1.2.3/l0b»,

которому необходимо решение, требующее интегрального от­вета;

■   выражение утверждения, т. е. Булево выражение, содержащее утверждения, например, «рЗ», где рЗ определяется равенством:

«p3=(pl AND NOT p2) OR (v3>2)»

где синтаксис и семантика должны соответствовать Булевым выражениям в TTCN.

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

Например, cl и с2, которые могут определяться следующим образом:

«cl: IF pi THEN m ELSE о»

«с2: IF (pi AND NOT p2) OR (v3 < 2) THEN m ELSE N/A»

Для условных выражений статуса может быть использован любой необ­ходимый синтаксис, но во избежание ненужного усложнения синтакси­са рекомендован синтаксис, внесенный в каталог ISO/IEC JTC1/SC21. Инструкции по завершению бланка PICS. Бланк PICS должен содер­жать дополнительный раздел, включающий:

•     объяснение потенциальному пользователю цели и структуры до­кумента;

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

•     предоставление точных инструкций для завершения PICS;

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

 

4.6.3. Процесс получения абстрактной тестовой последовательности

                                                                       

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

Следуя указанной цели, рекомендован следующий процесс получе­ния ATS:

• изучение соответствующих спецификации и бланков PICS для того, чтобы определить требования соответствия (включая опции), и объект тестирования;

•     определение необходимых тестовых наборов для достижения над­лежащего охвата требований соответствия;

•     раскрытие целей тестовых наборов — общих целей тестирования каждого тестового набора ;

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

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

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

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

включая структуру этапов теста и связь:

■   между процедурами тестирования,                                       

■   между процедурами тестирования и PICS,

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

•     анализ процедур поддержки ATS.

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

•     структурой тестовой последовательности и целями тестирования (TSS&TP);

•     спецификацией тестирования по выбору;

•     одной или более ATS для одного или более методов абстрактного тестирования;

•     спецификацией (если применима) протокола управления тести­рованием (ТМР).

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

 

4.6.3.1.                 Требования к соответствию и бланк PICS

 

Прежде чем начать разработку ATS, в первую очередь необходимо уста­новить, что означают требования к соответствию для того или иного про­токола и/или передачи спецификаций синтаксиса и что предписано в бланке PICS относительно внедрения этих спецификаций. При этом, если требования к соответствию по статике не определены надлежащим обра­зом, составитель ATS должен содействовать введению поправки к соот­ветствию или пересмотру действующей CCITT Рекомендации или Меж­дународного стандарта с тем, чтобы внести ясность в эти требования.

 

4.6.3.2.                 Структура тестовой последовательности и цели тестирования

 

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

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

 

4.6.3.3.                 Спецификация структуры тестовой последовательности

 

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

•     тестирование характеристик (для требований соответствия по статике);

•     тестирования процессов, которые действительны;             

•     тестирования процессов, которые исследуют реакцию IUT на не­действительные тестовые события, — это могут быть подразделения, связанные с синтаксически недействительными тестовыми событиями;

•     тесты, обращенные на PDU, которые отсылаются к IUT;

•     тесты, обращенные на PDU, которые получены от IUT;

•     тесты, обращенные на взаимодействия между полученными и отосланными PDU;

•     тесты, имеющие отношение к каждой обязательной характерис­тике;

•     тесты, имеющие отношение к каждой характеристике по выбору;

•     тесты, имеющие отношение к каждой фазе протокола;

•     колебания в этапах тестирования, происходящие в специфичес­ких состояниях;

•     колебания таймера и синхронизации;

•    колебания в кодировании PDU;

•     колебания в значениях отдельных параметров;

•     колебания в комбинациях значений параметров.

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

А Тестирование характеристик:

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

А.2 Характеристики по выбору

В Тестирование поведения (реакция на достоверное поведение равно­правным выполнением):                                                                       

В. 1 Фаза установления соединения (если соответствует)

В. 1.1 Фокусирование на посылке к IUT

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

В. 1.1.2 Отклонение таймера/нарушение синхронизации

В.1.1.3 Отклонение в кодировании

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

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

В. 1.2 Фокусирование на полученном от IUT

—  основа дана в В. 1.1

В. 1.3 Фокусирование на взаимосвязях

—  основа дана в В. 1.1                                                            

В.2 Фаза передачи информации                                                  

—  основа дана в В. 1                     

В.3 Фаза разъединения связи (если соответствует)

—  основа дана в В.1

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

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

С. 1.1 Фокусирование на посылке к IUT

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

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

С. 1.1.3 Отклонение в значениях отдельных недействитель­ных параметров

С. 1.1.4 Отклонение в комбинациях значений недействитель­ных параметров

С.1.2 Фокусирование на том, что должно быть выслано IUТ- ом

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

C. 1.2.2 Значения недействительных комбинаций параметров

С.2 Фаза передачи информации

—  основа дана в С.1

С.З Фаза разъединения связи (если соответствует)

—  основа дана в С.1

D Тестирования процесса: реакция на неподходящие события равно­правным выполнением)

D.1Фаза установления соединения (если соответствует)

D.1.1 Фокусирование на том, что отсылается к IUТ

D. 1.1.1 Отклонение тестового события в каждом из состояний

D.1.1.2 Нарушение синхронизации

D. 1.1.3 Отклонение специальных кодов

D.1.1.4 Отклонение значений большинства параметров

D.1.1.5 Отклонение большинства комбинаций значений па­раметров

D.1.2 Фокусирование на том, что должно быть выслано IUT  

— основа дана в D.1.1

D.2 Фаза передачи информации

—  основа дана в D.1

D.3 Фаза разъединения связи (если соответствует)                          

—  основа дана в D.I.

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

 

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

                        

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

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

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

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

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

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

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

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

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

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

Охват. Представим определение «достаточного» охвата, на рассмот­ренном выше примере структуры тестовой последовательности, где бук­ва «х» символизирует все подходящие значения для первого знака в идентификаторе тестовой группы, а «у» — для второго знака, так что В.х.у.1 обозначает В.1.1.1, В.1.2.1, В.1.3.1, В.2.1.1, В.2.2.1, В.2.3.1, В.3.1.1,В.3.2.1 иВ.3.3.1.

Следуя данной системе обозначений, минимальный «достаточный»

охват будет следующим:

•     для наборов тестирования характеристик (А.1, А.2):

■   хотя бы одна цель тестирования на соответствующую характе­ристику;

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

•     для тестовых наборов, связанных с колебаниями тестового события в каждом состоянии (В.х.у.1, С.х.1.1, D.x.y.l), хотя бы одна

цель тестирования на соответствующую комбинацию состояния/ события;                                                                         

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

•     для тестовых наборов, связанных с колебаниями кодирования (В.х.у.З, С.х.1.2, D.x.y.3), хотя бы одна цель тестирования для каждого соответствующего типа колебания кодирования на соот­ветствующий тип PDU;

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

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

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

■   для остальных соответствующих параметров хотя бы одна цель тестирования связана со значением, отличающимся от приня­того за «нормальное» или значение по умолчанию в других тестовых наборах;

Здесь тестирование отклонений действительных параметров должно сосредоточиваться на соответствующих требованиях в PICS.

•     для тестовых наборов, связанных с синтаксически или семанти­чески недействительными значениями индивидуальных парамет­ров (С.х.1.3, С.х.2.1):

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

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

           ■   для всех других соответствующих типов параметров — хотя бы одна цель тестирования на параметр.

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

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

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

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

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

Выполнение пункта TSS&TP. TSS&TP должен содержать пункт со­ответствия, минимальным требованием которого должно быть то, что общая ATS или ATS, соответствующая части TSS&TP:

•     состоит из наборов тестовых процедур, соответствующих набору или подмножеству целей тестирования, специфицированных в части TSS&TP;

•     использует структуру тестовой последовательности, которая яв­ляется необходимым подмножеством полной структуры тестовой последовательности, специфицированной в части TSS&TP;

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

•     использует одноименные соглашения для тестовых наборов и про­цедур тестирования;

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

 

4.6.3.5. Спецификация общих тестовых последовательностей

 

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

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

 

 

 

 

4.6.4. Методы абстрактного тестирования

Метод абстрактного тестирования (МАТ) определяет процедуры коорди­нирования и структуру тестирования, включая средства тестирования нижнего и верхнего уровней и их взаимодействие с системой тестирова­ния и SUT. Каждый МАТ устанавливает точки управления и наблюдения РСО и тестовые события (т. е. абстрактный примитив услуг (ASP) и PDU), которые должны быть использованы в процедуре абстрактного тестиро­вания данным методом. При этом каждая ATS должна специфициро­ваться в соответствии с одним из рассматриваемых далее МАТ.

Средства тестирования нижнего уровня. Для всех МАТ средство тестирования нижнего уровня взаимодействует с SUT посредством ос­новного сервисного провайдера, представляющего физическую среду передачи, соответствующую конкретному физическому уровню. Основ­ные характеристики МАТ, данные в этом разделе, относятся к IUT, в котором самый верхний уровень обозначен «Nt», а нижний — «Nb», причем для однопротокольного IUT Nt равен Nb.

Те же обозначения используются для уровней в пределах SUT, спо­собной приводить в исполнение протоколы по уровням, более низким, чем «Nb», что при описании методов тестирования не имеет особого значения. Однако и в этом случае SUT обязательно должна включать физический уровень. Для всех рассматриваемых далее методов тестиро­вания ATS определяет тестовые события относительно средства тести­рования нижнего уровня и контрольной точки (РСО) в значениях Nb-1 для ASP и/или с Nb no Nt для PDU.

Средства тестирования верхнего уровня. Основное отличие методов тестирования заключается в особенностях Nt и его согласованности со сред­ством тестирования нижнего уровня. Так, в некоторых методах для сред­ства тестирования верхнего уровня вводится еще одна контрольная точка, что требует определения формулировки тестовых событий в РСО в соответ­ствии с определениями в сервисе и протоколе спецификации OSI. В этом случае средства тестирования верхнего уровня не контролируют те пара­метры ASP, PDU или характеристики SUT или IUT, которые не являются частью OSI CCITT Рекомендации или Международного стандарта.

 

4.6.4.1. Основная спецификация МАТ для конечных систем IUT

 

Для IUT в пределах конечных систем SUT существует четыре категории МАТ — это локальный, распределенный, координированный и удален­ный методы тестирования

Локальный метод тестирования (L). В локальном методе тести­рования (рис. 4.9):

•     тестовые события в средствах тестирования нижнего уровня РСО определены только в понятиях Nb-1 для ASP и/или с Nb no Nt для PDU;

•     тестовые события в средствах тестирования верхнего уровня РСО определены в понятиях Nt для ASP;

•     граница обслуживания IUT, осуществляемая на верхнем уровне,

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

•     спецификация аппаратного интерфейса верхнего уровня IUT дол­жна устанавливать схематическое изображение связи между под­ходящими ASP и/или PDU и их реализацией в интерфейсе;

•     средство тестирования верхнего уровня находится в пределах те­стируемой системы;

•     требования к процедурам координации тестирования должны быть определены в ATS, но реализовываться локально, в пределах тес­тируемой системы.

Распределенный метод тестирования (D). В распределенном методе тестирования (рис. 4.10):

•     тестовые события в средстве тестирования нижнего уровня РСО определены только в понятиях Nb-1 для ASP и/или с Nb no Nt для PDU;

•     тестовые события в средстве тестирования верхнего уровня РСО определены в понятиях Nt для ASP;

•     границей обслуживания IUT на верхнем уровне должен быть или пользовательский интерфейс, или интерфейс стандартизованного языка программирования, которые можно использовать для целей тестирования, а тестовые последовательности не должны содер­жать каких-либо требований по использованию интерфейса в SUT в дополнение к уже изложенным в стандартизованной специфика­ции интерфейса языка программирования, если это имеет место;

•     должно быть схематическое изображение связи между подходя­щими ASP и их реализацией на верхнем уровне интерфейса IUT;

•     средство тестирования верхнего уровня находится в пределах SUT;

•     требования к процедурам координации тестирования должны быть определены в ATS в отличие от самих процедур;

•     если интерфейс IUT верхнего уровня является пользовательским интерфейсом, то требования TCP выполняет оператор SUT;

•     если интерфейс IUT верхнего уровня является стандартизован­ным интерфейсом языка программирования, то средство тестиро­вания верхнего уровня реализуется в программе, и средства тес­тирования верхнего и нижнего уровней выполняют требования процедур координирования тестирования (TCP).

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

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

Координированный метод тестирования (С). В координированном методе тестирования (рис. 4.11):

•     тестовые события в средстве тестирования нижнего уровня РСО  определены в понятиях Nb-1 для ASP, и/или с Nb no Nt для PDU

плюс TM-PDU;

•     Nt для ASP не использованы в спецификации ATS; нет предположе­ний о существовании границы обслуживания IUT верхнего уровня;

•     средство тестирования верхнего уровня расположено в пределах SUT;

•     требования к процедурам координации тестирования должны быть определены в ATS посредством сообщения стандартизованного

протокола управления тестированием (ТМР);

•     средство тестирования верхнего уровня должно выполнять ТМР и добиваться необходимых результатов по IUT;

•     процедуры тестирования должны дополнять ATS для цели тес­тирования соответствия требований спецификации ТМР; подоб­ные процедуры тестирования не делают вклада в оценку соот­ветствия ШТ.

В координированном методе тестирования стандартизованный ТМР мо­жет подходить только для одного стандартизованного ATS, а что каса­ется ТМР, то:

•     ТМР должен применяться в пределах SUT непосредственно над границей обслуживания абстрактного метода в верхней части IUT;

• к IUT не должно применяться требование интерпретировать ТМ- PDU — достаточно, что в процессе IUT будет передавать и получать их от средства тестирования верхнего уровня;

 

•     ТМР определен только для тестирования отдельного протокола и не должен быть независим от основного протокола;

•     заключения по процедурам тестирования не должны быть осно­ваны на возможности SUT демонстрировать какие-либо ASP или параметр ASP на верхней границе обслуживания ШТ, поскольку это приведет к противоречию в формулировке координированно­го метода тестирования: граница обслуживания верхнего уровня ШТ не РСО в данном методе тестирования. Несмотря на это реко­мендуется определять ТМР отдельно от ATS для того, чтобы об­легчить задачу конструктора средства тестирования верхнего уров­ня. Формулировка ТМР (так же, как и определение любого OSI протокола ISO) может ссылаться на ASP его основного обслужи­вания (т. е. ASP верхней границы обслуживания ШТ).

Метод удаленного тестирования (R). Метод удаленного тестирова­ния (рис. 4.12) используется в тех случаях, когда наблюдение и конт­роль за обслуживанием границы ШТ верхнего уровня невозможны. При таком тестировании:

•     тестовые события средства тестирования нижнего уровня РСО определены только в понятиях Nb-1 для ASP, и/или с Nb no Nt для PDU;

•     Nt для ASP не используются в спецификации ATS, так как не предполагается существование границы обслуживания IUТ верх­него уровня;

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

•     в процедурах координации тестирования или же контроля и/или наблюдения за ШТ для достижения каких-либо результатов SUT должен абстрактно выполнять некоторые функции средства тес­тирования верхнего уровня, поэтому последние допускаются или неформально выражаются в ATS для данного протокола, однако эти функции не специфицируются и их выполнение или реализа­ция не предполагается;                                       

• средство тестирования нижнего уровня должно пытаться достичь предполагаемых или же неформально выраженных процедур коор­динации тестирования в соответствии с информацией в бланке PIXIT. Кроме этого, чтобы компенсировать отсутствие спецификации процессов IUT, при необходимости, требуемый процесс SUT должен быть определен в понятиях Nb-1 для ASP или с Nb no Nt для PDU, за которым необходимо наблюдать с помощью средства тестирования нижнего уровня. Данная форма неявного определения должна пониматься как «делайте то, что необходимо в пределах SUT для того, чтобы вызвать необходимый про­цесс». Тем не менее возможно, что некоторые процедуры тестирования в ATS могут быть и невыполнимы (например, передача последовательных, оставшихся без ответа PDU данных, и т. д.). Однако даже при таком неявном определении контроля IUT он, в отличие от наблюдения по IUT, может быть определен (специфицирован). Это является основным отли­чием между данным и рассматриваемыми далее методами тестирования.

 

4.6.4.2. Одноуровневость и вложенность

 

Рассмотренные методы предназначены для тестирования однопротокольных IUT (аббревиатура S), в то время как для тестирования многопрото­кольных IUT (одновременного тестирования протоколов) может быть ис­пользован вариант вложения этих методов тестирования (аббревиатура Е).

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

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

и, например, если DS — это аббревиатура для «Распределенного Одно­уровневого» метода тестирования, то DSE будет аббревиатурой «Распре­деленного Одноуровневого Вложенного» метода тестирования.

 

4.6.4.       Однопротокольные IUT

                                              

В последующих описаниях одноуровневых методов тестирования одно-протокольных IUT абстрактная модель IUT называется N-объектом те­стирования.

Метод тестирования LS. В Локальном Одноуровневом (LS) методе тестирования (рис. 4.13) тестовые события определены в понятиях (N)-ASP аппаратного интерфейса верхнего уровня (Ы)-объекта тестирования и (N-l)-ASP и/или (N)-PDU в РСО средства тестирования верхнего уровня.

Метод тестирования DS. В Распределенном Одноуровневом (DS) методе тестирования (рис. 4.14) тестовые события определены в поня­тиях (N)-ASP интерфейса верхнего уровня (NJ-объекта тестирования и (N-l)-ASP и/или (N)-PDU в РСО средства тестирования нижнего уровня.

Особенность данного метода в отличие от LS метода заключается в том, что интерфейс верхнего уровня (М)-объекта тестирования не явля­ется аппаратным интерфейсом.

Метод тестирования CS. В координированном одноуровневом {CS) методе тестирования (рис. 4.15) события определены в понятиях (N-1)-ASP и/или (N)-PDU плюс TM-PDU в РСО средствах тестирования ниж­него уровня.

Метод тестирования RS. В удаленном одноуровневом (RS) методе тестирования (рис. 4.16) тестовые события определены в понятиях (N-1)-ASP и/или (N)-PDU в РСО средствах тестирования нижнего уровня.

4.6.6. Многопротокольные IUT

 

В одноуровневых вложенных методах процесс тестирования определен для однопротокольного IUT в рамках соответствующего многопротоколь­ного IUT, включая параметры действия протокола тестируемого IUT, но не определяя характеристик тестирования в границах обслуживания многопротокольного IUT. Так, в многопротокольном IUT с протокола Nb no Nt абстрактные тестовые процедуры для протокола тестирования N должны включать спецификацию PDU в протоколах R+l no Nt, так же, как и в протоколе N..

Данное описание вложенных методов тестирования предполагает, что протоколы IUT расположены в порядке непрерывного смежного взаи­модействия пользователь/провайдер. Поэтому использование варианта одноуровневого вложенного метода тестирования (с уровня Nb no N) называется возрастающим (инкрементным) тестированием многопрото­кольного IUT.

Варианты вложенного метода тестирования определяются для оди­нарного тестируемого протокола в многопротокольном IUT, при этом границы обслуживания многопротокольного IUT оказываются доступ­ными, но при тестировании не используются. Таким образом, все про­токолы, начиная с тестируемого протокола и заканчивая протоколом самого высокого уровня, для которых PDU представлены в форме тес­товых событий в ATS, должны рассматриваться в качестве части много­протокольного IUT.

Для верхнего уровня Nt многопротокольного IUT эти варианты соот­ветствуют нормальным однослойным методам тестирования.

Метод тестирования LSE. В локальном одноуровневом вложенном (LSE) методе тестирования про­токола Nj в многопротокольном IUT с Nb no Nt (рис. 4.17) тестовые собы­тия должны быть определены в по­нятиях Nt - ASP в IUT и Ni-1 - ASP и с Ni по Nt-PDU в пределах Ni-1 — сервисного провайдера в тестовой системе.

Метод тестирования DSE. В распределенном одноуровневом вло­женном (DSE) методе тестирования (рис. 4.18) для протокола Ni в пре­делах многопротокольного IUT с Nb по Nt тестовые события должны быть определены в понятиях Nt-ASP над IUT и Ni-l -ASP, а также с Ni по Nt -PDU над Ni-1-еервисным провайдером в тестируемой системе.

Метод тестирования CSE. Координированный одноуровневый вло­женный (CSE) метод тестирования (рис. 4.19) использует признаки как CS, так и DSE методов тестирования. Поэтому тестовые события должны определяться в понятиях Ni-1-ASP, с Ni по Nt-PDU, а также ТМ-PDU. ТМР должен быть составлен, чтобы действовать через Nt-Cepвиc.

Метод тестирования RSE. Метод удаленного одноуровневого вло­женного тестирования (RSE) использует те же РСО (рис. 4.20), что и метод тестирования RS для того же уровня, но отличается от метода тестирования RS, в котором с Ni+l no Nt-PDU определяются в процеду­рах тестирования для уровня Ni.

 

4.6.7. МАТ для открытых ретрансляционных систем

 

Для тестирования по шлейфу ретрансляционных систем и систем меж­сетевой связи применяются специальные МАТ, которым присваивают­ся аббревиатуры YL и YT, соответственно.

Метод тестирования YL. Метод тестирования YL (рис. 4.21) ори­ентирован на тестирование ретрансляционных систем одной подсети, используя для этой цели две контрольные точки SAP, находящиеся за пределами Nt -передатчиков. Для тестирования протоколов передачи с установлением соединения необходимо, чтобы соединения объединялись на дальней стороне Nt -передатчика, хотя рекомендаций по вопросу, про­изводится ли данное объединение в пределах Nt -передатчика или же во второй подсети, нет. Для протоколов, ориентированных на процессы без установления соединения, необходимо, чтобы PDU возвращались к началу цикла в пределах второй подсети и переадресовывались ко вто­рым РСО.

Данный метод позволяет тестировать открытую систему передачи без запроса на тестирование систем в двух разных подсетях, поэтому про­цедуры координации контроля, применяемые в 2-х РСО, могут быть реализованы в одной тестируемой системе. В то же время при таком

 

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

Метод тестирования YT. Метод YT предназначен для тестирова­ния системы передачи из двух подсетей и иллюстрируется (рис. 4.22). В данном методе в SAP, находящихся за пределами Nt -передатчика, ис­пользуются всего 2 РСО — по одной на каждой подсети, что позволяет тестировать открытую систему передачи в ее нормальном операцион­ном режиме путем контроля каждой подсети.

4.7.             ВЫБОР МЕТОДА АБСТРАКТНОГО ТЕСТИРОВАНИЯ

 

Перед определением МАТ необходимо проанализировать внешние усло­вия, при которых должно быть выполнено тестирование протокола, а затем установить количество ATS.

 

4.7.1. Комплексное обеспечение тестирования

 

В ATS соответствующего тестирования должны быть определены требо­вания, определяющие, какое минимальное количество МАТ будет под­держиваться при тестировании протокола. Поэтому всестороннее обес­печение тестирования должно включать хотя бы один метод, который не выдвигает никаких дополнительных требований по SUT, кроме тре­бований, содержащихся в OSI CCITT Рекомендации или Международ­ном стандарте, которым SUT обязана соответствовать.

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

Если стандартизованная ATS проведена, не удовлетворяя вышеука­занным требованиям для обеспечения полного обслуживания тестиро­вания, она должна содержать следующее предписание в разделе облас­ти действия: «Данная абстрактная тестовая последовательность сама по себе недостаточна для полного обеспечения тестирования протокола».

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

 

4.7.1.1. Исходные данные IUT

                                                                                    

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

•     принадлежат ли они конечным или ретрансляционным системам;

•     принадлежат ли они полным или частичным системам;

•     принадлежат ли они полностью открытым или смешанным сис­темам;

•     имеют ли они доступные границы обслуживания или нет;

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

 

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

 

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

 

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

 

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

Эти правила приводят к усовершенствованию процедур координации тестирования с целью достижения синхронности между средствами те­стирования верхнего и нижнего уровней и управления обменом инфор­мацией в процессе тестирования. При этом детали синхронизации и способы достижения требуемых целей определяются как характеристи­ками SUT, так и методами тестирования.

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

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

 

4.7.2. Спецификация ATS

 

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

•     наименования ATS, дата создания и номер версии;

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

•     названия (и номера вариантов) CCITT Рекомендации(й) или Международного(ых) стандарта(ов), определяющие обслуживание OSI, ASP которых определены и в процедурах тестирования за ними осуществлялся контроль и/или проводилось наблюдение;

•     наименование (и номера вариантов) CCITT Рекомендации или Международного стандарта, определяющее систему обозначений теста;

•     наименование целевого метода тестирования;

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

•     описание структуры тестовой последовательности в показателях тестовых наборов и их взаимоотношения со спецификацией про­токола;

•     описание процедур координации тестирования или же связь со спецификацией ТМР (если это применимо к данному методу тес­тирования);

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

•     информация для поддержки оператора, выполняющего тестиро­вание и лаборатории тестирования в процессе использования ими стандартизованной ATS;

•     идентификация Технической Ошибки (или CCITT эквивалента), которые относятся к CCITT Рекомендации или Международному стандарту, специфицирующему протокол или передачу синтакси­са, и которые были учтены в ATS.

 

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

 

Очевидно, что при разработке ATS должна применяться стандартизованная система обозначений, например, TTCN. После того как выбрана сис­тема обозначений и определен метод тестирования, можно специфициро­вать процедуры абстрактного тестирования, каждая из которых должна:

•     отображать в соответствии с составителем цели тестирования одну цель или совокупность целей или отображать одну специфика­цию тестирования при ее наличии;

•     специфицировать все последовательности тестовых событий, ко­торые включают в себя основную часть тестирования;

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

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

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

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

Если цель тестирования не может быть достигнута из-за специфичес­кой природы выбранного МАТ, то данное ограничение также должно быть задокументировано в стандартизованной ATS. Так, для каждой специфицированной цели тестирования стандартизованная ATS долж­на либо определять процедуру абстрактного тестирования для достиже­ния данной цели тестирования, либо документировать причину, по ко­торой данная процедура тестирования не включена.

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

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

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

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

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

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

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

Следует отметить, что при составлении спецификации тестовой пос­ледовательности должна обеспечиваться гарантия того, что каждая про­цедура абстрактного тестирования точно определяет:

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

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

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

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

 

4.7.2.2. Соответствие ATS

 

Стандартизованная ATS должна включать пункт соответствия и безоши­бочно представлять протокол(ы), соответствие которого она предназначе­на тестировать. При обнаружении ошибок или неясностей в специфика­ции протокола во время разработки ATS они должны быть пересланы соответствующей группе отчета о неисправностях CCITT или ISO/IEC, которая определяет проблемы, и если обнаружены различия между ATS и спецификацией протокола после стандартизации ATS, то специфика­ция протокола должна содержать предшествующий этап в решении про­блемы. При этом FDT могут способствовать действительности тестовой последовательности по отношению к спецификации протокола.

 

4.7.2.3. Спецификация ТМР

 

В случае координированного метода тестирования (CS и CSE) процеду­ры координации реализуются посредством стандартизации ТМР, в виде самостоятельной части стандарта тестирования соответствия. ТМР дол­жен иметь возможность передачи требований IUT для достижения ре­зультата действия примитива услуги, а также обратной передачи сред­ству тестирования нижнего уровня записи наблюдений за этими результатами. При этом управление средством тестирования верхнего уровня также должно осуществляться в соответствии с ТМР.

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

В случае разработки части ТМР стандарта тестирования соответствия, для выполнения его предписаний, должен предоставляться бланк, вклю­чающий соответствующий заголовок для каждого из TM-PDU.

 

4.7.2.4. Использование спецификации ATS

 

В стандартизованной ATS обязательно должна предоставляться инфор­мация для поддержки тестирования с целью ее правильного использова­ния. Эта информация не ограничена, но должна включать следующее: •     схематическое изображение процедур абстрактного тестирования во вводных частях бланков PICS для того, чтобы определить, нужно ли выбирать каждую процедуру абстрактного тестирования для отдельных IUT, при этом схематическое изображение должно быть специфицировано в виде, подходящем для Булевых обозначений;

•     спецификацию частичного бланка PIXIT для каждой ATS, кото­рый должен содержать список всех параметров, нуждающихся в установлении их значений, а если какие-либо из требуемых зна­чений параметров находятся в PICS, то ввод в бланк PIXIT для каждого из таких параметров должен ссылаться на соответствую­щий ввод в бланке PICS;

•     схематическое изображение в Булевом выражении процедур аб­страктного тестирования в частичном бланке PIXIT для введения параметров тестовой последовательности отдельного ШТ и иден­тификации требований к тестированию, которые могут предотв­ратить запуск процедур тестирования, противоречащих ШТ;

•     порядок, в котором процедуры абстрактного тестирования долж­ны быть перечислены в PCTR;

•     какие-либо ограничения порядка, в котором могут осуществлять­ся процедуры тестирования;                                                        

•     установление процедур тестирования и тестовых наборов, кото­рые должны быть реализованы в МОТ и должны соответствовать стандартизованной ATS;                                                              

•     требования к процедурам координации тестирования или ссылка на спецификацию ТМР (если это применимо к выбранному мето­ду тестирования);

•     какая-либо необходимая информация по синхронизации и вре­менным параметрам.

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

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

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

 

4.7.2.5. Поддержка ATS

 

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

 

4.8.             ВИДЫ ТЕСТИРОВАНИЯ ОТКРЫТЫХ СИСТЕМ

 

Обобщая вышеизложенное, можно отметить, что для подтверждения соответствия представленного на тестирование объекта регламентируе­мым тем или иным стандартом спецификациям проводится три вида тестирования, которые можно разделить на:

•     тестирование соответствия спецификациям;                          

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

•     тестирование соответствия по взаимодействию,

которые для телекоммуникационного оборудования осуществляются с учетом определенного уровня модели OSI или протокола.

 

4.8.1. Тестирование на соответствие спецификациям

 

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

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

тестируемого IUT и после их изучения производит выбор для выполнения нескольких тестов. За­тем осуществляется собственно тестирование с анализом результатов и подготовкой окончательного отчета о тестировании.  

                     

4.8.2. Тестирование функционального соответствия

              

Тестирование функционального соответствия включает установление тех или иных парамеров, например, качества услуг (Quality of Service — QoS) или сетевых характеристик (Network Performance — NP), которые определяются, например, в случае ATM трафиком при заданных или известных условиях (нагрузки и профайла). Данный тип тестирования подразделяется на две категории тестов:

•     измерение параметров QoS или NP с тем, чтобы они не превыша­ли определенных уровней при условии «нормальной нагрузки», которое заключается в том, чтобы для ATM уровня нагрузка яче­ек трафика соответствовала допустимой, а для SVC соединений трафик был бы меньше заданного;

•     тестирование перегрузки с тем, что бы установить, как действует механизм защиты SUT от перегрузки.

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

Здесь генератор формирует различные последовательности трафика Рис. 4.25. Обобщенная схема тестирования функционального соответствия     

                                                                                                        

(трафик, состоящий из ячеек для тестирования PVC или вызовы для тестирования SVC соединений), а анализатор определяет такие пара­метры функционирования, как количество ячеек с ошибками, вариа­ции задержки ячеек и т. д.

 

4.8.3. Тестирование соответствия по взаимодействию

                 

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

•     реализованы все обязательные функции и характеристики;

•     ни одна или некоторые из дополнительных характеристик/функ­ций не реализованы;

•     реализованы другие неопределенные характеристики/функции.

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

•     две SUT реализуют одинаковые обязательные характеристики/фун­кции, но отличаются с позиций дополнительных или неопределен­ных функций. В этом случае возможность их совместимости зави­сит от дополнительных и/или неопределенных характеристик.

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

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

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

типа.

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

•     тестирование на соответствие по статике, достигаемое через PICS и/или PIXIT, гарантируя, что различные IUТ основаны на стан­дартных спецификациях. Это увеличит вероятность того, что они также будут сочетаться с другими реализациями. Тестирование на взаимодействие не заменяет тестирования на соответствие по динамике;

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

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

Так как тестирование взаимодействия не устанавливает соответствие реализации требуемому стандарту, тем не менее две реализации могут взаимодействовать друг с другом будучи «нестандартными». Поэтому данный вид тестирования не затрагивает определенные в стандарте обя­зательные характеристики реализации тестируемого IUТ — это задача тестирования соответствия.

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

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

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

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

4.8.4. Сертификационное тестирование

 

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

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

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

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

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

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

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

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

•     поддержка основных сетевых сервисов: Telnet, FTP, HTTP/SHTTP, SMTP, POP3, DNS и др.;

•     контроль целостности объекта и системы;

•     возможность удаленного администрирования и мониторинга;

•     развитые средства мониторинга;

•     возможность фильтрации на соответствующих уровнях (в терми­нах модели ISO OSI) по следующим признакам: сетевые адреса отправителя и получателя, номера сервисов, текущее время и др.;

•     гибкость в задании правил фильтрации;

•     возможность выделения/сокрытия внутренних объектов и топо­логии сети;

•     жесткое разграничение пользователей;

•     интуитивно-понятный интерфейс управления;

•     надежный механизм протоколирования.

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

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

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

Очевидно, что более эффективной является классификация ошибок, выполненная с учетом особенностей тестируемых систем и методов тес­тирования.

 

4.8.5. Модель процесса сертификационного тестирования

 

В соответствии с «Методологией и архитектурой тестирования Взаимо­действия Открытых Систем на соответствие стандартам» реальная тестируемая открытая система представляется в терминах модели ISO OSI как набор компонентов одного или нескольких абстрактных уров­ней взаимодействия — от канального до прикладного — и имеет как точки предоставления сервиса для вышележащих уровней (или пользо­вателя), так и точки использования сервиса, предоставляемого нижеле­жащим уровнем. Наличие этих точек позволяет проводить тестирова­ние на соответствие стандартам внешнего поведения открытой системы или, что то же, тестирования взаимодействия открытых систем.

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

Согласно рассмотренным выше архитектурам тестирования в этом случае система представляется в терминах модели ISO OSI как набор уровней взаимодействия с подключением средств тестирования одно­временно к точкам предоставления сервиса вышележащего уровня и ко всем точкам (обычно на физическом уровне), через которые система пользуется услугами нижележащего (обычно физического) уровня. В процессе тестирования оператор тестирования моделирует состояния внешней и внутренней сети, взаимодействуя с SUT посредством стан­дартных протоколов на соответствующих уровнях, создавая все возмож­ные ситуации и используя все доступные возможности протоколов вза­имодействия. Кроме этого, в ходе такого тестирования (рис. 4.28) через соответствующие интерфейсы SUT осуществляется изменение и ее кон­фигурации, что позволяет контролировать внешнее поведение, сравни­вая его с описанным в стандартах.

Согласно приведенной архитектуре тестирования открытой системы модель процесса сертификационного тестирования включает оператора

тестирования (чело­века, проводящего сертификационное те­стирование), средство тестирования (про­граммно-аппаратный комплекс, предназна­ченный для проведе­ния тестирования) и собственно тестируемый объект (рис. 4.29).

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

 

ВЫВОДЫ

                      

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

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