ТЕСТИРОВАНИЕ, ВЕРИФИКАЦИЯ И ВАЛИДАЦИЯ ПРОГРАММ =
УДК 004.92+004.94
АВТОМАТИЗАЦИЯ МАССОВОГО СОЗДАНИЯ ТЕСТОВ РАБОТОСПОСОБНОСТИ
© 2008 г. Р. С. Зыбин, В. В. Кулямин, А. В. Пономаренко, В. В. Рубанов, Е. С. Чернов
Институт системного программирования РАН 109004 Москва, ул. Б. Коммунистическая, 25 E-mail: {phoenix, kuliamin, susanin, vrub, ches}@ispras.ru Поступила в редакцию 28.04.2008 г.
В данной статье рассказывается о технологии массового создания тестов работоспособности сложных программных систем, разработанной в Институте системного программирования РАН и названной Azov. Технология Azov основана на использовании базы данных со структурированной информацией об интерфейсных операциях тестируемой системы и методике пополнения этой информации за счет уточнения ограничений на типы параметров и результатов операций. Представленные результаты практической апробации технологии демонстрируют ее высокую эффективность при разработке тестов работоспособности для систем с большим количеством функций.
1. ВВЕДЕНИЕ
В современном мире как общее количество задач, решение которых возлагается на программные системы, так и их важность и ответственность все время возрастают. В связи с этим, с одной стороны, повышается сложность программного обеспечения (ПО), а с другой - риски, связанные с неизбежно возникающими при создании систем такой сложности ошибками. Единственным средством минимизации этих рисков является проведение на всех этапах создания или внесения изменений в ПО аккуратных и систематических проверок его корректности в смысле соответствия требованиям. Для такой проверки на последних этапах разработки чаще всего используется тестирование - наблюдение за работой системы и анализ ее правильности в ряде специально создаваемых ситуаций с учетом всех существенных аспектов ее поведения.
Имеющиеся на сегодняшний день методы тестирования требуют серьезных затрат для обеспечения некоторых гарантий полноты проводимой проверки. При возрастании сложности системы эти затраты возрастают нелинейно. Автоматизация создания тестов обычно не сильно
снижает их, поскольку она связана с необходимостью формализации требований к тестируемой системе, исходно заданных неформально, и классификации тестовых ситуаций для нее.
Однако иногда, когда результаты тестирования и не должны демонстрировать высокую надежность и полноту, эти затраты неоправданны. Например, при тестировании работоспособности проверяется только то, что система не разрушается и возвращает результаты, проходящие простейшие проверки на корректность (полная проверка при этом не выполняется). Оно используется, чтобы убедиться в том, что все функции системы устойчиво работают в простейших ситуациях, до того, как подвергнуть ее более тщательной и систематической проверке, которая требует значительно больше усилий, но бессмысленна, если система не в состоянии справиться даже с простейшими задачами. Такое тестирование экономит усилия на поиск и локализацию достаточно грубых ошибок в сложных программных системах.
Обычно тесты работоспособности разрабатываются вручную, но иногда огромное количество интерфейсных операций тестируемой систе-
мы и наличие полной и хорошо структурированной информации о них подталкивают к автоматизации их создания. Если операций очень много, традиционная разработка тестов для них становится слишком трудоемкой. В то же время, информация об их синтаксисе может быть использована для автоматической генерации заготовок тестов.
Оба этих фактора - большой размер и наличие базы данных с информацией об интерфейсных операциях - имеются у стандарта Linux Standard Base [3] (LSB), включающего несколько отдельных стандартов (POSIX [1], ISO C [4], Filesystem Hierarchy Standard [5] и пр.) и библиотек (Xlib [6], OpenGL [7], GTK+ [8], Qt [2]). В целом в LSB версии 3.1 входит более 30000 функций и методов. Для поддержки в актуальном состоянии текста стандарта и набора инструментов для выполнения различных проверок синтаксическая информация обо всех входящих в стандарт интерфейсах помещена в единую, хорошо структурированную базу данных. Все это позволяет использовать новый подход для создания тестов работоспособности LSB.
2. ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ СОЗДАНИЯ ТЕСТОВ РАБОТОСПОСОБНОСТИ
Для тех случаев, когда интерфейс системы состоит из тысяч операций и информация об элементах этого интерфейса хранится в хорошо структурированном, подходящем для автоматической обработки виде, можно предложить достаточно эффективную технологию автоматизации построения тестов работоспособности, основанных на требованиях, позволяющую создавать их массово, в большом количестве. Такая технология, названная Azov, разработана в 2007 году в Институте системного программирования РАН.
Эта технология использует базу данных с синтаксической информацией об операциях тестируемой системы и предполагает пополнение этой информации, в основном сводящееся к уточнению (специализации) типов параметров операций и их результатов. Уточнение выполняется вручную и позволяет в дальнейшем полностью
автоматически построить корректные входные данные для каждой операции и проверить некоторые свойства ее результата.
Технология включает следующие элементы.
• Методику уточнения данных об интерфейсных операциях.
• Базу данных с расширенной информацией о тестируемых операциях.
• Инструменты, использующиеся для внесения дополнительной информации в базу данных операций.
• Компоновщик тестов работоспособности, автоматически генерирующий набор тестов для выделенного множества операций по имеющейся в базе информации.
Основная идея технологии следующая: информация о типах параметров и результатов тестируемых операций уточняется так, чтобы позволить сгенерировать значения параметров для простейших сценариев нормального использования этих операций и выполнить некоторые (далеко не полные) проверки корректности их результатов. Поскольку одни и те же типы данных в больших системах используются многократно, массовая генерация тестов может привести к существенному снижению трудозатрат на каждый полученный тест.
2.1. Исходные данные и ожидаемые результаты
Исходными данными для выполнения работ по описываемой технологии являются база данных, содержащая структурированную синтаксическую информацию об операциях тестируемой системы (их сигнатуры), и документация на эти операции. На текущий момент предполагается, что все операции являются функциями языка С или методами классов С++. Изменение базового языка программирования в рамках императивных языков требует обычно лишь замены модуля печати выходной информации компоновщика тестов. Если в этом языке возможны способы передачи параметров и результатов операций, существенно отличающиеся от используемых в С/С++, может потребоваться некоторая модификация структуры используемой базы данных и алгоритмов генерации тестов.
Рис. 1. Схема выполнения работ по технологии Azov.
Структурированность информации об операциях означает, что в этой базе типы параметров и результатов операций должны присутствовать как отдельные сущности, связанные по ссылкам с соответствующими операциями. Более точные требования к исходной информации см. в разделе 2.5 "Инструментальная поддержка".
Документация на тестируемую систему должна содержать достаточно информации, чтобы можно было выявить основные сценарии работы всех интерфейсных операций, включая источники данных для аргументов вызова операции и базовые ограничения на возможные результаты при ее правильном функционировании.
Результатом работы по предлагаемой технологии является набор тестов работоспособности для всех операций тестируемой системы. Для каждой из них в этот набор входит тест, вызывающий операцию в рамках одного из простейших сценариев ее нормальной работы, не приводящих при корректной работе системы к сбоям, исключительным ситуациям или возврату кода ошибки. Тест также проверяет базовые ограничения на результат такого вызова. Все аргумен-
ты вызова должны быть построены корректным образом, и, при необходимости, должны быть сделаны предварительные вызовы других операций, инициализирующие необходимые внутренние данные системы, а также проведено итоговое освобождение захваченных ресурсов.
2.2. Организация работ по технологии Azov
Создаваемые по описываемой технологии тесты представляют собой тестовые варианты, т.е. программы, в рамках которых последовательно выполняются вспомогательные действия по подготовке системы к работе, инициализируются значения параметров для вызова тестируемой операции, выполняется этот вызов и производится финализация системы, т.е. освобождение ресурсов, которые должны быть освобождены по окончании работы. Кроме того, проверяются базовые ограничения на результаты всех выполняемых в тесте вызовов операций.
Разработка тестов в рамках технологии Azov разбита на следующие действия.
• Разбиение набора операций на функциональные группы. Интерфейс системы делится на
группы операций, работающих с одними и теми же внутренними данными и предоставляющих полный набор действий над ними. Это необходимо, прежде всего, для разбиения работ на достаточно независимые части, каждую из которых выполняет отдельный разработчик.
• Уточнение информации об интерфейсных операциях в базе данных. Разработчики анализируют документацию на операции выделенных им групп, определяя условия их нормальной работы и действующие при этом ограничения на их результаты. Выявляемые ограничения заносятся в базу данных в виде специализированных типов параметров и результатов операций. Каждый такой тип может иметь список возможных значений или действий, необходимых для инициализации или уничтожения данных такого типа. Если для нормальной работы операции необходимо правильно инициализировать не только ее аргументы, но и глобальные данные системы, для нее указываются соответствующие процедуры инициализации или финализа-ции этих данных. В ходе работы применяется методика уточнения данных, представленная ниже. Для заполнения базы данных используются вспомогательные инструменты, использующие Web-интерфейс и позволяющие осуществлять навигацию по базе данных, поис
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.