ПРОГРАММИРОВАНИЕ, 2009, № 5, с. 57-69
■ ТЕСТИРОВАНИЕ, ВЕРИФИКАЦИЯ И ВАЛИДАЦИЯ ПРОГРАММ
УДК 004.92+004.94
МЕТОД РЕДУКЦИИ ТЕСТОВОГО НАБОРА ДЛЯ РЕГРЕССИОННОГО ИНТЕГРАЦИОННОГО ТЕСТИРОВАНИЯ
© 2009 г. Д. Ю. Кичигин
Sophis UK
3-6 Gracechurch street London EC3V OAT United Kingdom E-mail: dkichigin@gmail.com Поступила в редакцию 11.01.2009 г.
В статье излагается метод редукции тестового набора для регрессионного тестирования взаимодействия двух модулей программного обеспечения, основывающийся на построении модели взаимодействия модулей на наборе тестов и последующей фильтрации тестового набора с помощью построенной модели. Модель взаимодействия строится в терминах последовательностей функций интерфейса интегрируемых модулей, вызываемых во время выполнения программного обеспечения.
1. ВВЕДЕНИЕ
Для современного программного обеспечения характерна высокая степень его модульности, что приводит к важности и необходимости проведения интеграционного и регрессионного интеграционного тестирования при создании и последующих модификациях ПО. В то же время, развитие программного обеспечения и, особенно, увеличение количества вносимых в него модификаций приводят к увеличению затрат на проведение регрессионного интеграционного тестирования [1]. В связи с этим достаточно актуальной является проблема уменьшения ресурсоемкое™ (в том числе и стоимости) такого вида тестирования. Редукция набора тестов [2-4] является одним из способов решения этой проблемы.
Задача редукции набора тестов заключается в создании набора тестов меньшего размера, но при этом, желательно, с таким же уровнем обнаружения ошибок [2]. Такое сокращение позволяет уменьшить затраты на сопровождение тестового набора и на выполнение на нем тестируемого программного обеспечения [2], что, в свою очередь, позволяет сократить затраты на проведение регрессионного тестирования в целом.
Традиционный подход к решению задачи редукции набора тестов, изначально разработанный для модульного тестирования, заключается в "отсеивании" тестов из первоначального набора таким образом, чтобы сохранялся уровень его адекватности в терминах некоторого выбранного критерия адекватности, и основывается на использовании статического анализа и/или инструментирования исходного текста ПО. Работа методов такого подхода, как правило, состоит из трех основных этапов. На первом этапе происходит инструментирование кода тестируемого ПО и запуск ПО на наборе тестов. На втором этапе собирается информация о достигнутом покрытии кода. Наконец, на третьем этапе происходит редукция набора тестов на основе собранной информации о покрытии [2]. В случае интеграционного тестирования большинство методов редукции набора тестов является адаптацией существующих методов для модульного тестирования. Основное отличие состоит в том, что анализируется покрытие части кода, отвечающей за взаимодействие интегрируемых элементов ПО.
Современные тенденции в разработке программного обеспечения ставят новые условия для методов редукции набора тестов и во мно-
гом ограничивают область применения существующих методов. Во-первых, использование методов, основанных на анализе исходного кода программы, может быть очень ресурсозатрат-ным для программного обеспечения большого объема [5, 6]. Также, в то время как инстру-ментирование исходного кода программы может быть достаточно нетрудоемко для программного обеспечения, состоящего из нескольких модулей, инструментирование исходного кода для ПО, состоящего из большого количества модулей, - гораздо более сложная и затратная по времени процедура [5]. Кроме того, особым препятствием становится возрастающая популярность использования готовых программных компонент. Такие компоненты, как правило, поставляются без исходного кода, что делает невозможным применение методов, основанных на анализе или инструментировании исходного кода программы [2]. Эти обстоятельства ограничивают область применения существующих методов редукции набора тестов и делают актуальной разработку новых методов, способных работать без доступа к исходному коду ПО.
В данной работе предлагается новый метод редукции набора тестов, основанный на анализе взаимодействия интегрируемых модулей на наборе тестов и использующий для этого короткие последовательности функций интерфейса модулей, вызванных во время выполнения ПО. В работе рассматривается взаимодействие между двумя модулями, осуществляемое через интерфейс функций, в качестве параметров которых выступают скалярные параметры. Предлагаемый метод не требует доступа к исходному коду ПО и не предполагает его инструментирования, что существенно расширяет область его применения.
Работа организована следующим образом. В разделе 2 рассмотрены основные существующие методы редукции набора тестов, применяемые для проведения регрессионного интеграционного тестирования. Раздел 3 посвящен описанию рассматриваемых взаимодействий и возникающих в них интеграционных ошибок. Раздел 4 посвящен описанию предлагаемого метода редукции набора тестов. В разделе 5 приводится описание проведенных экспериментов и их результатов. Завершающий раздел посвящен выводам.
2. СУЩЕСТВУЮЩИЕ РЕШЕНИЯ
Традиционный подход к решению задачи редукции набора тестов состоит в построении набора тестов меньшего размера, но при этом эквивалентного первоначальному в терминах выбранного покрытия элементов программы [7]. В случае интеграционного тестирования в качестве покрытия выступает покрытие взаимодействия между модулями. Существующие подходы к редукции набора тестов для интеграционного тестирования различаются в основном используемой метрикой покрытия, и, согласно этому параметру, их можно разделить на 2 основные группы.
2.1. Мутационный анализ
Изначально метод мутационного анализа был разработан для оценки адекватности модульного тестирования и состоит в систематизированном добавлении дефектов в программу и проверке обнаружения этих дефектов набором тестов [8].
Для интеграционного тестирования был предложен метод мутаций интерфейса (англ.: Interface Mutation) [9], являющийся адаптацией метода мутационного анализа. Метод мутаций интерфейса оценивает полноту тестирования взаимодействия между модулями программного обеспечения и основывается на следующих трех идеях [9]:
1. в качестве мутационных операторов принимаются те, которые моделируют интеграционные ошибки;
2. в случае интеграционного тестирования более двух модулей взаимодействия между несколькими модулями тестируются попарно;
3. мутационные операторы применяются только к "интерфейсным" частям исходного кода программного обеспечения, таким, как вызовы интерфейсных функций, их параметры или глобальные переменные.
Метод мутаций интерфейса работает в терминах исходного кода, что делает его неприменимым в случае отсутствия доступа к исходному коду программы.
2.2. Структурные метрики
В основе структурных метрик лежит проверка того, насколько хорошо тестовые наборы тестируют поведение структурных элементов ПО, отвечающих за взаимодействия интегрируемых элементов. Вычисление структурных метрик состоит из двух этапов: на первом (статическом) производится анализ исходного текста интегрируемых модулей с целью выявления зависимостей между ними; на втором (динамическом) производится анализ взаимодействия между модулями во время выполнения ПО на тестовом наборе с целью проверки фактического выполнения связей между модулями, выявленных на первом этапе. По результатам такой проверки выносится оценка о покрытии тестовым набором взаимодействия между модулями. Существуют две основные группы таких метрик, различающиеся видом используемой модели программы. К первой группе относятся методы, использующие модель потока управления в программе (англ.: program control flow model) [10, 11], ко второй - модель потока данных в программе (англ.: program data flow model) [11-13].
В основе метрик, использующих модель потока управления программы, лежит использование понятия графа потока управления программы (англ.: control-flow graph) [8]. Под графом выполнения программы понимается направленный граф, узлами которого являются интегрируемые элементы ПО, а дугами - взаимодействия между ними. Такой граф строится на основе реверс-инжиниринга исходного текста программы. Причем конкретный тип интегрируемых элементов зависит от тестируемого взаимодействия. Так, в [10] тестируется взаимодействие между функциями, и, соответственно, узлами графа являются отдельные функции программы, а ребрами - вызовы функций. В работе [11] тестируется межмодульное взаимодействие, и в используемом графе узлами являются интегрируемые модули, а ребрами - межмодульные вызовы интерфейсных функций модулей. Выполнение программы на тестовых наборах моделируется как проход по графу. При этом выполнение на каждом отдельном тесте соответствует пути в графе от начального узла до конечного. Такой путь называется пу-
тем выполнения программы (англ.: computation path или execution path). Метрика покрытия кода отображает, насколько хорошо путь выполнения программы покрывает элементы графа и, таким образом, характеризует покрытие внутренних элементов программы.
Метрики покрытия, использующие модель потока данных в программе, рассматривают потоки данных, протекающие через интерфейсы интегрируемых элементов программы. В основе моделей потока данных лежит граф потока данных в программе, который, в свою очередь, строится на основе ассоциации информации о вхождениях переменных в программу с графом потока управления программы. Различают два основных способа вхождения переменных в программу: определение переменной (англ.: variable definition) и использование переменной (англ.: variable use) [8]. Идея метрик покрытия потоков данных в программе состоит в оценке того, насколько полно покрываются пути в графе потока данных от места определения переменной до места ее использования. Конкретный вид графа потока данных, как и в случае графа потока управления, зависит от тестируемого взаимодействия и используемой метрики покрытия. Так, в работе [12] используется метрика покрытия межпроцедурных потоков данных (англ.: interprocedural
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.