CC BY
36
нарий тестирования (последовательность переходов между различными состояниями системы в ходе исполнения теста). Из-за отсутствия полной сборки ОС на этапе модульного тестирования подобный автоматически сгенерированный код пользовательского приложения должен быть дополнен вручную отсутствующими элементами, реализующими функции воздействия на систему и пользовательские объекты. Таким образом, применение средств моделирования, использующих формальные модели будущей системы, позволяет осуществить частичную автоматизацию процесса разработки модульных тестов. Заметим, что подобные средства автоматизации являются весьма дорогостоящими, поэтому пока нам не удалось их использовать.
Обратим внимание на то, что модульное тестирование ОС реального времени выполняется в группе разработчиков и является важным этапом отладки ОС. Чем больше дефектов, имеющихся в модулях, будет выявлено и устранено при выполнении модульного тестирования, тем легче будет протекать процесс дальнейшей отладки ОС в целом (процесс интеграционного тестирования и тестирования работоспособности), тем более высокий уровень качества будет иметь при поставке
разрабатываемая ОС. Поэтому главной задачей модульного тестирования является отыскание и устранение дефектов в отдельных модулях ОС, а для выполнения этой задачи следует иметь набор простых и коротких модульных тестов.
Список литературы
1. IEEE 1008. ANSI/IEEE 1008 - 1987 (Software Unit Testing).
2. Glenfor J. Myers. "The Art of Software Testing", John Wiley & Sons, 1979.
3. Specialist Interest Group on Software Testing: Standard for Software Component Testing, Working Draft 3.1 Date: 16 July 1996.
4. Harel D. "Statecharts: A Visual Formalism for Complex Systems," Sci. Computer Prog., July 1987, pp. 231-274; also see Tech. Report CS84-05, The Weizmann Inst, of Science, Rehovot, Israel, 1984.
5. Harel D. and Politi M. Modeling Reactive Systems with Statecharts, McGraw-Hill, New York (to be published); for abridged version, see The Languages of STATE-MATE, tech. report, i-Logix, Andover, Mass., 1991.
6. Harel D. et al. "STATEMATE: A Working Environment for the Development of Complex Reactive Systems," IEEE Trans. Soft. Eng., Apr. 1990, pp. 403-414.
СИСТЕМНОЕ ТЕСТИРОВАНИЕ ПРОГРАММНЫХ ИЗДЕЛИЙ
В.В. Никифоров, Я.А. Домарацкий
Тестирование является неотъемлемой частью разработки любого компонента программного изделия (ПИ), а системное тестирование - это завершающая фаза жизненного цикла разработки ПИ. Процесс тестирования в коллективах, занимающихся разработкой ПИ, может быть организован разными способами. Однако любой процесс тестирования должен быть направлен на выполнение главной цели, которая состоит в обнаружении дефектов в тестируемом объекте, выявлении расхождений между спецификациями проектирования и требованиями к ПИ и его реальным поведением. (Разделение обязанностей по осуществлению тестирования между разработчиками и тестировщиками описано на с. 30-33 наст. ном. журн). Авторы предлагают вниманию читателей описание процесса системного тестирования, принятое в ИДУ.
Работы по тестированию ПИ разделены между разработчиками ПИ и группой системного тестирования. Разработчики ПИ выполняют модульное тестирование, интеграционное и тестирование работоспособности ПИ. Системное тестирование выполняется в отдельной группе, которая названа группой системного тестирования (ГСТ).
ГСТ не участвует в разработке кода ПИ и пользовательской документации, а занимается только системным тестированием готовой версии ПИ. Главной целью системного тестирования является обнаружение дефектов в готовой версии ПИ и выявление расхождений между требованиями заказчика к ПИ и реальным поведением ПИ при его работе (подтверждение соответствия реального поведения ПИ требованиям заказчика).
Для этого в ГСТ разрабатывается комплекс системных тестов (тестовый комплект), который должен представлять собой совокупность программ и документов,
необходимых и достаточных для обеспечения выявления дефектов в программных кодах ПИ и пользовательской документации, для обнаружения и документирования расхождений между требованиями заказчика к ПИ и его реальным поведением.
В ИДУ для каждого проекта по разработке ПИ из состава ГСТ выделяется ответственный системный тес-тировщик, который начинает работы по системному тестированию непосредственно после утверждения "Положения о работе" для данного проекта ПИ. Он получает доступ к любой информации по проекту тестируемого ПИ, в том числе к исходным кодам ПИ в дальнейшем. Это обусловливает более эффективную и целенаправленную работу системного тестирования. По результатам ознакомления с требованиями заказчика к ПИ системный тестировщик проверяет каждое требование на возможность его тестируемости.
ГСТ начинает свою работу по созданию тестового комплекта для ПИ с составления плана системного тестирования сразу после утверждения требований заказчика к нему. Приведем перечень основных материалов, создаваемых в ходе разработки тестового комплекта и выполнения циклов системного тестирования, который принят в ИДУ в качестве обязательного. В перечень входят:
• план системного тестирования, основой которого являются утвержденные требования заказчика к ПИ и проектный план разработки ПИ;
• процедуры системного тестирования - документы, описывающие порядок выполнения тестов, обеспечивающие требуемую последовательность запуска системных тестов и критерии их успешного завершения (в процедурах системного тестирования необходимо также
приводить подробные описания запуска неавтоматизированных тестов);
• матрица покрытия требований, в которой каждому требованию заказчика поставлены в соответствие один или несколько тестов из тестового комплекта;
• автоматизированный тестовый комплект - совокупность текстовых (на принятом языке программирования), загрузочных и других файлов, обеспечивающих выполнение операций автоматизированного системного тестирования ПИ (в тестовом комплекте могут быть тесты, выполняемые вручную);
• отчет о результатах системного тестирования, выполненного на основе использования автоматизированного тестового комплекта в соответствии с процедурами системного тестирования (включая тесты, выполняемые вручную).
Разработка тестового комплекта. ГСТ занимается разработкой автоматизированного тестового комплекта для ПИ в соответствии с составленным для этого ПИ планом системного тестирования. Тестовый комплект должен покрывать все требования заказчика к ПИ. Для этого ответственный системный тестировщик должен работать совместно с разработчиками, чтобы удалить все нетестируемые требования и обеспечить возможность покрытия на 100 % всех требований заказчика к ПИ (пример нетестируемого требования: интерфейс должен быть дружественным).
Большинство тестов, входящих в состав тестового комплекта, должно выполняться в автоматическом режиме, за исключением тестов для проверки тех требований, проверка которых в автоматическом режиме невозможна или нецелесообразна.
План системного тестирования и проектный план разработки ПИ должны быть согласованными. Это означает, что основные вехи разработки тестового комплекта согласуются по срокам с вехами разработки ПИ. При этом целесообразно, чтобы завершение разработки тестового комплекта планировалось в те же сроки, что и завершение отладки текущей версии ПИ.
Покрытие кода тестируемого ПИ. Одной из косвенных характеристик полноты тестового комплекта является коэффициент покрытия кода тестируемого ПИ, который представляет собой отношение числа строк кода ПИ, достигаемых в ходе выполнения тестового комплекта, к общему числу строк кода ПИ. Для полноценного тестового комплекта величина коэффициента покрытия кода должна быть не менее заданного значения в требованиях заказчика к ПИ. В ИДУ принято, что этот коэффициент должен быть не менее 0.75.
Вехи системного тестирования. Ответственный системный тестировщик должен определить вехи системного тестирования ПИ, которые утверждаются руководителями проектной группы и ГСТ. Утвержденные вехи должны быть включены в соответствующий план системного тестирования. Обязательными вехами являются: окончание работ по разработке плана системного тестирования, разработке набора тестов для каждой функциональной компоненты, определенной в требованиях заказчика к ПИ; окончание составления тестовых процедур; завершение каждого из запланированных циклов системного тестирования.
Циклы системного тестирования - это деятельность системных тестировщиков по проверке ПИ между моментом, когда разработчики предоставляют версию
ПИ для системного тестирования и моментом представления ГСТ разработчикам отчета о выполненном системном тестировании. Продолжительность цикла системного тестирования, принятого в ИДУ, не должна превышать одного месяца. Циклы тестирования обязательно должны планироваться в соответствии с вехами программной разработки, указанными в проектном плане ПИ. Последний цикл системного тестирования часто называют выходным тестированием.
Входными данными для каждого цикла системного тестирования в соответствии с порядком, принятым в ИДУ, являются: комплект инсталляционных файлов ПИ (дискет); отчеты о модульном и интеграционном тестировании, о тестировании работоспособности; отчет руководителя проекта о сборке версии ПИ; журнал тестирования.
В перечень выходных данных цикла системного тестирования входят: отчет о системном тестировании, включающий в себя описание тестового комплекта, сам тестовый комплект и результаты тестирования; журнал тестирования, содержащий записи осуществленных в хронологическом порядке действий при выполнении циклов тестирования; отчет об инцидентах системного тестирования. Под инцидентом системного тестирования понимается зафиксированное в базе данных дефектов системным тестировщиком отклонение хода выполнения системного теста от ожидаемого. Истинной причиной такого отклонения может быть как дефект в ПИ, так и дефект в самом тесте.
Для выполнения цикла системного тестирования предварительно необходимо определить требуемые ресурсы для его проведения (например количество тести-ровочных машин, их конфигурация). В ходе выполнения цикла системного тестирования выполняются автоматизированные и неавтоматизированные инсталляционные и функциональные тесты; проверяется устранение дефектов, обнаруженных на предыдущем цикле системного тестирования; составляется и передается разработчикам ПИ отчет об инцидентах системного тестирования; регистрируются дефекты, обнаруженные в самом тестовом комплекте. Непосредственно после выполнения этих действий начинается подготовка к следующему циклу тестирования. При этом исправляются обнаруженные дефекты в тестовом комплекте, составляются новые тесты, требуемые для выполнения последующего цикла тестирования.
Разновидности системного тестирования. Тестовый комплект для системного тестирования должен включать в свой состав столько видов тестов, сколько необходимо для выполнения главной задачи тестирования: инсталляционные тесты, функциональные, сценарные, тесты производительности, граничные, тесты проверки взаимодействия ПИ со средой и проверка документации. Кроме того, могут выполняться специальная проверка на соответствие ПИ принятым стандартам и другие проверки для подтверждения полного соответствия ПИ требованиям заказчика. В соответствии с набором видов тестов в тестовом комплекте различают и виды системного тестирования.
Инсталляционное тестирование позволяет убедиться в корректности работы средств установки ПИ на машине заказчика. При этом проверяется корректность представления логотипа организации, выполнившей разработку ПИ, наименований ПИ и его версии; уточня-
ется, имеет ли носитель в нужном месте правильную этикетку и есть ли на ней и на экране инсталляции пометка о праве копирования; может ли пользователь выбрать место во внешней памяти, куда произвести инсталляцию, и может ли он при желании быстро отменить инсталляцию; имеются ли в наличии все файлы, определенные как поставочные; устанавливается ли ПИ на всех требуемых операционных системах; имеется ли файл "readme" и соответствующая ему иконка; имеется ли иконка деинсталляции; правильно ли указано лицензионное соглашение; правильно ли в экране "about" указаны пометка о праве копирования, название продукта и номер его версии; правильно ли представлена эмблема ПИ, если таковая существует.
Функциональное тестирование. Осуществление функционального тестирования обеспечивает проверку соответствия ПИ требованиям к нему. Для обеспечения эффективного выполнения операций регрессионного тестирования комплект функциональных тестов должен быть автоматизированным, покрывать 100 % функциональных требований к ПИ и не менее 75 % строк его кода. Для ПИ, предоставляющих пользователю большое разнообразие функциональных возможностей, целесообразно применение специфических разновидностей функциональных тестов, а именно: монокомпонентных, мультикомпонентных и конфигурационных.
Функциональные компоненты ПИ. Если ПИ предоставляет пользователю большое разнообразие функций, то эти функции обычно разбиваются на группы, классы. Так, например, ПИ типа ядра ОС реального времени может обеспечивать выполнение функций следующих классов: управление передачей сообщений, управление памятью, управление событиями, управление ресурсами. Каждый из таких классов объединяет некоторое подмножество логически связанных функций ПИ и может рассматриваться как его отдельный функциональный компонент.
Разбиение множества функций на компоненты способствует упорядочению структуры тестового комплекта. Для целей функционального тестирования неважно, в какой мере структурирование множества функций повторяет внутреннюю структурную организацию ПИ. Разбиение множества функций на компоненты не обязательно должно каким-то образом соответствовать разбиению ПИ на составляющие его подсистемы.
Монокомпонентные и мультикомпонентные тесты. Компонентный тест обычно строится для проверки выполнения отдельной функции (например функции, принадлежащей компоненту А). Однако это не всегда возможно, зачастую приходится строить тесты, проверяющие выполнение двух или более связанных функций. Так, например, при тестировании функционального компонента "управление передачей сообщений" функции "передача сообщений" и "прием сообщений" приходится тестировать совместно. В данном случае обе функции ПИ, используемые в тесте, принадлежат одному и тому же функциональному компоненту. Тест, направленный на проверку правильности выполнения действий, соответствующих отдельному функциональному компоненту, является монокомпонентным.
Если при работе теста используются функции из различных функциональных компонентов ПИ, тест является мультикомпонентным. Мультикомпонентные тесты проверяют работоспособность ПИ при совмест-
ном использовании различных функциональных компонентов. К построению таких тестов прибегают либо тогда, когда для проверки каких-то функций системы невозможно построить монокомпонентный тест, либо тогда, когда необходимо проверить работоспособность ПИ при комбинированном использовании различных функциональных компонентов.
При построении тестового комплекта следует максимально использовать возможности построения монокомпонентных тестов. В хорошо структурированном тестовом комплекте подавляющая часть функциональных требований покрывается монокомпонентными тестами.
Конфигурационные тесты. В случае если ПИ предоставляет пользователю возможность оперативного выбора требуемой ему функциональной конфигурации, возникает необходимость построения тестов, проверяющих работоспособность различных конфигураций ПИ. Для каждой тестируемой конфигурации необходимо проверить правильность выполнения всего набора соответствующих ей функций.
Сценарное тестирование. Структура и порядок выполнения функциональных тестов, как правило, существенно отличаются от структуры пользовательских приложений, от типичного порядка работы пользователя с ПИ. Это вызывается тем, что функциональные тесты, не предназначены для решения каких-то конкретных прикладных задач. Каждый отдельный функциональный тест предназначен лишь для проверки выполнения некоторого конкретного требования к ПИ.
Когда необходимо проверить работу ПИ в условиях его эксплуатации, следует использовать сценарные тесты. Тесты этой разновидности разрабатываются таким образом, чтобы их структура и порядок (сценарий) их выполнения соответствовали структуре пользовательских приложений, порядку (сценарию) работы пользователя с данным ПИ. Основу сценарного теста может составить реальное пользовательское приложение, ориентированное на использование данного ПИ.
Тестирование количественных характеристик ПИ, стрессовое тестирование. В состав требований к ПИ могут включаться количественные характеристики. К ним относятся величины пределов времени выполнения тех или иных функций, времени реакции на внешние события (характеристики производительности ПИ), величины предельно допустимых объемов для пользовательских объектов, например полей, записей, числа задач, буферов, сообщений и т.п. (характеристики пропускной способности). Тестовый комплект должен содержать группы тестов производительности и пропускной способности, проверяющих соответствие реальных значений количественных характеристик имеющимся в требованиях к ПИ. Стрессовые тесты проверяют устойчивость работы ПИ в условиях предельно допустимых нагрузок по производительности и пропускной способности.
Тестирование взаимодействия продукта со средой. Нормальная работа ПИ не должна сопровождаться такими вредными эффектами, как утечка памяти, некорректная работа с файлами (например файлы остаются открытыми после завершения работы приложения), некорректная работа с буферами (например буферы не освобождаются после завершения работы приложения). В
ходе системного тестирования должны выполняться проверки отсутствия таких вредных эффектов.
Тестирование документации. Документация, входящая в поставку программного продукта, должна проверяться по следующим позициям: изложение содержания разделов должно быть ясным, исключающим неоднозначное толкование; инструкции пользователя ПИ должны быть однозначными и полными, точно соответствующими реальному поведению ПИ; все примеры, приведенные в документации, должны работать в соответствии с описанием; Документ должен быть выполнен в соответствии со стандартами организации и правильно распечатан (правильное оглавление, нумерация страниц и т.д.); должна присутствовать пометка о праве копирования. В зависимости от требований к продукту могут понадобиться другие проверки.
Выходное тестирование осуществляется после устранения всех дефектов, обнаруженных на предшествующих циклах системного тестирования и является завершающим этапом системного тестирования. Это тестирование определяет готовность ПИ к поставке.
Метрики системного тестирования. В соотиет-ствии с "Метрической программой", принятой в ИДУ (см. с. 24-29 наст. ном. журн.), во время фазы "Системное тестирование" осуществляется сбор и анализ установленных метрик. Руководитель ГСТ, как и все руководители проектных групп, подготавливает еженедельные, двухнедельные и месячные метрические отчеты, регулярно выступает на еженедельных семинарах и ежемесячных оперативных обзорах с докладами о прогрессе в системном тестировании ПИ и о том, что сделано по плану системного тестирования за прошедший месяц и о планах на следующий.
Однако разработка автоматизированного тестового комплекта для системного тестирования и выполнение циклов тестирования ПИ обладает своей спецификой и требует значительных трудозатрат, которые обязательно следует учитывать при планировании работ по разработке ПИ.
При определении оценки трудоемкости системного тестирования при подготовке плана системного тестирования необходимо определить оценку размера кода тестового комплекта. Для этого следует использовать сведения о типе и размере кода тестируемого ПИ, сведения о размерах кодов готовых тестовых комплектов для тестирования аналогичных ПИ. Целесообразно также принимать во внимание трудоемкость создания тес-
Таблица
Метрики ПП и тестового комплекта для различных проектов
Базовые метрики Системы обработки тек- реального времени Системы моделирования
Объем ПИ (КАЕШС) 600 70 800
Трудоемкость разработки ПИ (человеко-недель) 300 150 300
Объем ТК (КАЕШС) 400 30 250
Число тестов 3000 5000 2000
Трудоемкость разработки ТК (человеко-недель) 40 50 45
тируемого ПИ, поскольку трудозатраты на создание полноценного тестового комплекта обычно коррелиро-ваны с трудозатратами на создание тестируемого ПИ. В •Этой связи представляется интересным знакомство с метриками реальных проектов ПИ, выполнявшихся в ИДУ в течение трех лет (см. таблицу).
Для визуального обзора и повышения скорости сравнения трудозатрат по разработке тестовых комплектов для различных проектов ПИ целесообразно их представление в графической форме. На рисунке показан пример такого представления. Очевидно, что имеются значительные отличия значений метрик для тестовых комплектов групп проектов ПИ, выделенных в таблице.
Заметим, что руководители проектов ПИ нередко недооценивают трудоемкость системного тестирования, отводя для него сжатые сроки выполнения. От этого обязательно пострадает не только качество проведения системного тестирования, но и качество поставляемого ПИ. Надлежащий порядок в отношении системного тестирования может быть установлен, если ГСТ будет настаивать на том, чтобы системное тестирование не признавалось законченным до тех пор, пока не будут удовлетворяться все критерии успешного завершения системного тестирования.
Напомним, что системному тестированию подвергаются как программные средства, так и соответствующая Документация. Между этими объектами системного тестирования не должно быть расхождений, а все вместе они должны соответствовать требованиям заказчика к ПИ.
Отметим, что ГСТ дает разрешение на выпуск ПИ или как-то иначе определяет его дальнейшую судьбу. Если ГСТ приходит к выводу, что продолжение системного тестирования не приведет к принятию решения о выпуске ПИ, то она должна согласовать свои дальнейшие действия с администрацией и представителями всех
Отношение нового кода тестового комплекта к трудоемкости его разработки
4.0
3.0 2.0 1.0
Л
Отношение размера кода тестового комплекта к размеру кода ЦИ
0.4
0.3 0.2 0.1
Отношение трудоемкости разработки тестового комплекта к трудоемкости разработки ПИ
0.4
0.3 0.2 0.1
ВС ABC А В
Различия метрических данных по группам проектов. А - системы обработки текстов, В - ядра ОС, С - системы моделирования
групп, участвующих в разработке ПИ. Во всех других случаях ГСТ должна рекомендовать выпуск ПИ, даже
если в нем имеются дефекты.
ПОСТРОЕНИЕ ТЕСТОВ ДЛЯ БАЗОВЫХ ФУНКЦИЙ ВСТРАИВАЕМЫХ
ОПЕРАЦИОННЫХ СИСТЕМ
В.В. Никифоров, Я.А. Домарацкий
Встраиваемые операционные системы (ОС), как правило, являются мультизадачными. Полный состав функциональных возможностей и характеристики таких ОС определяются сферой реального применения и архитектурой аппаратных средств, для которых они разрабатываются. Вместе с тем существует некоторое базовое подмножество функций, реализация которых является непременным условием разработки полноценной ОС реального времени, ориентированной на поддержку пользовательских приложений.
Базовые функции встраиваемых ОС и задачи их тестирования
Предоставляемые пользователю функциональные возможности встраиваемой ОС подразделяются на статические и динамические.
Статические возможности ОС реализуются при подготовке прикладной программной системы на инструментальной ЭВМ. К этим возможностям ОС относятся возможности статического порождения множества прикладных задач и обработчиков прерываний, возможности включения в состав приложения необходимых библиотечных функций ОС, настройка основных параметров прикладных задач, статическое распределение ресурсов между прикладными задачами (ресурсов памяти, стеков, специальных структур данных).
Динамические функциональные возможности ОС реализуются в реальном времени в ходе работы программного приложения на целевом оборудовании. К базовым динамическим функциям встраиваемых ОС относятся: динамическое распределение между задачами таких ресурсов, как память, специальные структуры данных, процессорное время; обмен сигналами и данными между задачами; передача сигналов и данных задачам от обработчиков прерываний; обработка исключительных ситуаций.
Различные ОС могут иметь дополнительные базовые функции, такие как динамическое порождение задач, динамическая модификация основных параметров задач (например приоритет задачи), динамическое перемещение стеков задач, математические вычисления, обработка текстов, доступ к периферийным устройствам и т.д.
В настоящей статье рассматриваются вопросы тестирования базовых функций встраиваемых ОС с двух точек зрения. Во-первых, с точки зрения проверки логической корректности выполнения базовых функций ОС (функциональное тестирование), во-вторых - с точки зрения измерения времени, требуемого для выполнения отдельных базовых функций ОС.
Задачи функционального тестирования состоят из проверки исполнения базовых функций ОС путем вызова их из задач и обработчиков прерываний, своевременности переключения процессора между задачами, свое-
временности и безошибочности передачи сигналов и данных, а также преднамеренного создания исключительных ситуаций с целью проверки правильности их обработки.
Задачи измерения времени включают в себя организацию локальных измерений, характеризующих выполнение отдельных функций ОС; глобальных измерений, характеризующих общее время выполнения эталонных приложений; измерений реактивности системы, обусловливающей оценку времени между моментом возникновения прерывания и моментом входа в соответствующий обработчик прерываний.
Среди требований к встраиваемым ОС типичным является требование масштабируемости. Это означает наличие в ОС средств, предоставляющих пользователю возможности генерации такой конфигурации ОС, которая обладала бы требуемыми конкретными свойствами. Требуемая конфигурация задается комбинацией значений конфигурационных признаков. Росту количества конфигурационных признаков соответствует экспоненциальный рост числа возможных конфигураций ОС. Каждая из сгенерированных конфигураций ОС должна предоставлять прикладным задачам пользователя тот сервис, который соответствует связанному с ним набору конфигурационных признаков.
Требования к тестовым комплектам для тестирования встраиваемых ОС [1]: каждый тест должен быть нацелен на проверку конкретного требования к тестируемой базовой функции ОС; выполнение каждого теста должно начинаться при некотором стандартном состоянии тестируемой ОС; после завершения теста тестируемая ОС должна приводиться в некоторое стандартное состояние; ход выполнения каждого отдельного теста не должен зависеть от хода выполнения других тестов.
В случае тестирования встраиваемой ОС следует выполнять реинициализацию системы перед выполнением каждого теста. Такой подход с наибольшей надежностью обеспечивает независимость тестов и идентичность условий их запуска. В этих условиях каждый тест должен представлять собой полное мультизадачное приложение, выполнение которого разбивается на несколько фаз, а именно: фазу перезапуска ОС с инициализацией всех системных структур данных и состояния аппаратных интерфейсов, поддерживаемых тестируемой ОС; фазу инициализации глобальных структур данных теста и структур данных, контролируемых отдельными задачами и обработчиками прерываний; фазу перевода задач, составляющих тест, в состояние, обеспечивающее проверку тестируемой функции ОС; фазу регистрации результатов выполнения теста и перезапуска (реинициализации) системы для выполнения следующего теста.
Тестовый комплект должен обеспечивать проверку работоспособности ОС в произвольной конфигурации.
