Рисунок 1 ? Фазы процесса изготовления изделия

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

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

Примерами возможностей протоколов является:

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

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

использование определенной последовательности передаваемых сообщений.

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

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

В RFC 972 описан принцип нумерации в сегментах TCP передаваемых октетов данных. Увеличение поля Sequence Number при передаче каждого пакета на величину переданного в предыдущем пакете сегмента данных можно трактовать как описанную возможность протокола TCP. Данная возможность может отсутствовать в тестируемом объекте, либо значение поля Sequence Number может изменяться на величину, отличную от размера переданного сегмента данных.

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

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

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

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

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

Рисунок 2 ? Множество возможностей протокола, проверяемых при аттестационном тестировании

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

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

Будем считать, что изделие полностью соответствует исходному полному описанию протокола, составленному разработчиком. Моменты несоответствия исходного полного описания протокола стандарту, используемому как эталон при тестировании, будем называть ошибками постановки задачи (Рис. 3). Основными причинами могут быть:

наличие нескольких стандартов на один протокол;

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

Рисунок 3 ? Ошибки, выявляемые аттестационным тестированием

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

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

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

Стандарты на современные протоколы передачи данных являются объемными и сложными для восприятия документами. Это связано с рядом причин:

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

указанием нескольких вариантов реализации различных возможностей, а так же большого числа факультативных возможностей;

желанием получить более гибкий и общий стандарт.

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

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

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

Литература