Тестирование переносимости прикладных программ.

"ЖУРНАЛ РАДИОЭЛЕКТРОНИКИ" N 2 , 2000
оглавление

дискуссия

ТЕСТИРОВАНИЕ ПЕРЕНОСИМОСТИ ПРИКЛАДНЫХ ПРОГРАММ

В.Н. Корниенко, А.Я. Олейников, В.А. Черепенин,

Институт радиотехники и электроники РАН

Получена 17 февраля 2000 г.

Работа посвящена проблемам, связанным с переносом прикладных программ (ПП) между различными программно-аппаратными платформами. Под переносимостью ПП понимается возможность использования ПП на различных программно-аппаратных платформах, отличающихся по архитектуре и характеристикам, с сохранением или небольшим изменением функций ПП. Обеспечение переносимости, прежде всего, позволяет сохранить затраты, вложенные в реализацию и апробирование ПП. Переносимость ПП достигается за счет использования соответствующих стандартов. Основное содержание работы состоит в описании методики тестирования ПП на соответствие этим стандартам, выполненной авторами согласно документу ISO/IEC 13210 ANSI/IEEE Std 1003.3 и представленной в виде проекта нормативного документа.

Работа выполнена в рамках проектов Минсвязи РФ и ФЦП "Интеграция".

1. Проблема переносимости прикладных программ.

В настоящее время, благодаря интенсивному развитию элементной базы ЭВМ, изменение или модернизация аппаратных платформ происходит достаточно часто.

Прогресс аппаратной части, который определяется не только повышением предоставляемых ресурсов, увеличением быстродействия, но и новыми качественными свойствами, неизменно приводит к изменению всей программной среды, в которой функционируют ПП. Время морального старения машинных ресурсов оказывается значительно меньшим, чем время разработки больших пакетов ПП. Это делает задачу переносимости и повторного использования ранее разработанных пакетов ПП весьма актуальной и приводит к необходимости создания переносимых ПП [1-3].

Обычно различают три вида переносимости [4, 5]:

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

вертикальную, когда ПП должна функционировать в совершенно новой аппаратно-программной среде (существенное изменение класса компьютеров, на которых работала рассматриваемая ПП). Например: ПП, ранее работавшая на ПК с ОС WINDOWS'95, переносится на суперкомпьютер с операционной системой UNIX.

переносимость, учитывающая возможность развития конкретной операционной системы [6, 7, 8]. В этом случае разрабатываемые ПП должны минимально использовать непосредственные функции аппаратной платформы (см., например, [9]).

1.1. Модель открытых систем OSE/RM.

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

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

Основой, обеспечивающей возможность реализации открытых систем, является совокупность стандартов, с помощью которых унифицируется взаимодействие аппаратуры и всех компонент программной среды: языки программирования, средства ввода/вывода, графические интерфейсы, системы управления базами данных, протоколы передачи данных в сетях и т.п. В результате сотрудничества многих национальных и международных организаций был определен набор стандартов, направленных на реализацию требований, обеспечивающих различные аспекты открытых систем. Число этих стандартов весьма велико, поэтому с целью структуризации среды рабочей группой POSIX P1003.0 Института инженеров по электронике и электротехнике (IEEE) предложена Эталонная Модель Среды Открытых Систем (OSE/RМ) [14]. В настоящее время модель, как и сам документ POSIX P1003.0, является документом ISO/IEC TR 14252.

1.2. Понятие API.

Эталонная Модель Среды Открытых Систем в качестве одного из основных компонентов включает в себя интерфейс прикладных программ (API) [14], определенный как интерфейс между ПП и операционной системой при взаимодействии через предоставляемые этой системой сервисы. Исходно API был разработан для обеспечения простоты переноса ПП между различными программно-аппаратными платформами. В настоящее время часть сервисов, предоставляемых API, обеспечивают и возможность обмена информацией между двумя или более системами.

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

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

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

1.3. Набор международных стандартов, обеспечивающих переносимость программ.

