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

На правах рукописи

Домарацкий Ярослав Александрович

-! 2:;;:]

Автоматизированная система тестирования операционных систем реального времени микропроцессорных управляющих комплексов

Специальность 05.13.06 - Автоматизированные системы управления

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата технических наук

Санкт-Петербург 1999

Работа выполнена в Санкт-Петербургском государственном электротехническом университете «ЛЭТИ»

Научный руководитель -

доктор технических наук Никифоров В.В.

Официальные оппоненты:

доктор технических наук, профессор Фомичев B.C., кандидат технических наук Павлов В.А.

Ведущая организация -Институт микропроцессорных вычислительных систем РАН (Москва)

Защита состоится "зО" чюй^ 1999 года в часов на заседании специализированного совета К.063.36.03 Санкт-Петербургского государственного электротехнического университета «ЛЭТИ» по адресу: 197376, Санкт-Петербург, улица профессора Попова, д.5.

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

Автореферат разослан" 2/ " 1999 ГОда

Ученый секретарь диссертационного совета

доктор технических наук, профессор Кутузов О.И.

1. ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

Разделяют два типа затрат на системное тестирование:

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

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

Наибольшая трудоемкость в системном тестировании приходится на создание тестового комплекта (ТК), поскольку трудоемкость исполнения тестов можно снизить во много раз за счет создания высокоавтоматизированных тестовых комплектов. По опыту работы СПИИРАН трудоемкость системного тестирования составляет до 29% от трудоемкости разработки ПИ в целом, а трудоемкость создания новых тестовых комплектов составляет до 70% от трудоемкости системного тестирования. Поэтому снижение затрат на разработку тестового комплекта для системного тестирования является актуальной задачей.

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

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

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

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

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

1.4. Научная новизна.

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

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

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

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

1.5. Практическая ценность. Подготовлена для практического использования методика построения автоматизированных систем тестирования операционных систем реального времени в соответствии с

требованиями пятиуровневой модели процесса разработки ПИ (в соответствии с требованиями модели СММ),

На ПЭВМ типа IBM РС486 в среде Windows NT осуществлена программная реализация автоматизированной системы тестирования операционных систем реального времени микропроцессорных управляющих комплексов.

1.6. Внедрение результатов. Результаты диссертационной работы использованы в Санкт-Петербургском институте информатики и автоматизации РАН (СПИИРАН) при проведении системного тестирования в ходе разработки программных изделий, в том числе при разработке операционных систем реального времени микропроцессорных управляющих комплексов. Использование результатов автора позволило сократить почти на 50% трудоемкость разработки тестовых комплектов и на 35% трудоемкость фазы системного тестирования.

1.7. Апробация работы. Научные результаты и основные положения диссертации докладывались на Международной конференции «Региональная информатика 96», городском научном семинаре «Информатика и компьютерные технологии», научных семинарах базовой кафедры СПИИРАН в СПГЭТУ в раках программы «Интеграция».

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

1.9.Структура и объем работы. Диссертационная работа состоит из: введения, четырех глав, заключения и списка литературы^включакяцего 67 наименований. Работа содержит 21 рисунок и 5 таблиц.

2. КРАТКОЕ СОДЕРЖАНИЕ РАБОТЫ

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

2.1.1. Специфика операционных систем реального времени.

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

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

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

Большое число контролируемых объектов приводит к необходимости дополнительных затрат на проведение тестирования ОС при максимально возможном числе управляемых объектов (на проведение граничного тестирования ОС)

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

Многоплатформность. Часто при разработке ОС ставится задача поддержки нескольких аппаратных платформ и использования средств кросс компиляции при разработке пользовательских приложений. Это приводит к необходимости создания тестов и проведения тестирования на различных аппаратных платформах при использования кросс средств.

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

2.1.2. Классификация тестовых приложений.

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

Предложенная в диссертационной работе классификация тестовых приложений позволило выбрать наиболее эффективный способ реализации ТК для конкретных пользовательских приложений.

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

Модульное тестирование ОС предназначено для выявления дефектов в тестируемом модуле. Этот вид тестирования используется для подтверждения правильности выполнения спецификаций проектирования этим модулем (верификация модуля).

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

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

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

Системное тестирование является средством валидации ОС и выполняется, как правило, независимой группой системного тестирования. Данный вид тестирования выполняется циклически. Системное тестирование оканчивается в соответствие с принятыми критериями окончания тестирования.

К системным ТК для ОС обычно предъявляются следующие требования:

• полное покрытие тестируемых требований, предъявляемых к ОС (100% покрытие требований);

• достаточная степень покрытия кода ОС системными тестами (минимальное значение коэффициента покрытия кода ОС может изменяться в зависимости от необходимой полноты ТК от 75% до 100%);

» использование метода "черного ящика" - использование только требований к ОС при создании ТК, без применения знаний о внутренней организации ОС;

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

