ГОСТ Р ИСО/МЭК ТО 10183-1-2000
Группа П85
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
Текстовые и учрежденческие системы
АРХИТЕКТУРА УЧРЕЖДЕНЧЕСКИХ ДОКУМЕНТОВ (ODA) И ФОРМАТ ОБМЕНА.
ТЕХНИЧЕСКИЙ ОТЧЕТ О ТЕСТИРОВАНИИ РЕАЛИЗАЦИИ ПРОТОКОЛА ИСО 8613
Часть 1
Методология тестирования
Information technology. Text and office systems. Office Document Architecture (ODA)
and interchange format. Technical Report on ISO 8613 implementation testing.
Part 1. Testing methodology
ОКС 35.240.20
ОКСТУ 4002
Дата введения 2001-01-01
Предисловие
1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного комитета Российской Федерации по связи и информатизации
ВНЕСЕН Техническим комитетом по стандартизации "Информационные технологии" (ТК 22)
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 6 апреля 2000 г. N 93-ст
3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК ТО 10183-1-93 "Информационная технология. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Технический отчет о тестировании реализации протокола ИСО 8613. Часть 1. Методология тестирования"
4 ВВЕДЕН ВПЕРВЫЕ
1 Назначение
1 Назначение
Настоящий стандарт устанавливает методологию тестирования и создает основу для спецификации абстрактных тестовых примеров при тестировании реализаций протокола по ИСО 8613. Общая цель настоящего стандарта состоит в том, чтобы создать соответствующую основу для тестирования возможностей к взаимодействию реализаций архитектуры учрежденческих документов (ODA).
Такое тестирование должно содействовать анализу способности реализации к взаимодействию в функциональной среде реализаций протокола ИСО 8613 и реализаций функциональных стандартов (ФС), основанных на ИСО 8613. Функциональные стандарты представляют собой стандартизованные прикладные профили по документам, гармонизованные в международном масштабе. И как таковые они представляют собой согласованные стабильные подмножества протокола ИСО 8613, предназначенные для обеспечения взаимодействия систем ODA на различных уровнях функциональных возможностей.
В ИСО 8613 термин "соответствие" означает соответствие потока данных правилам, определенным в ИСО 8613. Сюда относится соответствие потока данных прикладному профилю документа на основе ИСО 8613. Методология аттестационного тестирования, определенная в приложении G ИСО 8613-1, охватывает анализ потоков данных безотносительно возможностей реализации генерировать или принимать соответствующие потоки данных. Для создания функциональной среды взаимодействующих систем ODA необходимо иметь методологию тестирования, которая могла бы проверять правильность обеспечиваемых возможностей реализации с точки зрения ИСО 8613 и прикладных профилей документа (ППД) на семантическом уровне, а также с точки зрения потока данных или синтаксического уровня.
Следовательно, тестирование реализации является вспомогательным тестированием, которое дополняет аттестационное тестирование потоков данных. Оно повышает вероятность того, что различные реализации протокола ИСО 8613 и ФС будут способны к взаимодействию. Тестирование реализаций основано на концепции измерения способности реализации генерировать и (или) принимать представительный набор документов. Если реализация способна обеспечить такие возможности, повышается вероятность ее успешного взаимодействия с другими аттестованными реализациями при обмене документов самых различных видов.
Методология тестирования реализации устанавливает требования к абстрактным тестовым примерам, а также к процедурам при их использовании для тестирования возможностей реализации выполнять операции генерации и приема.
При установлении основ аттестационного тестирования была разработана концептуальная модель систем ODA с целью описать в абстрактном смысле множество различных конфигураций и ограничений реальных систем ODA.
Содержащаяся в настоящем стандарте методология охватывает тестирование реализации функциональных стандартов, основываясь на положениях ИСО 8613. Эта методология может быть использована также для тестирования других прикладных профилей документов на основе ИСО 8613.
Настоящий стандарт:
- определяет термины, используемые в контексте тестирования реализации;
- представляет концептуальную модель реализации ODA;
- обеспечивает поэтапный подход к тестированию реализаций;
- определяет функциональные компоненты при тестировании функций генерации и приема;
- определяет требования к абстрактным тестовым примерам.
Настоящий стандарт не распространяется на тестирование интерфейсов пользователя в системах, основанных на ODA. Любой подходящий системный интерфейс используется только как пункт контроля и наблюдения, предназначенный для проверки того, что преобразования документов ODA, относящиеся к различным процессам ODA, выполняются в соответствии с заявкой разработчика.
В уместных случаях в настоящем стандарте использованы понятия и термины, описанные в ГОСТ Р ИСО/МЭК 9646-1. В некоторых случаях были приняты понятия и термины, отражающие то, что ODA не является протоколом ВОС.
2 Нормативные ссылки
ГОСТ Р ИСО/МЭК 9646-1-93 Информационная технология. Взаимосвязь открытых систем. Основы и методология аттестационного тестирования. Часть 1. Общие положения
ИСО 8613-1-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 1. Введение и общие принципы
ИСО 8613-2-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 2. Структуры документа
ИСО 8613-4-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 4. Профиль документа
ИСО 8613-5-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 5. Формат обмена учрежденческих документов
ИСО 8613-6-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 6. Архитектуры позначного содержимого
ИСО 8613-7-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 7. Архитектуры содержимого растровой графики
ИСО 8613-8-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 8. Архитектуры содержимого геометрической графики
ИСО/МЭК ПМС 8613-9* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 9. Архитектура звукового содержимого
ИСО/МЭК 8613-10-91* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 10. Спецификации формата
ИСО/МЭК МФС 11181-1-93* Информационная технология. Функциональный стандарт. Профиль FOD26. Формат учрежденческого документа. Структура расширенного документа. Архитектуры позначного содержимого, содержимого растровой графики и геометрической графики. Часть 1. Прикладной профиль документа
ИСО/МЭК 10183-2-93* Информационная технология. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Методология тестирования и абстрактные тестовые примеры. Методология тестирования реализации. Часть 2. Абстрактные тестовые комплекты
_________________
* Оригиналы стандартов и проектов ИСО, ИСО/МЭК - во ВНИИКИ Госстандарта России.
3 Определения
Для целей настоящего стандарта применимы определения, приведенные в ИСО 8613-1, а также следующие определения.
Примечание 1 - Были использованы также некоторые термины ГОСТ Р ИСО/МЭК 9646-1, имеющие эквивалентный смысл.
3.1 Документ ODA - совокупность информации, структурированная в соответствии с абстрактной архитектурной моделью, определенной в ИСО 8613.
3.2 Поток данных ODA - поток данных ODIF или ODL, в котором элементы данных, образующие составные части и значения атрибутов, представлены в соответствии с разделом 8 ИСО 8613-1 и с любым другим стандартом, на который дана ссылка.
Примечание 2 - Это определение требует, например, чтобы все составляющие указатели были обеспечены либо в потоке данных, либо некоторым внешним указателем.
3.3 Кодирование - преобразование представления документа ODA в локальной системе в его представление в потоке данных.
3.4 Инициация (генерация) документа - создание потока данных ODA для обмена.
3.5 Процесс обмена ODA - инициация документа ODA и его передача средствами передачи данных либо его обмен с запоминающей средой и прием.
3.6 Прием документа - прием потока данных, представляющего документ ODA.
3.7 Декодирование - преобразование документа ODA из представления в потоке данных в его представление в локальной системе.
3.8 Поток данных ППД-L - поток данных ODA, в котором элементы данных находятся в соответствии с положениями раздела 7 конкретного ППД уровня "L", определенного в соответствии с ИСО 8613-1.
3.9 Тестируемая реализация (ТР) - реализация ИСО 8613, составляющая часть реальной открытой системы, которая анализируется процессом тестирования.
3.10 Реализация ODA - реализация, способная вырабатывать представительный набор потоков данных и (или) прием и последующую обработку представительного набора потоков данных ODA.
Примечание 3 - Обеспечение процессов генерации, приема и (или) дальнейшей обработки ODA зависит от характеристик реализации (например, от преобразователя, редактора, принтера и т.п.).
3.11 Реализация ФС - реализация ODA, которая может генерировать представительный набор потоков данных ППД-L ФС и (или) принимать и, возможно, осуществлять дальнейшую обработку представительного набора потоков данных ППД-L ФС.
Примечание 4 - Обеспечение процессов генерации, приема и (или) дальнейшей обработки ODA ППД-L зависит от характеристик реализации (например, от преобразователя, редактора, принтера и т.п.), как определено в ЗОГ/ЗОП (см. 3.22).
3.12 Редактирование - преобразование из представления обрабатываемой формы документа ODA в локальной системе в представление пересмотренной версии этой обрабатываемой формы документа ODA в локальной системе. Это преобразование происходит в соответствии с редактирующей частью процесса модели обработки документа ODA.
Примечание 5 - Редактирование включает в себя преобразование нулевого документа в обрабатываемый документ. Редактирование - это частный случай преобразования типа модификации (см. 3.13).
3.13 Модификация - преобразование из представления документа ODA в локальной системе в представление пересмотренной версии этого документа ODA в локальной системе.
Примечание 6 - Модификация - это преобразование, связанное с любыми изменениями структур документа, его составляющих, атрибутов и его контекста в представлении документа ODA в локальной системе. Примером модификации служит преобразование, происходящее в результате удаления конкретной упорядоченной структуры сформатированно-обрабатываемой формы документа с целью создать версию обрабатываемой формы этого документа ODA. Модификация включает в себя (но не ограничивается этим) преобразование в виде редактирования (см. 3.12).
3.14 Упорядочение - преобразование представления обрабатываемой формы документа ODA в локальной системе в представление сформатированной формы документа ODA в локальной системе. Это преобразование выполняется в соответствии с упорядочивающей частью процесса модели обработки документа ODA.
3.15 Отображение - преобразование из представления в локальной системе сформатированного или сформатированно-обрабатываемого документа ODA в визуально воспринимаемое представление этого документа ODA. Это преобразование выполняется в соответствии с частью "обработка отображения" модели обработки документа ODA.
Примечание 7 - Отображение - это частный случай преобразования типа визуализация (см. 3.16).
3.16 Визуализация - преобразование представления документа ODA в локальной системе в визуально воспринимаемое представление этого документа ODA.
Примечание 8 - Обеспечение реализацией преобразования типа визуализация зависит от физической среды представления (например, бумага, экран и т.п.), а также от применения (например, вывод на печать, сканирование файлов, архивное хранение и т.п.). Визуализация включает в себя (но не ограничивается этим) преобразование типа отображение (см. 3.15).
3.17 Представление в локальной системе - часть тестируемой системы, представляющая собой документ ODA обычно в системно-зависимом формате.
3.18 Реализация, основанная на ODA/ФС, - реализация ODA или ФС ODA (см. 3.10, 3.11).
3.19 Тестирование реализации ODA/ФС - тестирование возможности ТР обеспечивать функциональные элементы ODA или ФС ODA.
3.20 Система, основанная на ODA/ФС, - реальная открытая система, в которой существует ODA или ФС ODA.
3.21 Форма заявки об обеспечении функций генерации и приема (форма ЗОГ/ЗОП) - часть ФС, в которой установлены подробные требования к обеспечению функций генерации, приема и дальнейшей обработки, а также факультативные возможности, относящиеся к реализации данного ППД ФС.
3.22 Заявка об обеспечении функций генерации и приема (ЗОГ/ЗОП) - заявка, в которой изложены подробные заявляемые сведения об обеспечении реализацией функций генерации, приема и последующей обработки относительно конкретного ППД ФС.
3.23 Взаимодействие ODA - способность реализации генерировать и (или) принимать и, возможно, осуществлять последующую обработку потоков данных ODA в соответствии с ЗОГ/ЗОП.
Примечание 9 - "Последующая обработка" включает в себя одно или несколько преобразований, определенных в 3.12-3.16, таких как редактирование, модификация, упорядочение, отображение и визуализация.
3.24 Пункт контроля и наблюдения - пункт в функциональной среде тестирования, в котором тестовым примером определены контроль и наблюдение.
3.25 Тестируемая система (ТС) - реальная открытая система, в которой находится тестируемая реализация.
3.26 Цель тестового примера - описание на естественном языке задач тестового примера, в котором основное внимание уделено одному функциональному элементу (например, проверка обеспечения конкретного значения атрибута ODA).
3.27 Абстрактный тестовый пример (АТП) - цель тестового примера в сочетании со спецификацией любого функционального элемента ODA (или ODA ФС), необходимого для достижения цели тестового примера и вынесения вердикта тестирования.
3.28 Выполнимый тестовый пример - реализация абстрактного тестового примера.
3.29 Документ тестирования ODA/ФС - аттестационный документ ODA или ODA/ФС, в котором содержится один или несколько тестовых примеров.
3.30 Абстрактный тестовый комплект - полный набор тестовых примеров, необходимых для тестирования обеспечиваемых реализацией функций, относящихся к ODA или ФС ODA.
4 Сокращения
ЗОГ - заявка об обеспечении функции генерации;
ЗОП - заявка об обеспечении функции приема;
Ко - компонент обмена;
Кп - компонент процесса;
Ки - компонент системного интерфейса;
ПКН - пунт контроля и наблюдения;
ПОДД - локальное представление обрабатываемой формы документа (ОДД) ODA;
ППД - прикладной профиль документа;
ПТД - потоки тестируемых данных (используются при тестировании функций приема);
ПФДД - локальное представление сформатированной формы документа (ФДД) ODA;
ПФОДД - локальное представление сформатированно-обрабатываемой формы документа (ФОДД) ODA;
СТП - спецификации тестовых примеров (используются при тестировании функций генерации);
ТД - тестируемый документ;
ТР - тестируемая реализация;
ФС - функциональный стандарт.
5 Общие принципы тестирования реализации
Цель стандарта ODA - облегчить обмен документами - не будет полностью достигнута, пока реализация не будет протестирована на способность ее правильного взаимодействия. Стандартные тестовые комплекты необходимы для использования поставщиками или разработчиками реализации при выполнении самотестирования, пользователями изделий ODA, а также любой тестирующей организацией и другими администрациями, заинтересованными в тестировании реализаций ODA.
Реализации ODA могут быть самых различных видов, начиная от шлюзов, которые принимают и генерируют потоки данных при очень небольшой их обработке, до полных систем обработки документов ODA, реализующих все процессы, обеспечиваемые ИСО 8613. Тестирование реализаций ODA охватывает тестирование возможностей систем в обеспечении функций, идентифицируемых частью ППД функционального стандарта ODA. Это осуществляется путем использования соответствующего абстрактного тестового комплекта (АТК) ФС и проверки наблюдаемых результатов обеспечения ФС (форма ЗОГ/ЗОП) и заявки разработчика относительно возможностей реализации (ЗОГ/ЗОП). Не все реализации ODA могут быть реализациями ФС. Однако устанавливаемые в настоящем стандарте методология, основы и процедуры могут быть применены к любому ППД, определенному в соответствии с формой ППД и нотацией, определенной в ИСО 8613. "Полная реализация ODA", т.е. реализация ODA, обеспечивающая генерацию и прием потоков данных ODA, может рассматриваться как неограниченный ППД.
Наряду с методологией и основами тестирования для абстрактных тестовых примеров, определенных в ИСО/МЭК 10183-2, необходимо установить процедуры, которые следует выполнять при тестировании реализации ODA. Это должно привести к сопоставимости и широкой приемлемости результатов тестирования, полученных различными тестерами, и, тем самым, к минимизации необходимости повторного тестирования реализации одной и той же системы.
Тестирование реализации ODA преследует двоякую цель. Во-первых, оно повышает способность реализации к взаимодействию и, во-вторых, позволяет пользователям быть более уверенными в возможности взаимодействия протестированных изделий ODA даже в том случае, когда тестирование реализации дает только косвенную оценку общих ее возможностей.
ODA и ФС ODA - это сложные стандарты, и поэтому исчерпывающее тестирование всех допустимых комбинаций функциональных возможностей непрактично как в техническом, так и в экономическом отношении. Однако тестирование реализаций показывает, что реализация способна продемонстрировать требуемые возможности при представительном наборе тестовых примеров.
Поскольку функциональные возможности реализаций ODA могут быть разделены на функции генерации и приема потоков данных, то методология и основы абстрактных тестовых примеров и процедур тестирования также подразделяются, охватывая эти два сценария. При тестировании функции генерации общая методология охватывает реализацию, обеспечиваемую с набором тестовых примеров, которые представляют собой аспекты уровня функциональных возможностей, соответствующих конкретному ФС. При этом реализация должна генерировать большое число потоков данных, которые проверяются тестером на соответствие потока данных функциональному стандарту и на наличие требуемых функциональных возможностей. При тестировании приема набор документов, содержащих тестовые примеры, которые представляют уровень функциональных возможностей, соответствующий конкретному ФС, передается в реализацию. При этом реализация должна обрабатывать потоки данных в соответствии с требованиями ФС к обеспечиваемым возможностям и в соответствии с заявкой разработчика относительно обеспечиваемых реализацией возможностей. После этого тестер анализирует в пунктах наблюдения выходной документ реализации. При тестировании функций реализации и приема вырабатывается отчет о тестировании, в котором зарегистрированы вердикты тестирования. В обоих случаях отчет о тестировании анализируют, чтобы определить соответствие результатов тестирования заявке разработчика о возможностях реализации. Таким образом, тестирование реализации должно дать четкую констатацию возможностей реализации относительно ее способностей к взаимодействию, основываясь на результате прогона набора тестовых примеров.
6 Концептуальная модель систем, основанных на ODA
Определение концептуальной модели тестируемых систем (ТС) является важным элементом в установлении основ тестирования реализаций, поскольку очевидно, что разработка методологии тестирования и методов прогона тестов относится к различным конфигурациям и ограничениям реальных систем. Поскольку документы ODA являются информационными структурами, они могут использоваться во многих прикладных контекстах. Концептуальная модель систем ODA полезна при классификации таких систем.
Примечание 10 - Система, основанная на ФС, рассматривается как частный случай системы, основанной на ODA.
Система, основанная на ODA, может рассматриваться как состоящая из трех концептуальных компонентов для типовых систем, инициирующих и (или) принимающих документы ODA:
a) компонента "обмен" (Ко), представляющего функции передачи потоков данных ODA в систему и из системы;
b) компонента "процесс" (Кп), представляющего ту часть прикладного процесса, которая выполняет преобразование в представление документа ODA в локальной системе;
c) компонента "системный интерфейс" (Ки), представляющего механизмы, используемые для преобразования функций контроля и наблюдения в локальное представление документа ODA.
Перечисленные выше компоненты являются концептуальными, и они не обязательно отражают структуру реализации реальной системы. Границы компонента - это виртуальные границы, существующие только в представлении реальной системы, основанной на ODA.
Концептуальная модель систем, основанных на ODA, приведена на рисунке 1.
Рисунок 1 - Концептуальная модель системы, основанной на ODA
Рисунок 1 - Концептуальная модель системы, основанной на ODA
6.1 Компонент "обмен"
Формат обмена потока данных ODA в общем случае непригоден для прикладной обработки. Системы, ориентированные на обработку документов ODA, будут обычно осуществлять прямое и обратное преобразования из формата обмена в некоторую форму локального представления, которая позволяет облегчить доступ к структурам, составляющим, атрибутам и содержимому документов и манипулирование этими элементами. Решением этих вопросов занимается компонент "обмен" системы, основанной на ODA.
Три уровня представления могут быть визуализированы:
а) Уровень ввода/вывода систем инициирует и принимает потоки данных ODA либо в виде файлов операционной системы, частей тела сообщения СОС, файлов на магнитных носителях, файлов на сетевых файловых системах, либо в виде, полученном через протокол передачи файлов, и т.п. На этом уровне потоки данных ODA остаются неинтерпретированными.
b) Следующий уровень - уровень кодирования/декодирования решает вопросы синтаксиса передачи потоков данных. Поток данных ОDA создается/интерпретируется в соответствии с предписанной грамматикой ACH.1 и правилами ИСО 8613-5, создавая или выделяя таким образом компоненты ODA последовательно один за другим.
c) Последний, так называемый уровень экстернализации/интернализации часто реализуется в сочетании с предыдущим уровнем. На этом уровне создаваемые/интерпретируемые составляющие преобразуются во внутренние структуры данных и обратно в соответствии с применением(ями) локальной системы, основанной на ODA.
В реальной системе два последних уровня часто объединяются с применением(ями) компонента "процесс", но они могут быть и отдельными частями, не входящими в объединение компонента "процесс" с применением, как в случае инструментации ODA.
6.2 Компонент "процесс"
Это прикладной процесс локальной системы, который может обеспечивать семантику ODA при работе с элементами, образующими локальное представление документа ODA.
К представляющим интерес вопросам в контексте данной модели относятся вопросы, связанные с преобразованиями документа ODA типов "модификация", "упорядочение" и "визуализация". Разработчики реализации могут пожелать заявить об обеспечении этих типов преобразований и о последующей необходимости тестирования. Для таких применений могут быть разработаны тестовые примеры с целью охватить системы ODA, выполняющие функции отправителей и получателей, а в пределах этих наборов применений - те системы, которые могут осуществлять одно или несколько идентифицированных преобразований.
Компонент "процесс" может обеспечить одну или несколько семантик ODA, которые могут рассматриваться как набор обеспечиваемых функциональных возможностей (или свойств); каждая функциональная возможность содержит набор элементов ODA (атрибуты, составляющие) вместе с описанием абстрактного результата (но не способа его достижения), который должен быть получен обрабатывающим компонентом, использующим эти элементы. Такая функциональная возможность может быть настолько проста, насколько она способна выполнять обработку позначного текста, или настолько сложна, как создание конкретной структуры упорядочения или вывод на экран документа из документа ODA обрабатываемой формы. Поэтому набор элементов ODA может представлять собой значение и семантику простого атрибута, но часто может состоять из нескольких элементов ODA и соответствующей семантики. Следовательно, поток данных ODA рассматривается как переносящий встроенные функциональные возможности, вносимые в него одним процессом документа и нуждающиеся в интерпретации другим процессом документа.
6.3 Компонент "системный интерфейс"
Прикладные процессы, используемые в системе, основанной на ODA, это не обязательно прикладные программы оконечного пользователя, т.е. те прикладные программы, которые взаимодействуют с пользователями, такие как редакторы, файловые системы документов и т.п. К ним могут относиться также такие прикладные процессы, как серверы печати документов или автоматические трансляторы, преобразующие документы в форму ODA и обратно.
Рассматриваемый компонент представляет различные механизмы, доступные для управляемых преобразований в основанных на ODA системах, а также механизмы, используемые в этих системах для отслеживания результатов. Например, в тех случаях, когда прикладной процесс осуществляет трансляцию из документа не-ODA в документ ODA, управляющим механизмом может служить интерфейс пользователя системы не-ODA. В тех случаях, когда системой, основанной на ODA, является сервер печати, отслеживаемый результат может быть представлен на отображаемом бумажном документе.
7 Методология тестирования реализации
Чтобы определить, способна ли реализация ODA/ФС правильно взаимодействовать, необходимо контролировать и наблюдать поведение реализации в процессе ее тестирования. Методология тестирования основана на запросе реализации продемонстрировать способность обеспечивать конкретные функциональные возможности ODA и ФС путем использования в процессе выполнения функций генерации и приема набора тестовых примеров, охватывающих конкретные функциональные возможности ODA/ФС. Для определения способности проверять заявленную функциональную возможность можно проанализировать потоки данных ODA, поступающие из генерирующей системы или из выхода приемной системы. Поскольку прикладные процессы ODA различны, то способы контроля и наблюдения могут изменяться даже в том случае, если различные разработчики заявляют обеспечение одного и того же набора функциональных возможностей.
Архитектура тестирования системы, основанной на ODA/ФС, приведена на рисунке 2.
Рисунок 2 - Архитектура тестирования системы, основанной на ODA/ФС
Рисунок 2 - Архитектура тестирования системы, основанной на ODA/ФС
Как описано в разделе 5, ТР обеспечивается набором тестовых примеров для тестирования способностей реализации выполнять функции генерации и приема. При тестировании функций генерации эти примеры принимают вид "спецификация тестовых примеров" (СТП), а при тестировании функций приема - вид "потоки данных тестирования" (ПТД), представляющий документы ODA/ФС, содержащие тестовые примеры. ТР имеет документы для анализа либо в виде потоков данных (при тестировании функций генерации) и/либо документы, наблюдаемые со стороны соответствующего системного интерфейса (при тестировании функций приема).
7.1 Процессы и структуры данных в реализации ODA/ФС
Чтобы лучше понять область применения методологии тестирования реализаций ODA/ФС, полезно рассмотреть некоторые другие процессы реализации и обрабатываемые структуры данных (см. рисунок 3). Получив поток данных тестирования (ПТД) или набор спецификаций тестовых примеров (СТП), тестируемая реализация должна обеспечить для тестера набор потоков данных в случае тестирования функций генерации и набор документов, возможно, в различных представлениях, в случае тестирования функций приема. Обе эти базовые формы называются "тестируемым документом" (ТД). Класс реализаций, которые принимают и генерируют ПТД, СТП и ТД, может быть определен с точки зрения различных путей, которые проходят процесс, и структур данных, используемых данной системой. Один из примеров пути может относиться к классу реализаций, которые принимают ПТД, представляющие сформатированную форму документа ODA. Такой класс реализаций будет декодировать принимаемый ПТД в локальное представление (ПФДД). В дальнейшем некоторые из этих реализаций могут воспринимать локальное представление документа и передавать его через локальный процесс отображения для создания визуально воспринимаемой формы документа ODA. Такой документ может использоваться для наблюдения обеспечиваемых возможностей через преобразование "отображение" для конкретных функциональных возможностей представления. Следует заметить, что отображаемый документ - это только одна из форм возможных представлений тестируемого документа.
Рисунок 3 - Пример процессов реализации и документов данных
Рисунок 3 - Пример процессов реализации и документов данных
Примечание - Список сокращений приведен в разделе 4.
Существует множество возможных реализаций, и на рисунке 3 показаны только те процессы и структуры данных, которые относятся к конкретному классу реализаций ODA. Каждая такая структура данных представлена в виде овала, а каждый процесс - в виде прямоугольника. Другие процессы и структуры данных, не показанные на рисунке 3, могут использоваться реализацией или оказаться полезными в другом качестве в виде дополнительных элементов компонента системного интерфейса. Одним из примеров этого является возможность реализации осуществлять преобразование типа модификация из сформатированно-обрабатываемой формы документа в обрабатываемую форму документа. Другим примером может служить реализация, обеспечивающая прикладной процесс "сканер" файлов, который осуществляет преобразование визуализация для получения заданной визуально воспринимаемой формы структуры или содержимого представления "обрабатываемая форма документа" (ПОДД).
Приведенный на рисунке 3 пример показывает класс реализаций, которые осуществляют только генерацию документов обрабатываемой формы, хотя они могут принимать сформатированные, обрабатываемые и сформатированно-обрабатываемые формы документа и выполнять их дальнейшую обработку. Из показанного на рисунке 3 класса реализаций можно идентифицировать большое число путей обработки:
1 СТП-Редактирование-ПОДД-Кодирование-ТД;
2 ПТД-Декодирование-ПФДД-Отображение-ТД;
3 ПТД-Декодирование-ПФОДД-Отображение-ТД;
4 ПТД-Декодирование-ПОДД-Редактирование-ПОДД-Кодирование-ТД;
5 ПТД-Декодирование-ПОДД-Упорядочение-ПФОДД-Отображение-ТД;
6 ПТД-Декодирование-ПФОДД-Упорядочение-ПФОДД-Отображение-ТД;
7 ПТД-Декодирование-ПОДД-Редактирование-ПОДД-Упорядочение-ПФОДД-Отображение-ТД.
Это возможные пути тестирования для данного класса реализаций, каждый из которых требует соответствующего набора тестовых примеров.
7.2 Начальная задача тестирования реализации
Начальная задача тестирования реализаций должна быть сконцентрирована на наиболее вероятных типах реализаций с тем, чтобы облегчить разработку необходимых наборов тестовых примеров. Очевидно, что разработка тестовых примеров для всех возможных типов реализаций и для всего набора функциональных возможностей ИСО 8613 - непрактичная, если не невыполнимая задача. Сузив область применения соответствующих тестовых примеров, можно своевременно их разработать и быть более уверенным в том, что проверенная реализация будет успешно взаимодействовать при широком наборе документов. Дальнейшее сужение области применения должно рационально учитывать появление все большего числа реализаций ФС конкретного типа. Так, предполагается, что в ближайшее время будут преобладать преобразователи для систем обработки документов частного пользования относительно систем обработки документов, обеспечивающих полную архитектуру, что позволит, например, упростить прикладные программы редактирующего класса.
Отсюда следует, что разработка тестовых примеров для первых версий ФС должна быть сконцентрирована на тех функциональных возможностях, которые будут наиболее вероятно обеспечены в ожидаемых изделиях, т.е. в реализациях ФС, осуществляющих преобразования документов в форму, приемлемую для систем обработки документов частного пользования, и обратно. Например, в разделе 6 ИСО/МЭК МФС 11181-1 подробно изложены тестовые примеры для проверки возможностей реализаций в обеспечении функциональных возможностей документов.
8 Тестирование функции генерации
На рисунке 4 показаны функциональные компоненты, необходимые для тестирования потоков данных, генерируемых ТР для проверки соответствия ФС на конкретном функциональном уровне ППД-L. На этом рисунке показаны три региона: "стандарт", "реализация" и "тестер". Эти регионы разграничивают ответственности за создание структур информации/данных и т.п., используемых при тестировании функций генерации ФС.
Рисунок 4 - Функциональные компоненты тестирования функции генерации
ДИ - дополнительная информация
Рисунок 4 - Функциональные компоненты тестирования функции генерации
Регион "стандарт" показывает, какую информацию необходимо получить из мира стандартизации для того, чтобы обеспечить возможность тестирования функций генерации реализации ФС. Регион "реализация" показывает, что разработчик реализации несет ответственность за заполнение "заявки об обеспечении функции генерации" (ЗОГ), за обеспечение дополнительной специфичной для реализации информации, необходимой для тестирования, и за создание большого числа потоков данных ODA, подлежащих тестированию, при условии обеспечения абстрактных тестовых примеров для ППД-L ФС. Регион "тестер" показывает, какая информация должна использоваться системой тестирования при анализе потоков данных ODA, вырабатываемых реализацией.
8.1 Регион "стандарт"
В регионе "стандарт" требуются тестовые примеры для функции генерации ODA, из которых могут быть образованы тестовые примеры генерации для конкретного ППД на конкретном функциональном уровне L. Для того чтобы разработчик заявки об обеспечении функции генерации имел стандартный метод, для функциональных стандартов стандартизована форма этой заявки. Она называется формой ЗОГ для ППД-L. Эта форма разработана в ИСО/МЭК 10183-2. Настоящий стандарт - это ППД на конкретном функциональном уровне L. Возникает также потребность в разработке формы отчета о тестировании для региона "тестер", которая обеспечила бы общий формат для записи результатов тестирования функции генерации.
8.2 Регион "реализация"
Для тестирования функции генерации регион "реализация" использует абстрактные тестовые примеры для конкретного ППД на функциональном уровне L и создает исходящий из заданной реализации набор потоков данных тестирования (ODA1-N) для их анализа тестером. Региону "тестер" необходима также заполненная форма ЗОГ для ППД-L и любая дополнительная информация, используемая при тестировании функции генерации.
8.3 Регион "тестер"
Регион "тестер" показывает, что тестер использует правила, приведенные в приложении G к ИСО 8613-1, для анализа соответствия потоков данных 1-N ODA указанному стандарту и соответствующему ППД. Набор потоков данных ODA используется также для проверки наличия тестовых примеров в соответствии с информацией ЗОГ-LI. В обоих примерах результаты 1-N для каждого потока данных вводятся в результаты процесса регистрации, который обеспечивает вердикты в отчете о тестировании конкретной реализации. Следует отметить, что между тестовыми примерами и потоками данных не обязательно должно существовать однозначное соответствие и не обязательно каждый тестовый пример должен быть представлен в наборе потоков данных, обеспечиваемых заданной реализацией 1.
9 Тестирование функции приема
На рисунке 5 показаны функциональные компоненты, необходимые для тестирования потоков данных, генерируемых ТР для проверки соответствия ФС на конкретном функциональном уровне L. На этом рисунке показаны три региона: "стандарт", "реализация" и "тестер". Эти регионы разграничивают ответственности за создание структур информации/данных и т.п., используемых при тестировании функции приема ФС.
Рисунок 5 - Функциональные компоненты тестирования функции приема
ДИ - дополнительная информация
Рисунок 5 - Функциональные компоненты тестирования функции приема
Регион "стандарт" показывает, какую информацию необходимо получить из области стандартизации для того, чтобы обеспечить возможность тестирования функции приема реализации ФС. Регион "реализация" показывает, что разработчик реализации несет ответственность за заполнение "заявки об обеспечении функции приема" (ЗОП), за обеспечение дополнительной специфичной для реализации информации, необходимой для тестирования, и за выработку большого числа документов (возможно, в одном или нескольких представлениях), подлежащих тестированию при условии обеспечения набора потоков данных для реализаций ФС функционального уровня L. Регион "тестер" показывает, какая информация должна использоваться тестирующей системой при анализе документов, вырабатываемых реализацией.
9.1 Регион "стандарт"
В регионе "стандарт" требуются тестовые примеры ODA, из которых могут быть образованы тестовые примеры для конкретного ППД на функциональном уровне L. Для того, чтобы разработчик заявки об обеспечении функции приема имел стандартный метод, для функциональных стандартов стандартизована форма этой заявки. Она называется формой ЗОП для ППД-L. Эта форма разработана в ИСО/МЭК 10183-2. Настоящий стандарт - это ППД на конкретном функциональном уровне L. Возникает также потребность в разработке формы отчета о тестировании для региона "тестер", которая обеспечила бы общий формат для записи результатов тестирования функции генерации.
9.2 Регион "реализация"
Для тестирования функции приема регион "реализация" принимает потоки данных ODA, представляющие тестируемые документы для конкретного ППД на функциональном уровне L, и создает для заданной реализации 1 набор документов (ДОКУМЕНТЫ 1-N) в целях их анализа тестером. Эти документы могут создаваться в различных представлениях, включая потоки данных ODA, последовательно проверяться с использованием методологии тестирования функций генерации. Региону "тестер" необходима также заполненная ЗОП для ППД-L и любая дополнительная информация о реализации, используемая для тестирования функции приема.
9.3 Регион "тестер"
Регион "тестер" показывает, что тестер генерирует набор потоков данных ODA, содержащих тестовые примеры для конкретного ППД на функциональном уровне L. Они передаются в реализацию, которая обеспечивает затем набор представлений документов 1-N для тестирования. Анализатор документов использует эти представления документов 1-N вместе со спецификациями тестов 1-N и проверяет обеспечение функциональных возможностей в соответствии с ЗОП-LI. Результаты 1-N тестирования каждого документа вводятся в процесс регистрации результатов, который обеспечивает вердикты для отчета о тестировании конкретной реализации.
10 Требования к абстрактным тестовым примерам
В этом разделе приведены требования к разработке абстрактных тестовых примеров. К построению абстрактных тестовых примеров предъявляют требования двух видов. Первое состоит в том, что должна быть предусмотрена возможность настройки абстрактных тестовых примеров для ППД ФС. Второе требование состоит в том, чтобы была предусмотрена возможность настройки абстрактных тестовых примеров для различных типов реализаций этих ППД.
Возможность изменения абстрактных тестовых примеров для различных ППД и для различных типов реализаций дает несколько преимуществ. Во-первых, экономятся усилия, поскольку отпадает необходимость записывать набор тестовых примеров для каждого ППД и каждой реализации. Во-вторых, обеспечивается взаимная согласованность между наборами тестовых примеров для различных ППД и ТР, поскольку для порождения специфичных для ППД тестовых примеров используются одни и те же правила.
Настройка тестовых примеров для различных ППД может быть достигнута путем построения тестовых примеров, содержащих минимальный объем спецификации. Полная спецификация документа в общем случае не может быть приспособлена к различным ППД, поскольку различные ППД допускают различные наборы структур и различные комбинации атрибутов и значений. По этой причине тестовый пример будет приспособлен с наибольшей вероятностью, если он имеет незначительно зависимую от ППД информацию, определенную в тестовом примере, и если он определен наиболее общим способом.
Приспособляемость к различным ТР может быть достигнута путем определения тестовых примеров, основанных на функциональных возможностях, поскольку четкое определение функциональных возможностей способствует общему пониманию набора функций, обеспечиваемых различными реализациями.