Опыт создания мобильных программных средств, который обобщался более 10 лет, привел к необходимости разработки концепции и комплекса стандартов, обеспечивающих эффективную переносимость прикладных программ между различными аппаратными и программными платформами. Основу составила группа стандартов, созданная специалистами США под эгидой IEEE (Institute of Electrotechnical and Electronics Engineers) под общим названием "Интерфейсы операционных систем, обеспечивающие переносимость прикладных программ" (Portable operating system interfaces - POSIX) [14]. К настоящему моменту группа POSIX содержит около 50-ти документов (см., например, http://standards.ieee.org). Основным назначением этой группы стандартов является решение проблемы переноса программ за счет унификации интерфейса операционных систем ЭВМ с различными прикладными программами, а также с окружающей средой. Сами стандарты POSIX не ориентированы на определенную архитектуру компьютеров и лишь предполагают использование современной операционной среды (прежде всего операционных систем клана UNIX), а также тех языков программирования, на которые разработаны международные стандарты [12].

Формирование концепции стандартов POSIX осуществлялось, исходя из следующих задач:

содействие облегчению переноса кода прикладных программ на иные платформы;

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

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

определение необходимого минимума интерфейсов прикладных программ;

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

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

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

базовые, которые определяют общие принципы построения, основы реализации и методологию тестирования интерфейсов переносимых ПП, а также административное управление программами. К базовым относятся стандарты IEEE 1003.0, 1003.1, 1003.2, 1003.3, 1003.4;

стандарты, конкретизирующие интерфейсы ПП, разработанные на языках программирования Си, Фортран, Ада, с операционной системой (IEEE 1003.5, 1003.9, 1003.16, 1003.19, 1003.20);

стандарты, определяющие взаимодействие в распределенных открытых системах, телекоммуникацию в компьютерных сетях и защиту информации (IEEE 1003.6, 1003.8, 1003.12, 1003.15, 1003.17);

стандарты, регламентирующие процессы создания, основные компоненты и структуру ППО для интерактивного взаимодействия с пользователями, а также для мультипроцессорных систем, суперкомпьютеров, систем реального времени (IEEE 1003.10, 1003.11, 1003.13, 1003.14, 1003.18).

Исходным документом служит стандарт IEEE 1003.0.

2. Проблема тестирования на переносимость.

Общая методология тестирования для проверки соответствия интерфейсов ППО стандартам POSIX изложена в стандарте IEEE 1003.3. В этом документе представлены принципы формирования наборов тестов и предлагается методика развития системы тестов для контроля создаваемых приложений на соответствие стандартам POSIX. Введено понятие тестовых утверждений и проведена их классификация. В методе тестирования определяются следующие виды работ:

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

2.1. Методика тестирования.

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

Рис.1. Взаимоотношение объектов тестирования, стандартов POSIX и методики тестирования

2.1.1. Выделение из прикладной программы элементов тестирования. Их классификация.

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

По функциональному признаку модули можно разделить на две группы (Рис.2):

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

Рис.2. Модульная структура прикладной программы

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

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

Рис.3. Структура модулей взаимодействия с внешней средой.

2.1.2. Определение уровней тестирования элементов прикладных программ.

К различным по сложности элементам тестирования применяются различные по емкости уровни тестирования. По уровню сложности различают три вида тестовых испытаний [15]:

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

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

оценочные тесты, устанавливающие лишь общие характеристики качества.

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

2.1.3. Принципы формирования тестовых утверждений.

Исходя из принципов, изложенных в стандартах, можно построить целый ряд непротиворечивых следствий (утверждений) различной степени сложности. На их основе разрабатываются так называемые тестовые утверждения: некоторые заключения о функционировании системы в том случае, если она удовлетворяет стандартам. Само тестовое утверждение может принимать два значения: ИСТИНА (если поведение системы удовлетворяет стандарту) или ЛОЖЬ (если поведение системы отклоняется от стандартизованных норм). По отношению к тестируемой программе утверждения можно разделить на четыре категории, представленные на Рис.4:

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

- (I) Основные тестовые утверждения для требуемых свойств прикладной программы

- (II) Расширенные тестовые утверждения для требуемых свойств прикладной программы.

- (III) Основные тестовые утверждения для опциональных свойств прикладной программы.

- (IV) Расширенные тестовые утверждения для опциональных свойств прикладной программы.

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

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

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

- "ТЕСТ ПРОШЕЛ" - эта информация свидетельствует об успешном выполнении проверки утверждения

- "ТЕСТ НЕ ПРОШЕЛ" - результат, возвращаемый в том случае, если поведение программы отличается от требуемого стандартами (тестовое утверждение приняло значение ЛОЖЬ)

- "ТЕСТ НЕ ВЫПОЛНЯЛСЯ" - такой результат возможен только для расширенных утверждений, выполнение которых в общем случае не обязательно (группы утверждений II и IV)

-"СВОЙСТВО НЕ ПОДДЕРЖИВАЕТСЯ" - информация, возникающая в случае, если свойство, подлежащее тестированию, не используется в данной ПП.

2.1.4. Форма представления результатов работы тестирующего комплекса.

Большой объем проводимых тестовых испытаний налагает определенные требования к регистрации и обработке результатов тестирования. Данные, получаемые в процессе тестирования для дальнейшего анализа можно разделить на следующие группы [16, 17]:

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

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

Большой объем проводимых испытаний вызывает также необходимость создания автоматизированного испытательного комплекса. Испытательный комплекс включает в себя:

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

3. Основные направления развития программы сертификации.

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

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

Заключение.

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

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

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

Существо методики, в основе которой лежит стандарт ISO/IEC 13210 ANSI/ IEEEStd 1003.3 состоит в выделении в тестируемой программе элементов тестирования и проверке их на соответствие тестовым утверждениям, содержащимся в стандартах.

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

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

Литература.

[1] Б.Боэм, Дж.Браун, Х.Каспар и др. Характеристики качества программного обеспечения. Пер. с англ. Е.К.Масловского. - М.: Мир, 1981.

[2] Vincent J., Waters A., Sinclair J. Software quality assurance. Vol.II. A programme guide. Englewood Cliffs, New Yersey: Prentice-Hall, 1988.

[3] Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. - М.: Научная книга, 1997. - 368 с.

[4] Мобильность программного обеспечения. под.ред. Д.Б.Подшивалова. Пер. с англ. - М.: Мир, 1980.

[5] DoD Software Reuse Initiative Vision and Strategy. DoD USA. July 15, 1992.

[6] Арсено Ж., Тиман М., Хенкель-Уоллес Д.В. Переносимость программного обеспечения. GNU Открытые системы. 1993. Вып.2. С.29-35

[7] Липаев В.В., Позин Б.А., Штрик А.А. Технология сборочного программирования. М.: Радио и связь, 1992.

[8] APP - Application Portability Profile. The U.S. Government open system evironment profile OSE/1 Version 2.0 NIST. Washington. 1993

[9] Musa J.D., Iannino A., Okumoto K. Software Reliability: Measurement, Prediction, Application. N.Y. Mc-Graw-Hill, 1987.

[10] А. Я. Олейников. Открытые системы — основное направление информационных технологий для построения информационной инфраструктуры. "Радиотехника", 1998 г., № 12, C.3

[11] А.Я. Олейников. Открытые системы: концепция и реальность. Открытые системы, 1993, осень, С.53.

[12] Зайцев С.С., Кравцунов М.И., Ротанов С.В. Сервис открытых информационно-вычислительных сетей. Справочник. М.: Радио и связь, 1990.

[13] Open systems handbook: A guide to building open systems. Digital Equipment Corporation.USA, 1991.

[14] IEEE Std 1003.0-1995 IEEE Guide to the POSIX® Open System Environment (OSE).

[15] Джонс Д. Проверка соответствия прикладных систем стандарту POSIX1. Открытые системы. 1992. Вып.1.С.7-13.

[16] Kit E. Software testing in the Real World - Improving the Process. Addison-Wesley. 1996.

[17] Липаев В.В. Отладка сложных программ. М.: Энергоатомиздат, 1993.

Авторы: Корниенко Владимир Николаевич, e-mail: korn@mail.cplire.ru,
Олейников Александр Яковлевич, e-mail: olein@ire.ras.ru,
Черепенин Владимир Алексеевич, e-mail: cher@cplire.ru

оглавление

дискуссия