2.2. Во второй главе дан подробный анализ процесса системного тестирования ОС. Выделены основные этапы создания тестового комплекта. Проанализированы структуры ТК и на основе результатов подобного анализа разработано формальное представление логики ТК (плоская схема).

2.2.1. Основные виды системного тестирования.

На этапе системного тестирования наибольшие трудозатраты занимает процесс создания ТК и его запуск на целевой аппаратуре.

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

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

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

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

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

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

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

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

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

Тестирование производительности применяется для экспериментального определения временных характеристик ОС. К подобным характеристикам, как правило, относятся:

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

• время исполнения эталонных приложений - временные затраты на исполнение некоторых эталонных приложений;

» время задержки прерываний, вызванное ОС, - максимальное время, на которое прерывания запрещены в системе.

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

2.2.2. Этапы создания тестового комплекта.

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

2.2.3. Формальное представление тестовых комплектов. Разработано формальное представление ТК. Это представление позволяет

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

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

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

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

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

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

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

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

форма, представленная в Примере 1.

Пример!.

Время исполнения Задача А Задача В Задача С

Т1 АсСтгеСТАБКВ)

Т2 Аа^еСТАБКА)

ТЗ ЗшреЫБеЩ)

Т4 8изрепс18е1Г0

Т5 ТевШпсЮ

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

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

• интерпретации представления плоской схемы во время работы ТК (ТК, управляемый данными);

• компиляции плоской схемы в исполняемый код ТК (генерация исходного кода ТК на основе плоской схемы).

Наиболее важными свойствами плоских схем являются:

• использование плоских схем позволяет создавать хорошо обозримые описания ТК, содержащих спецификации параллельно выполняемых

задач и обработчиков прерываний, что обусловливает повышение эффективности разработки и исполнения ТК для ОС; • плоские схемы обеспечивают _ возможность проверки корректности реализации функций ОС (передачи данных и сигналов между задачами и обработчиками прерываний, динамического распределения ресурсов памяти, специальных структур и процессорного времени);они пригодны для локальных и глобальных измерений времени, измерения временных характеристик ОС;

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

Пример 2. typedef struct Test_Step { int Taskld; void (* UtilServ) (); StepArg Arg_l; StepArg Arg_2;

};

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

Пример 3. union StepArg { int IntArg; char* StringArg; void (* FunArg) ( );

I* */

};

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

строкой и иметь собственную переменную для указания на анализируемый или исполняемый элемент плоской схемы: Тез181ер* СштеМ81ер;.

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

Использование плоских схем для разработки тестов и метода управления данными сокращает сроки разработки ТК и повышает его мобильность, а плата за это невелика. Размер кода тела интерпретатора плоских схем вместе с библиотекой функций составляет не более 10% от размера кода всего тестового комплекта.

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

Пример 4. Тев181ер Ме8БОиеие[ ] = {

/* — Очередь из 10 сообщений формируется для задачи Та$к_2 */ 0,&Ъоор81а]1,&сус1е_уаг, 10,

l,&CallPutMessage,Task_2,&mesl_ptr, /* Повтор посылки сообщения */ 0,&ЬоорЕпс1)&сус1е_уаг,0,

1,&Са11ТазкЕп(1,0>0, /* Задача Таяк_1 завершается */

/* — Очередь из 10 сообщений исчерпывается задачей Тазк_2 */

0,&Ьоор81а11Дсус1е_уагД0,

2)&CallGetMessage,&mes2_ptr,0, /* Повтор получения сообщения */

0,&ЬоорЕпс1,&сус1е_уаг,0,

ОДЕпс^о^сЬетеДО

}

Переменная сус\е_уаг в этом примере используется как переменная цикла. Можно построить вложенные циклы, каждый со своей переменной цикла - например, сус1е1_чаг для внешнего цикла и сус1е2_уаг для внутреннего цикла.

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

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

и

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

2.3.1. Автоматизация этапа анализа требований.

На данном этапе необходимо осуществить разбиение требований к ОС на тестируемые и не тестируемые требования и создать список тестируемых требований. Как правило, подобное разбиение не может быть произведено автоматически и выполняется тестировщиком на основе документов, содержащих перечень требований к системе (стандартов, спецификаций и т.д.). Таким образом, автоматизация данного этапа обычно не представляется возможной. В некоторых случаях, автоматизация может быть осуществлена за счет применения специальных программных систем автоматического отслеживания требований (например, DOORS - Dynamic Object Oriented Requirements System).

2.3.2. Автоматизация этапа создания списка элементарных тестов.

Процесс создания списка элементарных тестов на основе тестируемых

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

2.3.3. Автоматизация этапа реализации элементарных тестов.

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

2.3.4. Автоматизация процесса построения тестовых комплектов.

Автоматизация этого этапа, как правило, достигается за счет

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

тысяч. Это приведет к необходимости организации специфических сеансов тестирования.

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

2.3.5. Автоматизация загрузки, запуска и интерпретации работы тестовых комплектов.

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

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

