Зиновьев Д.А.
Донецкий Национальный Технический Университет
Кафедра автоматизированных систем управления
Источник: Інформаційні управляючі системи та комп`ютерний моніторинг (ІУС та КМ-2010). / Матеріали I всеукраїнської науково-технічної конференції студентів, аспірантів та молодих вчених - 19-21 травня 2010 р., Донецьк, ДонНТУ. - 2010. Збіник містить 2 томи загальним обсягом 634 стор.
Аннотация
Фонотов А.М., Зиновьев Д.А. Составление тестовых последовательностей «Test Case» на основе объектно-ориентированной модели. В статье рассматривается вопрос, и методы составления тестовых последовательностей, которые используют объектно-ориентированную модель системы. Проведен анализ ранее использованных методик, проанализированы их достоинства и недостатки, рассмотрены пути автоматизации процесса оптимальных тестовых последовательностей на основе объектно-ориентированных моделей.
Общая постановка задачи
Процесс разработки программного обеспечения состоит из 5 этапов: выдвижение требований, анализ, проектирование, разработка, тестирование [1].
Производство качественного программного обеспечения является основной задачей разработчиков. Но помимо самой разработки, много времени и средств уходит на проверку выпускаемого продукта. Процесс тестирования программного обеспечения позволяет дать оценку качеству программного продукта, оценить готовность его к внедрению. На сегодняшний день методы тестирования не позволяют выявить все возможные «неисправности» при рассмотрении крупных информационных систем и дать однозначный ответ о корректности работы программного обеспечения [1]. Но в основном от качества проверки будет, зависит, насколько хорошим и популярным будет данный продукт.
Тестируя довольно не большую модель, можно проверить практически все варианты выполнения системы. Но если система большая, то количество тестов и время их выполнения может стать серьезной проблемой для разработчиков и тестировщиков. В связи с этим появляется задача оптимизации тестовых наборов. Для этой цели используются критерии тестового покрытия. Критерии тестового покрытия это определенный набор условий, выполнив который можно сказать, что система успешно прошла тестирование. На данный момент считается, что хороший процент покрытия 60-70% [2].
Перечислим самые распространенные критерии тестового покрытия:
- Statement coverage – в тестовом наборе Т, каждое состояние будет выполнено хотя бы раз;
- Branch coverage – в тестовом наборе Т, каждый оператор ветвления должен быть выполнен как для значения true так и для значения false;
- Conditional coverage – каждое условие в графе должно быть выполнено как для true так и для false;
- Path coverage – в тестовом наборе Т, каждый переход должен быть пройден хотя бы раз. [2]
На сегодняшний день вопросу тестирования, а именно его автоматизации, уделяется большое внимание. Создаются специальные программы для тестирования продукции, которые используют код программы или модель системы. Но все, же основная часть продуктов рассчитаны на работу именно с программным кодом. В связи с тем, что существует огромное количество языков программирования и принципов построения кода программ, тестирование на основе программного кода является сложно выполнимой задачей. Для того что бы сделать процесс тестирования универсальным, следует использовать для построения тестов объектно-ориентированную модель системы. Можно выделить 3 основные причины, почему следует пользоваться моделью проекта:
- 1) традиционное программное тестирование включает в себя только статистическое рассмотрение кода, которое не достаточно для тестирования динамического поведения системы;
- 2) использование кода для проверки системы является сложной и трудоемкой задачей;
- 3) модель помогает лучше понять систему и найти данные для тестирования после просмотра модели, чем та же работа с кодом.
Генерация тестовых последовательностей, основанная на объектно-ориентированных моделях, может быть начата на самых ранних этапах создания программного продукта и позволяет выполнить одновременно написание и проверку продукта.
Наиболее универсальным способом тестирования, является последний рассмотренный вариант – формирование тестов на основе объектно-ориентированных моделей. Для построения объектно-ориентированных моделей чаще всего используют язык UML. Диаграмма взаимодействия, диаграмма классов, диаграмма состояний позволяют рассмотреть динамику взаимодействия объектов в системе и возникающие при этом ветвления и альтернативы потока событий.
Различают 3 вида тестирования :
- 1) тестирование черного ящика;
- 2) тестирование белого ящика;
- 3) тестирование серого ящика.
В основе тестирования объектно-ориентированных моделей лежит так называемые серый ящик, это вид тестирования, когда разработчику тестов доступен не весь код, но алгоритм процесса и все возможные условия которые могут повлиять на конечный результат выполнения программы.
При рассмотрении вопросов тестирования на основании объектно-ориентированных моделей Test Case представляет собой набор констант, значений переменных, которые приводят систему в одно из состояний. Для того что бы понять работает ли система правильно, сравнивается test oracle – ожидаемый результат системы после тестирования и actual result – результат который тестировщик получает после тестирования. На основании анализа полученных результатов делают выводы, был ли тест пройден.
Представление моделей
Любую модель системы или программы можно рассматривать как функцию 
где S это набор возможных входных значений и R это набор возможных результатов. Более формально S это набор векторов 
, так чтобы 
где Dxi является областью входных переменных xi.
Поток управления графа (Control Flowgraph) модели P это направленный граф G=(N,E,s,e) который состоит из набора узлов N и набора ребер 
соединенных с узлами. В каждом графе есть два специальных узла входной узел s и выходной узел e [3].
Каждый узел можно считать базовым блоком, который интерпретируется как последовательность инструкций. Выполнение блока можно понимать как выполнения последовательности инструкций в этом блоке. Ребро между двумя узлами n и m, соответствует возможному переходу из n в m. Каждое ребро представляет собой предикат с условием. Предикат может быть и без условия – пустой предикат, значение которого всегда true.
Путь 
- это последовательность узлов, где pqp это последний узел пути. Выполнение модели P c входными параметрами xi означает, что сценарий с входными параметрами xi приводит к прохождению по пути p. Путь называют осуществимым, если существует xi S пересекающий путь, иначе его называют не осуществимым.
На рисунке 1 представлена схема генерации тестовых данных предложенная Бейзером.
Рисунок 1 - Cхема генерации тестовых данных
Исходя из утверждений Бейзера, были созданы описания для диаграмм последовательности, представленные ниже[2].
Каждая диаграмма представляет собой запись следующего вида D=(A,T,F,C,a1,af), где:
- A={a1,a2…am} это набор состояние диаграммы деятельности;
- T={t1,t2…tn} это набор переходов диаграммы деятельности;
- С={с1,с2…cn} это набор граничных условий, сi соответствует ti. Сon это отображение значения ti, то есть Сon(ti)= сi;
это поток связей между действиями и переходами;- a1 начальный узел, af конечный узел.
Для генерации Test Cases нам необходимо сравнить выполнение программы с динамическим выполнением диаграммы деятельности[2].
Методика формирования Test Case
Существует множество различных алгоритмов для построения тестов по модели системы. И зачастую данная процедура содержит три основных шага:
- 1) формирование системы и ввод ограничений и условий;
- 2) интерпретация модели в виде графа;
- 3) составление тестовых последовательностей(test case).
Рассмотрим эти шаги подробнее
Формирование системы и ввод ограничений и условий.
Для того что бы начать процесс составления Test Cases необходимо сперва составить модель проекта. Для разработки проекта будем использовать UML. Появление OCL (Object Constraint Language) дало возможность накладывать дополнительные условия в UML-модели. Условия, задаваемые с помощью OCL, позволяют рассмотреть диаграммы последовательности и деятельности, как расширенные сценарии поведения системы.
Интерпретация модели в виде графа.
Часто для формирования тестовых последовательностей используют Структурированный составной граф (Structured Composite Graph). Это делается для того что бы систематически исследовать потоки управления модели. Информация, которая храниться в диаграмме преобразуется, и храниться в структурированном составном графе. Поочередно все состояния диаграммы исследуются и располагаются на графе. Для автоматизации процесса формирование тестовых последовательностей представление диаграммы в виде графа является очень удобным. Рассматриваемая модель должна содержать информацию и требования к возможным значениям переменных и к входным данным, которые приводят к изменению состояния системы.
Составление тестовых последовательностей(Test Case).
Задача состоит в том, чтобы сгенерировать такой набор входных данных xi для модели P и пути u, что бы набор xi привел к движению по сценарию u. Выделяют три класса методов генерации тестовых последовательностей: генерация случайных тестовых данных (random), целенаправленная генерация данных (goal-oriented), генерация данных с использованием пути (path-oriented).
Генерация случайных тестовых данных (random).
Данный метод является самым простым для составления тестовых данных. Он может быть применен для любого типа данных. Но данный метод имеет маленькую вероятность нахождения ошибок, а так, же маленькое тестовое покрытие. Данные, которые сгенерированы, могут не удовлетворять определенным условиям модели.
Целенаправленная генерация данных (goal-oriented).
Этот метод намного эффективнее случайной генерации. В место того чтобы сгенерировать данные которые позволяют рассмотреть модель от начала до конца, метод генерирует такой набор данных который позволит пересечь заданный неспецифический(unspecific) путь.
Одним из методов, использующих эту методику, является цепочный подход. Метод цепочки ищет значения, для предикатов ветви исходя из накладываемых условий. При этом решается задача идентифицировать цепочку узлов, которые необходимо выполнить, что бы дойти до выбранного узла. Эта цепочка строиться итеративно в процессе выполнения.
Генерация данных с использованием пути (path-oriented).
Данный метод является самым результативным из перечисленных. Он не предоставляет возможность выбора пути из определенного множества возможных путей, однако дает возможность выбрать один определенный путь. В этом этот метод чем-то похож на целенаправленную генерацию. Использование выделенных путей приводит к большему покрытию модели. С другой стороны сложнее найти тестовые данные.
На рисунке 1 изображена схема генерации данных с использованием пути. Важным компонентом схемы является именно выбор пути (Path selector). Выбирается такой набор путей, который будет удовлетворять выбранным критериям покрытия.
Список литературы
1. Journal of Object Technology 2008// A Novel Approach to Generate Test Cases from UML Activity Diagrams.
2. Journal of Object Technology 2008// Automatic Test Data Synthesis using UML Sequence Diagrams
3. A survey on automatic test data generation. In Proceedings of the Second Conference on Computer Science and Engineering in Linkoping, pages 21-28.ECSEL, October 1999.