CC BY
37
По мере выполнения теста восстанавливается все большее число инструкций ОС. После завершения теста будут восстановлены все те инструкции ОС, которые потребовались для работы этого теста. Число обращений к программе-трассировщику будет равно числу восстановленных инструкций.
Техника измерения покрытия по кодам запрещенных команд уменьшает (по сравнению с техникой непосредственного отслеживания) время выполнения теста при измерении покрытия. Каждой инструкции ОС соответствует не более одного обращения к программе-трассировщику. В результате темп выполнения теста в режиме измерения покрытия становится более приближен к темпу выполнения встроенного пользовательского приложения в обычном режиме (без программы-трассировщика).
Полное соответствие темпа выполнения встроенного приложения в режиме измерения покрытия кода тестируемой ОС темпу обычного режима работы встроенного приложения достигается в случае применения техники с замещением единственной инструкции ОС. В этом случае последовательность шагов выглядит так.
Шаг 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 J., 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.J. The art of software testing. NY, USA, John 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 July 1995 (Dundee, UK: University of Abertay Dundee, 1995), v.l.
7. Баранов C.H., Домарацкий A.H., Ласточкин H.K., Морозов В.П. Предотвращение дефектов при создании программных изделий. //Программные продукты и системы. - 1998. -№2. - С.2-6.
МОДУЛЬНОЕ ТЕСТИРОВАНИЕ ОПЕРАЦИОННОЙ СИСТЕМЫ
РЕАЛЬНОГО ВРЕМЕНИ
Я.А. Домарацкий
Тестирование операционной системы (ОС) реального времени имеет свои особенности, которые необходимо учитывать при организации как модульного, так и интеграционного тестирования, тестирования работоспособности и системного тестирования. Настоящая статья посвящена описанию организации только модульного тестирования ОС реального времени, хотя многие принципы его организации пригодны и для организации других видов тестирования.
Модульное тестирование ОС реального времени предназначено для выявления дефектов в тестируемом модуле с их обязательным последующим устранением и для подтверждения правильности выполнения спецификаций проектирования этим модулем ОС. Тестирование любого модуля ОС выполняется отдельно, независимо от других модулей. Оно осуществляется разработчика-
ми ОС на этапе отладки (см. с. 30-33 наст. ном. журн.). Существует стандарт по проведению модульного тестирования [1].
При организации модульного тестирования предполагается, что при проектировании все функции ОС логически разделены на компоненты. Каждому компоненту ставится в соответствие программный модуль ОС. Под программным модулем ОС подразумевается минимальная часть ОС, которая имеет спецификацию, описывающую реакцию этого модуля на определенное входное воздействие. Далее ставится задача тестирования каждого компонента отдельно, независимо от других компонентов.
На этапе модульного тестирования ОС для каждого модуля системы и его спецификации необходимо создать соответствующий набор тестов. При этом допуска-
ется использование метода "белого ящика" [2], то есть при разработке модульных тестов можно использовать не только информацию о модуле, полученную на основе его спецификации, но и информацию о внутренней структуре ОС, а также знание исходного кода тестируемого модуля. Для этого необходимо осуществить анализ требований к компоненту функций ОС, анализ архитектуры поставленного в соответствие этому компоненту модуля ОС и проанализировать спецификации проектирования. Модульное тестирование часто соприкасается с компонентным тестированием [3].
Разработка списка тестов для модульного тестирования
При разработке списка элементарных тестов на этапе модульного тестирования ОС реального времени возможно применение различных методов. Все методы могут быть разделены на два основных вида: методы, базирующиеся на анализе спецификаций проектирования и на анализе исходного кода. Часто возможно применение метода, предполагающего построение модели системы.
Разработка списка тестов на основе анализа спецификаций проектирования
Разбиение по принципу равнозначности. Принцип основывается на разбиении входных воздействий на компоненты по схожести выходных реакций. Такое разбиение получается на основе спецификации компоненты. Каждое разбиение должно содержать перечень или интервал входных значений, объединенных по принципу идентичности выходных реакций. Примером подобного разбиения может служить разбиение всего набора входных воздействий для директивы "активизировать задачу" на следующие классы: активизировать задачу с большим приоритетом, чем текущая; активизировать задачу с меньшим приоритетом, чем текущая; активизировать несуществующую задачу. Список тестов создается для проверки каждого класса входных воздействий.
Анализ граничных условий. Метод основывается на принципе разбиения входных воздействий и выходных реакций по принципу нахождения в определенном интервале. Такое разбиение получается на основе выделения ограниченных интервалов значений для входных воздействий и реакций. Каждое разбиение должно содержать набор значений, попадающих в один интервал. Примером подобного разбиения может служить разбиение всего набора входных воздействий для директивы "послать сообщение" на следующие классы: послать сообщение, длина которого находится в пределах одного машинного слова; послать сообщение, длина которого находится в пределах двух машинных слов; послать сообщение, длина которого превышает два машинных слова. Для каждого интервала воздействий обычно достаточно проверить три значения: граничные значения и некоторое среднее значение. Список тестов создается для проверки каждого из выделенных интервалов входных воздействий и реакций.
Метод анализа переходов между состояниями основывается на анализе возможных состояний компонента и возможных переходов между этими состояниями, на анализе внешних событий, вызывающих переходы, и соответствующих выходных реакций. Результаты такого анализа обычно представляются в виде диаграммы перехода состояний. Примером подобного анализа
может служить разбиение множества переходов состояний семафора в результате исполнения директивы "освободить семафор" на следующие классы: состояние семафора изменилось, и он стал свободен; состояние семафора не изменилось, и он остался занят. Список тестов создается для проверки всех возможных путей в диаграмме перехода состояний.
Метод причинно-следственного анализа. В основу метода положен причинно-следственный анализ связей между входными воздействиями и выходными реакциями. Воздействия и реакции рассматриваются как некие логические условия, которые могут быть либо истинными, либо ложными, либо как комбинация таких условий. Компонент представляется в виде графа, отражающего взаимосвязь между воздействиями и реакциями с использованием логических операторов. Список тестов составляется для проверки всех возможных комбинаций логических условий, отражающих взаимосвязь входных воздействий и реакций.
Составление списка тестов на основе анализа программного кода модуля
Тестирования элементов исполняемого кода модуля. Этот метод предполагает анализ исходного кода и выделение исполняемых элементов. Задача составления списка тестов состоит в получении максимального покрытия тестами исполняемых элементов программного кода модуля.
Тестирования условных переходов. При составлении списка тестов для тестирования условных переходов необходимо провести анализ исходного кода модуля и осуществить выделение операторов ветвления (под оператором подразумевается исполняемый элемент кода, который может вызвать изменение в последовательности передачи управления в зависимости от логического условия). Подобный анализ служит для выяснения возможного изменения выходной реакции компонента в зависимости от изменений в последовательности исполнения. Список тестов составляется для проверки изменений выходной реакции на основании всех возможных изменений в последовательности исполнения.
Тестирования потока данных. Метод основан на тестировании компонента с точки зрения потока передачи информации между различными его частями. Разбиение проводится на основе анализа использования данных и анализа возможных моментов их изменения. Список тестов составляется для проверки корректности работы со всеми данными.
Тестирование единичных условий ветвления. Для этого необходимо выполнить анализ операторов ветвления с точки зрения логических условий. Результат сравнения в операторе ветвления, который может изменить последовательность работы компонента, зависит от заложенной в него логики. Список тестов должен быть разработан в расчете на проверку единичных логических условий в операторах ветвления.
Тестирование комплексных операторов ветвления. Список тестов для этого случая составляется по результатам анализа комплексных логических условий, состоящих из комбинации нескольких логических переменных, и используется для проверки работы компонента при переборе всех комбинаций логических условий, входящих в комплексные операторы ветвления.
Тестирование последствий ветвления. Для решения этой задачи следует использовать анализ исход-
ного кода и выделение условных операторов, соответствующих логических условий и возможных путей ветвления. Список тестов составляется для проверки того, что каждый логический оператор, входящий в комплексное условие ветвления, вызывает требуемый результат ветвления и выходную реакцию компонента независимо от остальных логических операторов.
Тестирование непрерывных участков кода. Такое тестирование предполагает использование результатов анализа исходного кода и выделение последовательностей операторов, выполняемых непрерывно, и точек, в которых происходит изменение последовательности передачи управления. Результатом анализа являются выделенные в исходном коде программного модуля непрерывные участки с указанием точек начала, конца и точек других участков, в которые может быть передано управление. Список тестов составляется для исполнения всех подобных непрерывных участков кода.
Разработка списка тестов на основе построения модели системы. Этот метод позволяет упростить процесс создания списка тестов за счет автоматического анализа модели системы. При использовании такого метода необходимо построить формальную модель системы в терминах конечного автомата [4]. Подобная модель может быть неполной, поскольку не требуется окончательной детализации. Задача построения модели системы в терминах конечного автомата требует выделения набора состояний системы и описания возможных переходов между состояниями. Под состоянием системы подразумевается определенное, обособленное, ортогональное условие, которое удерживается некоторый промежуток времени [5]. Переходы между состояниями системы отражают реакцию системы на наступление событий, вызванных внешними или внутренними источниками, и влекут за собой выполнение определенных действий. Современные программные средства, предназначенные для проектирования сложных систем, позволяют осуществить моделирование поведения системы после построения ее модели в терминах конечного автомата [6]. На основе построенной модели и результатов моделирования возможно автоматическое выделение наборов исходных состояний и воздействий на систему, которые служат основой для создания списка тестов на этапе модульного тестирования.
Реализация тестов на этапе модульного тестирования
При разработке ОС этап модульного тестирования всегда совмещается с ее отладкой. Практика показывает, что вероятность обнаружения дефекта в системе при осуществлении модульного тестирования достаточно велика, а упрощение процесса отладки приводит к необходимости выполнения требования простоты организации тестового комплекта. Таким образом, при модульном тестировании целесообразна разработка неделимых тестов без контроля исполнения и внешней интерпретации результатов тестирования.
Требования к реализации модульных тестов:
а) простота организации - организация модульных тестов должна быть достаточно проста для облегчения понимания и отладки системы;
б) естественность - модульный тест не должен управляться данными реального приложения;
в) повторяемость - поведение модульного теста должно быть неизменно при каждом исполнении;
г) изолированность - модульный тест должен проверять только один компонент (и никак не должен затрагивать остальные), допускать возможность исполнения при тестировании неполной системы, состоящей из усеченного набора компонентов;
д) ограниченность - модульный тест должен быть достаточно коротким в целях облегчения процесса отладки теста и интерпретации результата его исполнения.
Специфика реализации модульных тестов
Разрабатываемая ОС обычно не обладает полным набором функций к началу этапа модульного тестирования. К этому времени, как показывает практика, бывает реализован только ограниченный набор компонентов либо некоторые компоненты реализованы частично. Это приводит к необходимости затрат дополнительных усилий при разработке модульных тестов, связанных с использованием ограниченного набора сервисов, предоставляемых системой в ограниченных предопределенных условиях. Поэтому перед этапом реализации модульных тестов обязательно следует проанализировать состояние системы, выделить набор тестируемых компонентов и описать их допустимые состояния.
На этапе модульного тестирования часто ограничена функциональность средств отладки, связанная с невозможностью применения средств отладки, ориентированных на целевую ОС реального времени. Поэтому отладка модульных тестов часто доступна только на уровне исходного кода (или на уровне исполняемых команд). При этом, как правило, невозможно использовать отладчики, оперирующие категориями операционной системы (задачами, сообщениями, семафорами и т.д.)
Способы реализации модульных тестов
Различают два вида реализации модульных тестов -ручное и автоматизированное. Ручная реализация является основным методом разработки модульных тестов. При использовании ручного способа перед разработчиком стоит задача генерации набора пользовательских приложений для ОС реального времени, который необходимо использовать при осуществлении модульного тестирования. Каждое отдельное пользовательское приложение должно обладать простой структурой и быть приближено по своей организации к реальному приложению пользователя. Особое внимание должно уделяться проверке корректности внешних воздействий на систему, так как обычно на ранних этапах разработки в системе отсутствуют какие-либо механизмы защиты ОС от разрушения. Обязательно следует учитывать имеющиеся ограничения, связанные с необходимостью использования неполного набора сервисов ОС в предопределенных условиях.
Использование автоматизированных средств создания модульных тестов практически не представляется возможным ввиду отсутствия средств, предназначенных для генерации исходного кода пользовательских приложений. Однако некоторые современные программные средства проектирования и моделирования сложных систем предоставляют средства генерации исходного кода пользовательского приложения на основе анализа модели системы в терминах конечного автомата [6]. При использовании подобных средств появляется возможность автоматической генерации исполняемого кода пользовательского приложения, реализующего сце-
нарий тестирования (последовательность переходов между различными состояниями системы в ходе исполнения теста). Из-за отсутствия полной сборки ОС на этапе модульного тестирования подобный автоматически сгенерированный код пользовательского приложения должен быть дополнен вручную отсутствующими элементами, реализующими функции воздействия на систему и пользовательские объекты. Таким образом, применение средств моделирования, использующих формальные модели будущей системы, позволяет осуществить частичную автоматизацию процесса разработки модульных тестов. Заметим, что подобные средства автоматизации являются весьма дорогостоящими, поэтому пока нам не удалось их использовать.
Обратим внимание на то, что модульное тестирование ОС реального времени выполняется в группе разработчиков и является важным этапом отладки ОС. Чем больше дефектов, имеющихся в модулях, будет выявлено и устранено при выполнении модульного тестирования, тем легче будет протекать процесс дальнейшей отладки ОС в целом (процесс интеграционного тестирования и тестирования работоспособности), тем более высокий уровень качества будет иметь при поставке
разрабатываемая ОС. Поэтому главной задачей модульного тестирования является отыскание и устранение дефектов в отдельных модулях ОС, а для выполнения этой задачи следует иметь набор простых и коротких модульных тестов.
Список литературы
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 наст. ном. журн). Авторы предлагают вниманию читателей описание процесса системного тестирования, принятое в ИДУ.
Работы по тестированию ПИ разделены между разработчиками ПИ и группой системного тестирования. Разработчики ПИ выполняют модульное тестирование, интеграционное и тестирование работоспособности ПИ. Системное тестирование выполняется в отдельной группе, которая названа группой системного тестирования (ГСТ).
ГСТ не участвует в разработке кода ПИ и пользовательской документации, а занимается только системным тестированием готовой версии ПИ. Главной целью системного тестирования является обнаружение дефектов в готовой версии ПИ и выявление расхождений между требованиями заказчика к ПИ и реальным поведением ПИ при его работе (подтверждение соответствия реального поведения ПИ требованиям заказчика).
Для этого в ГСТ разрабатывается комплекс системных тестов (тестовый комплект), который должен представлять собой совокупность программ и документов,
необходимых и достаточных для обеспечения выявления дефектов в программных кодах ПИ и пользовательской документации, для обнаружения и документирования расхождений между требованиями заказчика к ПИ и его реальным поведением.
В ИДУ для каждого проекта по разработке ПИ из состава ГСТ выделяется ответственный системный тес-тировщик, который начинает работы по системному тестированию непосредственно после утверждения "Положения о работе" для данного проекта ПИ. Он получает доступ к любой информации по проекту тестируемого ПИ, в том числе к исходным кодам ПИ в дальнейшем. Это обусловливает более эффективную и целенаправленную работу системного тестирования. По результатам ознакомления с требованиями заказчика к ПИ системный тестировщик проверяет каждое требование на возможность его тестируемости.
ГСТ начинает свою работу по созданию тестового комплекта для ПИ с составления плана системного тестирования сразу после утверждения требований заказчика к нему. Приведем перечень основных материалов, создаваемых в ходе разработки тестового комплекта и выполнения циклов системного тестирования, который принят в ИДУ в качестве обязательного. В перечень входят:
• план системного тестирования, основой которого являются утвержденные требования заказчика к ПИ и проектный план разработки ПИ;
• процедуры системного тестирования - документы, описывающие порядок выполнения тестов, обеспечивающие требуемую последовательность запуска системных тестов и критерии их успешного завершения (в процедурах системного тестирования необходимо также