2.4. В четвертой главе описан набор требований для успешной разработки процесса тестирования ОС в соответствие с пятиуровневой моделью СММ. Эти требования являются результатом обобщения практических данных, полученных в СПИИРАН при работе над реальными проектами программных изделий (ПИ) в различных предметных областях в течение более, чем трех лет, в которых автор принимал участие. Определены метрики, характеризующие процесс тестирования ПИ, и приводится краткое описание автоматизированной системы проведения системного тестирования ОС, которая была разработана с использованием результатов диссертационной работы при непосредственном участии автора.

2.4.1. Набор требований для разработки процесса тестирования ПИ.

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

СП принято строить в соответствие с многоуровневой моделью СММ Института технологии программирования (США), нашедшей признание и распространение среди ведущих мировых производителей программного обеспечения.

Анализ модели СММ выходит за рамки настоящей диссертации.

Как составная часть СП, должен быть разработан специальный стандарт на проведения тестирования ПИ - процесс тестирования (ПТ). В процессе тестирования должны _ быть четко разделены обязанности по тестированию между разработчиками и системными тестировщиками.

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

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

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

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

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

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

2.4.2. Метрики, характеризующие процесс тестирования ПИ.

Основными метриками, характеризующими процесс тестирования ПИ, являются:

Число тестов - характеризует представительность ТК. Обычно различают запланированное число тестов (определяется на основе анализа требований к ПИ и планируемого объема кода продукта на этапе разработки

плана тестирования) и число написанных тестов (характеризует готовность ТК к проведению тестирования). Учитывают также число исполненных тестов (характеризует полноту проведенного тестирования) и число прошедших тестов (характеризует степень готовности ПИ к выпуску).

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

Степень покрытия требований - характеризует представительность тестового комплекта. Различают: планируемую степень покрытия требований (как правило, 100%) и фактическую степень покрытия требований.

Таблица. Реальные метрики процесса тестирования встраиваемой ОС

Метрики Ядро ОС реАльного времени

Объем кода ядра ОС (КАЕЬОС) 75

Трудоемкость разработки ядра ОС (человеко-недель) 240

Объем ТК (КАЕЬОС) 41

Число тестов 7200

Число тестируемых версий ядра 9000

Трудоемкость фазы системного тестирования при разработке ТК традиционным методом (человеко-недель) 81

Трудоемкость фазы системного тестирования при использовании автоматизированной системы (человеко-недель) 53

Трудоемкость разработки тестового комплекта традиционным методом (человеко-недель) 57

Трудоемкость разработки тестового комплекта при использовании автоматизированной системы (человеко-недель) 30

Степень покрытия кода - характеризует представительность тестового комплекта. Различают: планируемую степень покрытия кода (как правило, не ниже 75%) и фактическую степень покрытия кода (степень кода ПИ, покрытого при проведении тестирования).

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

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

2.4.3. Автоматизированная система тестирования ОС реального времени.

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

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

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

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

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

Средства измерения покрытия кода ОС предоставляют возможность автоматизированного измерения степени покрытия кода ОС в процессе исполнения ТК.

Всего в автоматизированной системе тестирования ОС реального

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

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

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

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

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

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

3.4.Разработана и реализована автоматизированная система выполнения системного тестирования встроенных ОС реального времени, которая использовалась для проведения системного тестирования ПИ, разрабатываемых в СПИИРАН. Автоматизированная система обеспечила выпуск ПИ с требуемым качеством при сокращении трудоемкости фазы системного тестирования на 35% по сравнению с ранее существующими методами.

3.5 Осуществлено обобщение практических данных по тестированию ПИ, полученных в СПИИРАН при работе над реальными программными проектами в течение более, чем трех лет, по результатам обобщения сформулирован набор требований для успешной разработки процесса тестирования ПИ в соответствие с требованиями модели СММ.

4. ПУБЛИКАЦИИ ПО ТЕМЕ ДИССЕРТАЦИИ

1. Домарацкий Я.А., Никифоров В.В. Тестирование механизмов межзадачных взаимодействий в операционных системах реального времени. //Тезисы докладов V Санкт-Петербургской Международной конференции «Региональная информатика - 98», часть 2, с. 223 - 224.

2. Никифоров В.В., Домарацкий Я.А. Применение метода плоских схем для разработки тестовых комплектов для встраиваемых операционных систем. //Программные продукты и системы. - 1998. - №4. - с. 33 - 37.

3. Домарацкий Я.А. Модульное тестирование операционной системы реального времени. //Программные продукты и системы. - 1998. - №4. - с. 37 -40.

4. Никифоров В.В., Домарацкий Я.А. Системное тестирование программных изделий. //Программные продукты и системы. -1998. - №4. - с. 40-44.

5. Никифоров В.В., Домарацкий Я.А. Построение тестов для базовых функций встраиваемых операционных систем. //Программные продукты и системы. - 1998. - №4. - с. 44 - 46.