Software & Systems

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

Модульное тестирование ОС реального времени предназначено для выявления дефектов в тестируемом модуле c их обязательным последующим устранением и для подтверждения правильности выполнения спецификаций проектирования этим модулем ОС. Тестирование любого модуля ОС выполняется отдельно, независимо от других модулей. Оно осуществляется разработчиками ОС на этапе отладки (см. с. 30-33 наст. ном. журн.). Существует стандарт по проведению модульного тестирования [1].

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

На этапе модульного тестирования ОС для каждого модуля системы и его спецификации необходимо создать соответствующий набор тестов. При этом допускается использование метода "белого ящика" [2], то есть при разработке модульных тестов можно использовать не только информацию о модуле, полученную на основе его спецификации, но и информацию о внутренней структуре ОС, а также знание исходного кода тестируемого модуля. Для этого необходимо осуществить анализ требований к компоненту функций ОС, анализ архитектуры поставленного в соответствие этому компоненту модуля ОС и проанализировать спецификации проектирования. Модульное тестирование часто соприкасается с компонентным тестированием [3].

Разработка списка тестов для модульного тестирования

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

Разработка списка тестов на основе анализа спецификаций проектирования

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

Анализ граничных условий. Метод основывается на принципе разбиения входных воздействий и выходных реакций по принципу нахождения в определенном интервале. Такое разбиение получается на основе выделения ограниченных интервалов значений для входных воздействий и реакций. Каждое разбиение должно содержать набор значений, попадающих в один интервал. Примером подобного разбиения может служить разбиение всего набора входных воздействий для директивы "послать сообщение" на следующие классы: послать сообщение, длина которого находится в пределах одного машинного слова; послать сообщение, длина которого находится в пределах двух машинных слов; послать сообщение, длина которого превышает два машинных слова. Для каждого интервала воздействий обычно достаточно проверить три значения: граничные значения и некоторое среднее значение. Список тестов создается для проверки каждого из выделенных интервалов входных воздействий и реакций.

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

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

Составление списка тестов на основе анализа программного кода модуля

Тестирования элементов исполняемого кода модуля. Этот метод предполагает анализ исходного кода и выделение исполняемых элементов. Задача составления списка тестов состоит в получении максимального покрытия тестами исполняемых элементов программного кода модуля.

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

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

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

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

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

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

Разработка списка тестов на основе построения модели системы. Этот метод позволяет упростить процесс создания списка тестов за счет автоматического анализа модели системы. При использовании такого метода необходимо построить формальную модель системы в терминах конечного автомата [4]. Подобная модель может быть неполной, поскольку не требуется окончательной детализации. Задача построения модели системы в терминах конечного автомата требует выделения набора состояний системы и описания возможных переходов между состояниями. Под состоянием системы подразумевается определенное, обособленное, ортогональное условие, которое удерживается некоторый промежуток времени [5]. Переходы между состояниями системы отражают реакцию системы на наступление событий, вызванных внешними или внутренними источниками, и влекут за собой выполнение определенных действий. Современные программные средства, предназначенные для проектирования сложных систем, позволяют осуществить моделирование поведения системы после построения ее модели в терминах конечного автомата [6]. На основе построенной модели и результатов моделирования возможно автоматическое выделение наборов исходных состояний и воздействий на систему, которые служат основой для создания списка тестов на этапе модульного тестирования.

Реализация тестов на этапе модульного тестирования

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

Требования к реализации модульных тестов:

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

б) естественность – модульный тест не должен управляться данными реального приложения;

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

г) изолированность – модульный тест должен проверять только один компонент (и никак не должен затрагивать остальные), допускать возможность исполнения при тестировании неполной системы, состоящей из усеченного набора компонентов;

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

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

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

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

Способы реализации модульных тестов

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

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

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

1.1.1.1.2.Список литературы

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.