CC BY
22
—Продолжтггельность цикла тестирования
Календарное время
Рис. 4. Распределение найденных в цикле тестирования дефектов по уровням серьезности
3, Далее следует производить сравнение распределений найденных дефектов в каждом цикле тестирования (рис. 5). При этом должна наблюдаться тенденция снижения количества и уровня серьезности найденных дефектов при продвижении к более поздним циклам тестирования.
4. При соблюдении условия (3) тестирование разработчиками продолжается до тех пор, пока не будут покрыты тестами 100 % спецификаций функционального проектирования и 100 % кода тестируемой сборки версии ПИ, а на текущем цикле тестирования работоспособности не обнаруживается дефектов выше второго уровня серьезности. Причем на последнем цикле тести-
рования обнаруженных дефектов должно быть не более пяти.
Если условие (4) (100 % покрытие спецификаций функционального проектирования и кода тестируемой сборки версии ПИ) выполняется на втором цикле тестирования разработчиками, то должен выполняться третий цикл тестирования, а при необходимости и последующие циклы с новыми тестами до подтверждения условия (3) (снижение количества и уровня серьезности найденных дефектов при продвижении к третьему и последующим циклам тестирования).
Все обнаруженные дефекты при тестировании разработчиками должны быть занесены в базу данных ошибок и дефектов и закрыты к моменту передачи сборки версии ПИ на системное тестирование.
5. При системном тестировании также проводится не менее трех циклов тестирования. При этом дополняется график (рис. 3), сроятся распределения найденных дефектов по уровням серьезности (см. рис. 4 и 5), кроме того должны выполняться условия системного тестирования. В ИДУ - это 100 % покрытия требований заказчика к ПИ, 75 % покрытия кода тестируемой сборки версии ПИ, а в последнем цикле системного тестирования не должно быть обнаружено более трех дефектов второго уровня серьезности.
По окончании системного тестирования прошедшая тестирование сборка версии ПИ должна быть возвращена в ПГ для устранения выявленных дефектов и подготовки ее к поставке заказчику.
Список литературы
1, Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при разработке ПИ. // Программные продукты и системы. - 1998. - №2. - С.2-6.
2. Paulk, М.С.', B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version LI. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability
Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-17S. Software.
3. Baranoff S., Domaratsky A., Lastochkin N,, Morozov V. An automated system for software project planning. International Conference on Informatics and Control (ICI&C'97 June 9-13, 1997 St.Petersburg). Proceedings. Volume 2 of 3. St.Petersburg. SPIIRAS, 1997 - P.785-795.
Количество найденных дефектов (штук)
Уровни серьезности найденных дефектов
Д 1 мшжм.
Календарное время
Рис. 5. Пример сравнения циклов тестирования
ПРИМЕНЕНИЕ МЕТОДА ПЛОСКИХ СХЕМ ДЛЯ РАЗРАБОТКИ ТЕСТОВЫХ КОМПЛЕКТОВ ДЛЯ ВСТРАИВАЕМЫХ ОПЕРАЦИОННЫХ СИСТЕМ
В.В. Никифоров, Я.А. Домарацкий
Факт наличия проблемы отладки и тестирования встраиваемых операционных систем (ОС) общеизвестен [1-6]. Качественное системное тестирование встраиваемой ОС представляет собой сложную и трудоемкую задачу. Разделяют два типа затрат на системное тестирование - затраты на создание тестового комплекта (составление плана и процедуры системного тестирования, разработка и отладка тестов и тестового комплекта в целом) и затраты на исполнение собственно тестов, входящих в состав тестового комплекта (исполнение тестов, регистрация дефектов и составление отчетов о системном тестировании).
Наибольшая трудоемкость в системном тестировании приходится на создание тестового комплекта, по-
скольку трудоемкость исполнения можно снизить во ¡много раз за счех создания высокоавтоматизированного тестового комплекта.
По опыту работы ИДУ, трудоемкость системного тестирования составляет 29 % от трудоемкости создания ОС в целом, а трудоемкость создания тестовых комплектов составляет до 70 % от трудоемкости системного тестирования [7]. Задача сокращения трудоемкости создания тестовых комплектов является актуальной, ее решение можно осуществить за счет применения специальных языков программирования и специализированных инструментальных средств, а также за счет создания и использования эффективных методов построения тестов.
Так возникла задача отыскания более удобной формы описания отдельных тестов тестовых комплектов для встраиваемых ОС. Одним из возможных решений этой задачи является использование нового метода, разработанного авторами специально для сокращения затрат при построении тестовых комплектов названного методом плоских схем.
Простейший вариант построения плоских схем базируется на следующих предположениях (сохраняется повторяемость порядка выполнения тестов):
а) для разработки тестов можно использовать только малое количество простых утилит (например менее 10 единиц);
б) каждая базовая функция ОС и каждая тестовая утилита может иметь ограниченное число параметров (например не более двух);
в) тест может включать в себя только операторы вызова сервисов ОС и тестовых утилит;
г) различные задачи, выполняемые тестом, должны иметь различные приоритеты;
д) осуществляется только статическое распределение приоритетов и генерация всех задач, входящих в тест.
В соответствии с приведенными предположениями информация о каждом шаге теста может быть описана данных (пример 1).
В структуре данных поле ТаякМ содержит номер, идентифицирующий тестовую задачу. Поле \JtilServ содержит указатель на функцию, выполняемую на данном шаге теста. Подобная функция либо выполняет некоторые действия с переменными теста (процедура из библиотеки утилит тестирования), либо выполняет вызов базовой функции ОС (процедура вызова сервиса ОС). Поля и Arg_2
используются для представления параметров утилиты тестирования или базовой функции ОС. Поскольку тип аргументов может изменяться от одного оператора к другому, типы аргументов должны задаваться объединением (пример 2).
Здесь следует перечислить все типы аргументов, использующиеся при вызовах утилит тестирования или сервисов ОС.
Организация тестов в виде процессов, управляемых данными
Наиболее удобным путем для быстрой автоматической обработки плоских схем является использование соответствующего интерпретатора плоских схем. В этом случае для каждой задачи должен инициализироваться отдельный экземпляр интерпретатора, а все экземпляры интерпретатора должны выполняться параллельно. При этом каждый экземпляр должен сканировать спецификацию плоской схемы строка за строкой и иметь собственную переменную для указания анализируемого или исполняемого элемента плоской схемы: Тез181ер* Сиггег^ер;.
Тогда i-й экземпляр интерпретатора будет выполнять только те строки плоской схемы, которые относятся к г'-й задаче, а все другие строки будут пропускаться, поскольку они выполняются другими экземплярами интерпретатора.
При таком построении интерпретатора плоских схем должен существовать только один экземпляр тела интерпретатора, а количество экземпляров для выполнения спецификаций плоских схем должно соответствовать количеству задач теста. При этом все задачи должны отличаться номером, который необходимо использовать в качестве параметра при инициализации очередного экземпляра интерпретатора.
Организация теста в виде процессов, управляемых данными, обусловливает важное свойство. В этом случае существует только одна точка, вызывающая в тесте тестируемую ОС - точка, в которой экземпляр интерпретатора вызывает сервисную процедуру или утилиту, указанную в выполняемой строке плоской схемы. Это свойство позволяет существенно упростить разработку измерительных тестов.
Использование плоских схем для разработки тестов и метода управления данными сокращает сроки разработки тестового комплекта и повышает его мобильность (упрощает адаптацию тестового комплекта к различным версиям ОС и платформам, на которые ОС ориентирована), а плата за это невелика. По реальным данным ИДУ размер кода тела интерпретатора плоских схем вместе с библиотекой утилит составляет не более 10 % от размера кода всего тестового комплекта.
Замечание 1. Средства программирования на языке Си не всегда доступны при разработке пользовательских приложений для встроенных ОС реального времени. Часто доступны только средства ассемблера. Если встраиваемая ОС и пользовательские приложения написаны на ассемблере, то и тестовый комплект целесообразно создавать на ассемблере. Это обстоятельство не является препятствием для использования плоских схем, описания которых могут строиться для языка ассемблера с тем же успехом, что и для языка Си.
Замечание 2. Исходная строчная форма представления теста не пригодна для интерпретации в реальном времени. Для устранения этого недостатка следует применить методику, аналогичную Fort-технологии [4]. Представление теста должно быть преобразовано из строчной формы в форму регулярного массива (стандартных макросредств), в котором его элементы должны содержать номер задачи, указатель на вызываемую процедуру и аргументы этой процедуры.
Построение сценарных тестов
В соответствии с требованием направленности функциональных тестов каждый функциональный тест должен проверять конкретное свойство встраиваемой ОС в определенных условиях. Поэтому полноценный тестовый комплект должен включать набор сценарных тестов, характер которых был бы приближен к характеру реальных пользовательских приложений, а каждый сценарный тест должен реализовывать последовательность действий, которая использует ОС в режиме, приближенном к реальному режиму функционирования. Для построения сценарных тестов может с успехом использоваться метод плоских схем.
при помощи структуры
Пример 1
typedef struct Test_Step { int Taskld; void (* UtilServ) (); Step Arg Arg_l; Step Arg Arg_2;
Пример 2
union StepArg { int IntArg; char* String Arg; void (* FunArg) (); //........
В примере 3 приведен массив, который описывает сценарный тест передачи сообщений между четырьмя потоками - тремя задачами и процедурой обработки прерывания и представлен элемент метода плоских схем, который позволяет задавать операции, выполняемые обработчиками прерываний.
Отрицательное число в поле Taskld соответствует оператору, который должен выполняться обработчиком прерываний. В этом случае абсолютное значение Taskld не указывает на какой-то конкретный обработчик прерываний, а задает уровень вложенности прерываний, на котором выполняется данная строка плоской схемы.
Тест MessTravel разработан для проверки разновидности механизма передачи сообщений, обеспечивающего передачу указателя на сообщение из обработчика прерываний в задачу или из одной задачи в другую. Переменные mesl_ptr, mes2_ptr, mes3_ptr в примере используются как указатели сообщений. Значение константы TEST_MESSAGE является указателем на некоторый инициализированный экземпляр сообщений.
Сценарий пересылок сообщений между задачами состоит из следующих событий:
задача Task_l пытается получить сообщение и приостанавливается ввиду его отсутствия (Шаг_01);
обработчик прерываний посылает сообщение TEST_MESSAGE задаче Task_3, которая в этот момент еще не готова его принять (Шаг_02, Шаг_03);
задача Task_2 пытается получить сообщение и приостанавливается ввиду его отсутствия (Шаг_04)\
задача Task_3 получает сообщение TEST_MESSAGE (посланное ранее обработчиком прерываний) и пересылает его задаче Task_l, приостановленной до момента его поступления (Шаг_05, Шаг_0б);
задача Task_l пересылает сообщение задаче Task_2 и освобождает процессор выполнением сервисной процедуры CallTaskEnd( ) (Шаг_07, Шаг_08);
после завершения задачи Task_l сообщение, принятое задачей Task_2, сравнивается с TEST_MESSAGE (Шаг_09), сравниваемые указатели сообщений должны быть идентичны).
Процедура Resumelsr( ) в рассматриваемом примере инициирует вызов обработчика прерываний. Для реализации тела обработчика прерываний порождается эк-
земпляр того же общего интерпретатора, который выполняется для всех задач. Настройка на выполнение обработчика прерываний осуществляется несколькими операторами, предшествующими входу в тело общего интерпретатора.
Организация циклов в плоских схемах
Для построения плоских схем введены вспомогательные элементы. В примере 3 был использован один из таких вспомогательных элементов - разделитель ЕМ_о/_$с}1ете. Еще одна полезная разновидность вспомогательных элементов -это разделитель циклов. Механизм организации циклов введен в плоские схемы для предотвращения появления длинных схем с повторяющимися фрагментами.
В примере 4 показан тест (.Меа()иеие), который проверяет очередь сообщений. Очередь из 10 сообщений в представленном примере формируется для задачи Таяк_2, затем задача Таяк_2 потребляет эти сообщения из очереди одно за другим.
Переменная cycle_var в этом примере используется как переменная цикла. Можно построить вложенные циклы, каждый со своей переменной цикла (например cycle l_var для внешнего цикла и cycle2_var для внутреннего).
Для каждого цикла должно соблюдаться граничное условие, которое заключается в том, что состояние каждой из работающих задач в конце цикла должно совпадать с состоянием этой задачи в начале цикла.
Разработка тестов для проверки обработки ошибок
Пример теста MessTravel демонстрирует возможность применения метода плоских схем при построении тестов для тестирования большинства базовых функций операционной системы. Представленный в примере 3 тест проверяет порядок переключения процессора между различными потоками действий. Тест MessTravel проверяет корректность передачи данных между задачами и между обработчиками прерываний и задачами. Подобным же образом может быть проверено распределение памяти или специальных структур данных и т.д.
Одной из задач функционального тестирования ОС является тестирование механизма обработки ошибок. Плоские схемы приспособлены для решения данной за-
Пример 3
TestStep MessTravel [ ] = {
l,&CallGetMessage,&mesl_ptr,0, // Сообщений нет, Task_l ждет
2,&ResumeIsr,0,0, 11 Моделирование прерывания
-l,&CallPutMessage,TASK_3,TEST_MESSAGE, // Сообщение для Task_3 2,&CallGetMessage,&mes2_ptr,0, 11 Сообщений нет, Task_2 ждет
3,&CallGetMessage,&mes3_ptr,0, 11 Task_3 получает сообщение
3,&CallPutMessage,TASK_l,&mes3_ptr, // Активация задачи Task_l l,&CallPutMessage,TASK_2,&mesl_ptr, // Task_2 готова продолжаться
1 ,&CallTaskEnd,0,0, 11 Процессор отдается Task_2
2,&CheckEqual,&mes2_ptr,TEST_MESSAGE, 11 Совпадают ли указатели ? 2,&End_of_Test,0,0, //TEST_MESSAGE
0,&End_of_scheme,0,0 //
}
Пример 4
Те8151ерМе88(2иеие[ ] = {
// — Очередь из 10 сообщений формируется для задачи Таэк_2 0,&Ьоор81аг1,&сус1е_уаг, 10,
1,&Са11Ри1Ме88а§е,Та8к_2,&те81_р1г, /* Повтор посылки сообщения */
0,&ЬоорЕп(1,&сус1е_уаг,0,
1 ДСаПТавкЕг^ДО, /* Задача Таяк_1 завершается */
// — Очередь из 10 сообщений исчерпывается задачей Таэк_2 0,&Ьоор81аг1,&сус1е_уаг, 10,
2,&Са1Юе1Ме88а§е,&те82_р1г,0, /* Повтор получения сообщения */ 0,&ЬоорЕг^,&сус1е_уагД
С^&Епс^оОсЬетеДО }_
дачи. На следующем примере плоской схемы (пример 5) показано, каким образом достигается эта возможность.
Пример 5
Те8181ерМетКедЕгг[ ] = {
//------Шаги с 81ер_01 до исчерпывают ресурс памяти
1 ,&Ое1Метогу,ЗОДтет_рй:, // Шаг 5гер_г+1
0,&СЬескЕггВа1а,Ш_МЕМ(ЖУА //------Последующие шаги схемы
С^&Епс^оОсЬетеДО ]_
Задача Та$к_1 в этом примере требует 30 блоков памяти, что приводит к возникновению ошибки ввиду недостатка ресурса памяти. Техника тестирования базовой функции обработки ошибок аналогична технике моделирования прерываний с помощью утилиты КештеШ( ). Ошибка должна вызывать специальный поток действий со входом в тело интерпретатора плоской схемы. Интерпретатор находит вспомогательную строку схемы и выполняет утилиту СкескЕггОма( ). Предполагается, что ОС передает код ошибки ЫО_МЕМОЯУ в блок обработки ошибок.
Организация автоматизированных сеансов тестирования
Характерной особенностью встраиваемых ОС является возможность настройки пользователем параметров для выбора необходимого типа эффективности (по скорости, по памяти) и задания набора требуемых базовых функций ОС. Эта возможность приводит к тому, что с ростом числа параметров экспоненциально растет число версий ОС. При этом десятку двоичных параметров соответствует более тысячи различных версий ОС. Вместе с тем для каждой тестируемой версии должен быть построен, загружен и выполнен свой тестовый комплект. В результате общее количество тестов, которые необходимо построить, загрузить и выполнить, может исчисляться миллионами. Отсюда следует необходимость решения задачи создания автоматизированных средств разработки тестов, спецификации и выполнения сеансов тестирования.
Для решения этой задачи в тестовый комплект для встраиваемой ОС необходимо включать средства: автоматизированного построения тестов, загрузки тестов в целевое устройство и автоматического исполнения тестов. Автоматизированные средства должны предоставлять возможность организации специфицированного сеанса тестирования. Спецификация сеанса тестирования должна включать список действий по построению, загрузке и выполнению необходимых тестов.
Существуют, по крайней мере, еще две причины, которые приводят к необходимости автоматизации сеансов тестирования встраиваемых ОС - это перспективы модернизации ОС и перспективы их переноса на новые процессоры (микроконтроллеры).
Всякий раз после внесения изменений в ОС необходимо проведение регрессионного тестирования (даже после внесения в ОС незначительных усовершенствований). Тестирование усовершенствованной ОС не должно требовать больших затрат, для сокращения которых используется автоматизация сеансов тестирования.
В случае переноса ОС на новый процессор необходимо выполнить аналогичный перенос тестового комплекта. Перенос должен требовать значительно мень-
ших затрат, чем его разработка. Использование метода плоских схем в высокой степени способствует сокращению трудоемкости переноса тестового комплекта на другие версии ОС и типы процессоров.
Измерение покрытия тестовым комплектом программного кода ОС
Общепринятая техника измерения покрытия тестовым комплектом кода тестируемой ОС основывается на непосредственном отслеживании передачи управления в коде ОС. Техника непосредственного отслеживания отвечает требованию невмешательства и поддерживается специальными программно-аппаратными средствами. Аппаратную часть составляет механизм трассировочных прерываний со специально выделенным вектором (ГЛ4Р-прерывания). Программную часть составляет обработчик пошаговых прерываний, выполняющий в этом случае роль программы-трассировщика. Выполнение каждой инструкции ОС предваряется прерыванием по Г&4.Р-вектору, что приводит к очередному запуску обработчика пошаговых прерываний.
В случае встраиваемых ОС техника непосредственного отслеживания может оказаться неприменимой из-за того, что при выполнении встроенного пользовательского приложения совместно с программой-трассиров-щиком система будет работать значительно медленнее, чем в случае реальной работы, и некоторые операторы, быстро работающие в случае реального выполнения, могут быть недостижимы при измерении покрытия кода тестируемой ОС.
Более подходящая техника измерения покрытия кода тестируемой ОС для встроенных пользовательских приложений базируется на механизме использования кодов запрещенных команд. Для реализации этого механизма также используются специально выделенный вектор прерываний (вектор прерываний по запрещенной команде). Роль программы-трассировщика здесь выполняет обработчик прерываний по запрещенной команде. Процесс измерения покрытия в таком случае состоит из следующих шагов.
Шаг 1. Область памяти, занимаемая телом ОС, замещается кодами запрещенных команд. Перед замещением первоначальное содержимое области памяти (коды инструкций ОС) сохраняется в специальном массиве для последующего восстановления.
Шаг 2. Выполняется тест. Поскольку область памяти, отведенная под тело ОС, занята кодами запрещенных команд, при обращении к ОС возникает программное прерывание по запрещенной команде.
Шаг 3. В результате прерывания выполняется про-грамма-трассировщик, которая восстанавливает (из специального массива) необходимый код инструкции ОС и передает управление на восстановленную инструкцию.
Шаг 4. Выполняется восстановленная инструкция
ОС.
Шаг 5. Если после выполнения восстановленной инструкции ОС счетчик команд указывает адрес очередной инструкции из тела ОС, то возможен один из двух вариантов: очередная инструкция еще не восстановлена или она уже восстановлена. В первом случае очередной раз срабатывает прерывание по запрещенной команде с восстановлением еще одной инструкции из тела ОС.
По мере выполнения теста восстанавливается все большее число инструкций ОС. После завершения теста будут восстановлены все те инструкции ОС, которые потребовались для работы этого теста. Число обращений к программе-трассировщику будет равно числу восстановленных инструкций.
Техника измерения покрытия по кодам запрещенных команд уменьшает (по сравнению с техникой непосредственного отслеживания) время выполнения теста при измерении покрытия. Каждой инструкции ОС соответствует не более одного обращения к программе-трассировщику. В результате темп выполнения теста в режиме измерения покрытия становится более приближен к темпу выполнения встроенного пользовательского приложения в обычном режиме (без программы-трассировщика).
Полное соответствие темпа выполнения встроенного приложения в режиме измерения покрытия кода тестируемой ОС темпу обычного режима работы встроенного приложения достигается в случае применения техники с замещением единственной инструкции ОС. В этом случае последовательность шагов выглядит так.
Шаг 1. В теле ОС выбирается единственная инструкция, относительно которой необходимо выяснить, покрывается ли она тестом. Лишь эта инструкция замещается кодом запрещенной команды.
Шаг 2. Тест выполняется с начала до конца. Если по завершении теста инструкция не восстановлена, то она не покрывается данным тестом.
Применение техники с замещением единственной инструкции требует значительных расходов машинного времени, поскольку полное измерение покрытия кода ОС требует повторных выполнений теста (или всего тестового комплекта) столько раз, сколько имеется инструкций в теле ОС.
В заключение выделим наиболее важные свойства метода плоских схем.
1. Применение метода плоских схем обусловливает повышение эффективности разработки и исполнения тестовых комплектов для встраиваемых ОС.
2. Использование плоских схем позволяет создавать хорошо обозримые описания тестов, содержащих спецификации параллельно выполняемых задач и обработчиков прерываний.
3. Метод плоских схем пригоден для проверки корректности реализации базовых функций ОС (передачи данных и сигналов между потоками действий, динамического распределения ресурсов памяти, специальных структур, процессорного времени).
4. Плоские схемы пригодны не только для построения функциональных тестов, их применение эффективно также для локальных и глобальных измерений времени, для измерения характеристик реактивности ОС.
5. На основе плоских схем могут быть построены стандартные тестовые комплекты для тестирования базовых функций встраиваемых ОС.
Список литературы
1. Kazara E.J. Real-time debugging with embedded operating systems. Embedded Systems Programming, vol.7, no.8, Aug 1994, pp.24-32.
2. Liband 1., Blakeslee T.R. Technique for real-time debugging. Proc. of the Fifth Annual Embedded Systems Conference, Santa Clara, CA, USA, 5-8 Oct 1993 (San Francisco, CA, USA: Miller Freeman, 1993), v.2, pp. 121 -138.
3. Mandrioli D., Morasca S., Morzenti A. Functional test case generation for real-time systems. Dependable Computing for realtime applications 3, Mondello, Italy, 14-16 Sept 1992 (Wien, Austria: Springer-Verlag 1993), pp.29-61.
4. Schach S. Testing: principles and practice. ACM Computer Survey, vol. 28, no. 1, Mar 1996 pp.277-279.
5. Myers G.I. The art of software testing. NY, USA, lohn Wiley & Sons, 1979, 177 p.
6. Watkins A. The automatic generation of test data using genetic algorithms. Proc. of the 4th Software Quality Conference, Dundee, UK, 4-5 luly 1995 (Dundee, UK: University of Abertay Dundee, 1995), v.l.
7. Баранов C.H., Домарацкий A.H., Ласточкин H.K., Морозов В.П. Предотвращение дефектов при создании программных изделий. //Программные продукты и системы. - 1998. -№2. - С.2-6.
МОДУЛЬНОЕ ТЕСТИРОВАНИЕ ОПЕРАЦИОННОЙ СИСТЕМЫ
РЕАЛЬНОГО ВРЕМЕНИ
Я.А. Домарацкий
Тестирование операционной системы (ОС) реального времени имеет свои особенности, которые необходимо учитывать при организации как модульного, так и интеграционного тестирования, тестирования работоспособности и системного тестирования. Настоящая статья посвящена описанию организации только модульного тестирования ОС реального времени, хотя многие принципы его организации пригодны и для организации других видов тестирования.
Модульное тестирование ОС реального времени предназначено для выявления дефектов в тестируемом модуле с их обязательным последующим устранением и для подтверждения правильности выполнения спецификаций проектирования этим модулем ОС. Тестирование любого модуля ОС выполняется отдельно, независимо от других модулей. Оно осуществляется разработчика-
ми ОС на этапе отладки (см. с. 30-33 наст. ном. журн.). Существует стандарт по проведению модульного тестирования [1].
При организации модульного тестирования предполагается, что при проектировании все функции ОС логически разделены на компоненты. Каждому компоненту ставится в соответствие программный модуль ОС. Под программным модулем ОС подразумевается минимальная часть ОС, которая имеет спецификацию, описывающую реакцию этого модуля на определенное входное воздействие. Далее ставится задача тестирования каждого компонента отдельно, независимо от других компонентов.
На этапе модульного тестирования ОС для каждого модуля системы и его спецификации необходимо создать соответствующий набор тестов. При этом допуска-
