Зиновьев Дмитрий Андреевич
| Факультет: | Компьютерных наук и технологий |
| Кафедра: | Автоматизированные системы управления |
| Специальность: | Информационные управляющие системы и технологии |
| Тема выпускной работы: | Составление тестовых последовательностей на основе объектно-ориентированных моделей |
| Руководитель: | к.т.н., доцент Фонотов Анастас Михайлович |
Введение
Важно задачей в процессе разработки и внедрения программного обеспечения занимает тестирование ПО. Обычно это занимает от 30 до 50 процентов времени, которое было затрачено на создание продукции. В связи с этим является целесообразным разработать систему, которая позволит упростить процесс тестирования, что позитивно повлияет как на качество выпускаемой продукции, так и на время производства.
Актуальность темы
Каждый день выходит огромное количество программной продукции, которая за частую не проходит нужного уровня тестирования. Разработка данной систему упростит процесс тестирования и сократит его сроки.
Цели и задачи разработки
Целью магистерской работы является создание автоматизированной системы составления тестовых последовательностей на основе объектно-ориентированной модели.
Основными целями системы является:
Общая постановка задачи
Процесс разработки программного обеспечения состоит из 5 этапов: выдвижение требований, анализ, проектирование, разработка, тестирование [1].
Производство качественного программного обеспечения является основной задачей разработчиков. Но помимо самой разработки, много времени и средств уходит на проверку выпускаемого продукта. Процесс тестирования программного обеспечения позволяет дать оценку качеству программного продукта, оценить готовность его к внедрению. На сегодняшний день методы тестирования не позволяют выявить все возможные «неисправности» при рассмотрении крупных информационных систем и дать однозначный ответ о корректности работы программного обеспечения [1]. Но в основном от качества проверки будет, зависит, насколько хорошим и популярным будет данный продукт.
Тестируя довольно не большую модель, можно проверить практически все варианты выполнения системы. Но если система большая, то количество тестов и время их выполнения может стать серьезной проблемой для разработчиков и тестировщиков. В связи с этим появляется задача оптимизации тестовых наборов. Для этой цели используются критерии тестового покрытия. Критерии тестового покрытия это определенный набор условий, выполнив который можно сказать, что система успешно прошла тестирование. На данный момент считается, что хороший процент покрытия 60 – 70% [2].
Перечислим самые распространенные критерии тестового покрытия:
На сегодняшний день вопросу тестирования, а именно его автоматизации, уделяется большое внимание. Создаются специальные программы для тестирования продукции, которые используют код программы или модель системы. Но все, же основная часть продуктов рассчитаны на работу именно с программным кодом. В связи с тем, что существует огромное количество языков программирования и принципов построения кода программ, тестирование на основе программного кода является сложно выполнимой задачей. Для того что бы сделать процесс тестирования универсальным, следует использовать для построения тестов объектно-ориентированную модель системы. Можно выделить 3 основные причины, почему следует пользоваться моделью проекта:
Генерация тестовых последовательностей, основанная на объектно-ориентированных моделях, может быть начата на самых ранних этапах создания программного продукта и позволяет выполнить одновременно написание и проверку продукта.
Наиболее универсальным способом тестирования, является последний рассмотренный вариант – формирование тестов на основе объектно-ориентированных моделей. Для построения объектно-ориентированных моделей чаще всего используют язык UML. Диаграмма взаимодействия, диаграмма классов, диаграмма состояний позволяют рассмотреть динамику взаимодействия объектов в системе и возникающие при этом ветвления и альтернативы потока событий.
Различают 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 представлена схема генерации тестовых данных предложенная Бейзером.[4]
Рисунок 1 – Cхема генерации тестовых данных
(Анимация:объем – 23,7 КБ; размер – 462х446; количество кадров – 4; зедержка между кадрами 500 мс;
количество циклов повторения – бесконечное)
Исходя из утверждений Бейзера, были созданы описания для диаграмм последовательности, представленные ниже[2].
Каждая диаграмма представляет собой запись следующего вида D=(A,T,F,C,a1,af), где:
это поток связей между действиями и переходами;Для генерации Test Cases нам необходимо сравнить выполнение программы с динамическим выполнением диаграммы деятельности[2].
Методика формирования Test Case
Существует множество различных алгоритмов для построения тестов по модели системы. И зачастую данная процедура содержит три основных шага:
Рассмотрим эти шаги подробнее
Формирование системы и ввод ограничений и условий
Для того что бы начать процесс составления Test Cases необходимо сперва составить модель проекта. Для разработки проекта будем использовать UML. Появление OCL (Object Constraint Language) дало возможность накладывать дополнительные условия в UML-модели. Условия, задаваемые с помощью OCL, позволяют рассмотреть диаграммы последовательности и деятельности, как расширенные сценарии поведения системы.
Интерпретация модели в виде графа
Часто для формирования тестовых последовательностей используют Структурированный составной граф (Structured Composite Graph). Это делается для того что бы систематически исследовать потоки управления модели. Информация, которая храниться в диаграмме преобразуется, и храниться в структурированном составном графе. Поочередно все состояния диаграммы исследуются и располагаются на графе. Для автоматизации процесса формирование тестовых последовательностей представление диаграммы в виде графа является очень удобным. Рассматриваемая модель должна содержать информацию и требования к возможным значениям переменных и к входным данным, которые приводят к изменению состояния системы.[5]
Составление тестовых последовательностей(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 [электронный ресурс] доступ к статье: http://www.jot.fm/issues/issue_2010_03/article2.pdf
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.
4. B. Beizer. Software Testing Techniques. Van Nostrand Reinhold, 2nd edition, 1990.
5. K. Chang, W. Carlisle, J. Cross II, and D. Brown. A heuristic approach for test case generation. In Proceedings of the 1991 ACM Computer Science Conference, pages 174{180. ACM, 1991.
6. W. H. Deason, D. Brown, K. Chang, and J. H. Cross II. A rule-based software test data generator. IEEE Transactions on Knowledge and Data Engineering, 3(1):108{117, March 1991.
7. R. A. DeMillo and A. J. O utt. Constraint-based automatic test data generation. IEEE Transactions on Software Engineering, 17(9):900{910, September 1991.
8. R. Ferguson and B. Korel. The chaining approach for software test data generation. IEEE Transactions on Software Engineering, 5(1):63{86, January 1996.
9. R. Ferguson and B. Korel. Generating test data for distributed software using the chaining approach. Information and Software Technology, 38(1):343{353, January 1996.
10. N. Gupta, A. P. Mathur, and M. L. So a. Automated test data generation using an iterative relaxation method. In Proceedings of the ACM SIGSOFT sixth international symposium on Foundations of software engineering, pages 231{244, November 1998.
11. B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870{879, August 1990.