CC BY
16
групп, участвующих в разработке ПИ. Во всех других случаях ГСТ должна рекомендовать выпуск ПИ, даже
если в нем имеются дефекты.
ПОСТРОЕНИЕ ТЕСТОВ ДЛЯ БАЗОВЫХ ФУНКЦИЙ ВСТРАИВАЕМЫХ
ОПЕРАЦИОННЫХ СИСТЕМ
В.В. Никифоров, Я.А. Домарацкий
Встраиваемые операционные системы (ОС), как правило, являются мультизадачными. Полный состав функциональных возможностей и характеристики таких ОС определяются сферой реального применения и архитектурой аппаратных средств, для которых они разрабатываются. Вместе с тем существует некоторое базовое подмножество функций, реализация которых является непременным условием разработки полноценной ОС реального времени, ориентированной на поддержку пользовательских приложений.
Базовые функции встраиваемых ОС и задачи их тестирования
Предоставляемые пользователю функциональные возможности встраиваемой ОС подразделяются на статические и динамические.
Статические возможности ОС реализуются при подготовке прикладной программной системы на инструментальной ЭВМ. К этим возможностям ОС относятся возможности статического порождения множества прикладных задач и обработчиков прерываний, возможности включения в состав приложения необходимых библиотечных функций ОС, настройка основных параметров прикладных задач, статическое распределение ресурсов между прикладными задачами (ресурсов памяти, стеков, специальных структур данных).
Динамические функциональные возможности ОС реализуются в реальном времени в ходе работы программного приложения на целевом оборудовании. К базовым динамическим функциям встраиваемых ОС относятся: динамическое распределение между задачами таких ресурсов, как память, специальные структуры данных, процессорное время; обмен сигналами и данными между задачами; передача сигналов и данных задачам от обработчиков прерываний; обработка исключительных ситуаций.
Различные ОС могут иметь дополнительные базовые функции, такие как динамическое порождение задач, динамическая модификация основных параметров задач (например приоритет задачи), динамическое перемещение стеков задач, математические вычисления, обработка текстов, доступ к периферийным устройствам и т.д.
В настоящей статье рассматриваются вопросы тестирования базовых функций встраиваемых ОС с двух точек зрения. Во-первых, с точки зрения проверки логической корректности выполнения базовых функций ОС (функциональное тестирование), во-вторых - с точки зрения измерения времени, требуемого для выполнения отдельных базовых функций ОС.
Задачи функционального тестирования состоят из проверки исполнения базовых функций ОС путем вызова их из задач и обработчиков прерываний, своевременности переключения процессора между задачами, свое-
временности и безошибочности передачи сигналов и данных, а также преднамеренного создания исключительных ситуаций с целью проверки правильности их обработки.
Задачи измерения времени включают в себя организацию локальных измерений, характеризующих выполнение отдельных функций ОС; глобальных измерений, характеризующих общее время выполнения эталонных приложений; измерений реактивности системы, обусловливающей оценку времени между моментом возникновения прерывания и моментом входа в соответствующий обработчик прерываний.
Среди требований к встраиваемым ОС типичным является требование масштабируемости. Это означает наличие в ОС средств, предоставляющих пользователю возможности генерации такой конфигурации ОС, которая обладала бы требуемыми конкретными свойствами. Требуемая конфигурация задается комбинацией значений конфигурационных признаков. Росту количества конфигурационных признаков соответствует экспоненциальный рост числа возможных конфигураций ОС. Каждая из сгенерированных конфигураций ОС должна предоставлять прикладным задачам пользователя тот сервис, который соответствует связанному с ним набору конфигурационных признаков.
Требования к тестовым комплектам для тестирования встраиваемых ОС [1]: каждый тест должен быть нацелен на проверку конкретного требования к тестируемой базовой функции ОС; выполнение каждого теста должно начинаться при некотором стандартном состоянии тестируемой ОС; после завершения теста тестируемая ОС должна приводиться в некоторое стандартное состояние; ход выполнения каждого отдельного теста не должен зависеть от хода выполнения других тестов.
В случае тестирования встраиваемой ОС следует выполнять реинициализацию системы перед выполнением каждого теста. Такой подход с наибольшей надежностью обеспечивает независимость тестов и идентичность условий их запуска. В этих условиях каждый тест должен представлять собой полное мультизадачное приложение, выполнение которого разбивается на несколько фаз, а именно: фазу перезапуска ОС с инициализацией всех системных структур данных и состояния аппаратных интерфейсов, поддерживаемых тестируемой ОС; фазу инициализации глобальных структур данных теста и структур данных, контролируемых отдельными задачами и обработчиками прерываний; фазу перевода задач, составляющих тест, в состояние, обеспечивающее проверку тестируемой функции ОС; фазу регистрации результатов выполнения теста и перезапуска (реинициализации) системы для выполнения следующего теста.
Тестовый комплект должен обеспечивать проверку работоспособности ОС в произвольной конфигурации.
N пара петров ОС = N-мерный куб конфигураций
Слои-куба-
■Простейшие
О
-конфигурации
Неправильные комбинацгш параметров
Сложнейшая конфигурация
Для ОС с 18 двоичными параметрами:
- 20000 конфигурации ОС,
- 240000 неправильных комбинаций параметров.
Рис. 1. Пространство конфигураций встраиваемых ОС
Если настройка ОС выполняется путем задания набора значений N двоичных параметров, то общее число элементов пространства конфигураций ОС равно 2N (рис. 1). При N = 18 проверка всех элементов этого пространства требует значительных затрат машинного времени. При N = 30 и более полная проверка всех элементов пространства конфигураций становится неосуществимой. В этом случае следует ограничиваться проверками для верхних и нижних слоев вершин N-мерного куба.
Инструментальные средства тестирования встраиваемых ОС
В ходе разработки, отладки и выполнения тестов используются общие и специальные инструментальные средства. Под общими понимаются те аппаратные и программные средства, с помощью которых разрабатываются прикладные программные комплексы, строящиеся на базе данной ОС. Обычный набор общих аппаратных средств включает персональный компьютер (ПК), во внешней памяти которого размещаются исходные файлы приложений, инструментальные программы (инструментальная ОС со средствами редактирования исходных файлов; система программирования, включающая кросс-транслятор и компоновщик загрузочных файлов; комплекс коммуникационных программ, обеспечивающий связь ПК с отладочными стендами; про-грамма-отладчик, обеспечивающая интерактивное взаимодействие разработчика с отладочными стендами). Кроме того, во внешней памяти ПК размещаются промежуточные результаты обработки исходных файлов и готовые к загрузке исполняемые файлы приложений. В набор аппаратных средств входят также отладочные стенды с целевым процессором или микроконтроллером, осуществляющим исполнение приложений в реальном времени.
Специальные инструментальные средства тестирования представляют собой набор программ и программных продуктов, обеспечивающих автоматизацию процесса тестирования (например система "QA Partner" фирмы "Segue", ориентированная на работу с про-граммами-отладчиками, использующими оконный интерфейс [2]).
При тестировании масштабируемых встраиваемых ОС требуется разработка специальных инструментальных программ - программ-генераторов, которые обеспечивают формирование множеств тестов для конкретных конфигураций ОС и мониторов тестирования, организующих проведение сеансов тестирования.
Структура тестового комплекта
Каждый тестовый комплект для встраиваемой ОС представляет собой некоторое множество взаимодействующих задач и, возможно, обработчиков прерываний. Представление логики таких тестов путем непосредственного использования стандартных средств программирования приводит к трудностям двух типов.
Во-первых, отслеживание логики каждого теста затруднено необходимостью частого переключения внимания с одного участка текста программы на другой.
Во-вторых, точки, из которых происходит обращение к ОС, распределены по телу программы (рис. 2).
Анализ требований к тестовым комплектам для встраиваемых ОС приводит к выводу, что тесты должны строиться в виде процессов, управляемых данными. Среди факторов, приводящих к этому выводу, отметим следующие.
• Поскольку каждый тест должен представлять собой полное мультизадачное приложение, из этого следует, что спецификация всех тестов, составляющих тестовый комплект, непосредственно на стандартном языке программирования неизбежно страдала бы существенной избыточностью, так как все тесты содержали бы повторяющиеся фрагменты, относящиеся к инициализации задач и структур данных, к организации выполнения базовых операций ОС.
• Разработка тестов для базовых функций ОС непосредственно на стандартном языке программирования приводит к трудностям отслеживания логики теста, поскольку для такого отслеживания разработчику приходится на каждом шаге переключать внимание с одного фрагмента текста программы на другой. Спецификация логики теста в виде интерпретируемых структур данных, позволяет обойти эти трудности, например за счет использования представлений типа плоских схем (см. с. 33-37 наст. ном. журн.).
• Взаимодействия тестового комплекта с ОС могут быть локализованы в фиксированном месте тела программы, что позволяет лучше отслеживать взаимодействие тестов с ОС и, в частности, существенно упрощать решение задач измерения производительности.
• Некоторый проигрыш в эффективности исполнения, характерный для процессов, управляемых данными. В случае тестового комплекта это не играет решающего значения.
• Представление логики тестов в виде интерпретируемых структур данных существенно повышает мобильность тестового комплекта, поскольку при его переносе на процессоры других архитектурных линий требуется переработать лишь интерпретатор схем тестирования, что составляет (по нашему опыту) не более 10 % общего объема тестового комплекта.
Тест
Стек задачи 1
Тело задачи 1
Стек задачи 2
Тело задачи 1
Стек задачи 3
Тело задачи 1
Тестируемая ОС
Рис. 2. Множественные связи между тестом и ОС
Сеансы тестирования встраиваемых ОС выполняются в два этапа. На первом этапе осуществляется сборка исходных текстов тестов с библиотечными файлами, реализующими функции тестируемой ОС, генерация загрузочных (исполняемых) файлов. На этом этапе проверяются предоставляемые ОС возможности статического порождения множества прикладных задач и обработчиков прерываний, настройки основных параметров прикладных задач, возможности статического распределения ресурсов между задачами. Результаты первого этапа тестирования фиксируются в соответствующих файлах-протоколах статического тестирования. Отметим, что для сокращения времени статического этапа тестирования следует стремиться к сокращению числа исполняемых файлов.
На втором этапе осуществляется загрузка исполняемых файлов в целевую систему и исполнение тестов с использованием коммуникационных и отладочных программ.
Основное время (5-10 секунд) тратится на загрузку теста в память целевого устройства. Это справедливо для небольших тестов, поскольку загрузочный файл включает не только тело теста, но и тело самой ОС. Использование операции реинициализации целевого устройства и ОС позволяет размещать серию элементарных тестов в одном загрузочном файле. Такое решение позволяет сократить время выполнения как статического, так и динамического этапа сеанса тестирования.
При построении тестов в виде процессов, управляемых данными, плотность тестов на килобайт исполняемого файла увеличивается, что позволяет сократить продолжительность обоих этапов сеанса тестирования.
Пути повышения мобильности тестов для ОС
Как отмечалось выше, существенное повышение мобильности тестового комплекта достигается за счет представления логики тестов в виде интерпретируемых структур данных. При непосредственной реализации этого подхода тесты представляются с использованием синтаксических форм, имеющихся в той системе программирования, на которую ориентируется тестируемая ОС, например: при использовании системы программирования на основе языка ассемблера логика тестов мо-
жет представляться последовательностью макросов, разворачиваемых компилятором в массивы данных (при программировании на языке Си для этой цели удобнее всего использовать массивы структур).
Дополнительное повышение мобильности тестового комплекта может быть достигнуто за счет представления логики тестов в универсальной форме, не зависящей от особенностей системы программирования. Для адаптации такой универсальной формы к конкретной системе программирования достаточно сделать несложный фильтр, приводящий универсальное представление тестов к нужной синтаксической форме.
Еще один круг вопросов, связанных с проблемой повышения мобильности тестовых комплектов касается адаптации тестов к особенностям тестируемой ОС, в частности к набору ее функциональных возможностей. Сюда относятся вопросы параметрической настройки тестового комплекта, например способов представления приоритетов задач и величины временных интервалов; вопросы моделирования одних механизмов взаимодействия задач через другие, например механизма рандеву через механизм передачи сообщений или механизма мониторов через семафоры.
Для упрощения адаптации первого типа требуется соответствующее внимание к организации тестового комплекта, обособление параметров, требующих перенастройки. Для решения вопросов адаптации второго типа необходимо располагать соответствующими методами моделирования.
Разработка тестовых комплектов для встраиваемых ОС является трудоемкой задачей. Использование плоских схем для построения тестов с целью проверки базовых функций ОС позволяет существенно снизить эту трудоемкость при одновременном повышении качества тестирования и в конечном счете - качества разрабатываемых встраиваемых ОС и прикладных программных комплексов.
Список литературы
1. Beizer В. Software Testing Technique. NY, International Thomson Computer Press, 1990, 550 p.
2. QA Partner. User's Guide. Newton Center, MA, Segue Software, Inc. 1995,250 p.
АВТОМАТИЗАЦИЯ ПРОЦЕССА УПРАВЛЕНИЯ ПРОЕКТОМ ПРОГРАММНЫХ ИЗДЕЛИЙ
С.Н. Баранов, А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Как показывает опыт, внедрение стандартного процесса, соответствующего модели СММ [1], в повседневную работу организации требует значительных усилий и времени. В ИДУ эта работа началась с интенсивного обучения всех сотрудников, которое включало несколько курсов по модели СММ и способам практического использования новой методологии. По окончании обучения в ИДУ была организована специальная группа процесса, которая взяла на себя труд по приспособлению методологии модели СММ к конкретным условиям работы ИДУ, то есть по разработке и внедрению стандартного процесса.
Даже в этом случае среди сотрудников не было единого понимания того, как следует выполнять те или иные требования стандартного процесса. Различия взглядов на требования стандартного процесса особенно наблюдались у руководителей проектов, поскольку большинство из них воспринимало эти требования как ограничение их творческой инициативы. Поэтому требования стандартного процесса приходилось представлять в убедительной и простой форме, чтобы сотрудники сами могли осознать правильность избранного администрацией метода работы.
