Интегрированная среда автоматизации тестирования на основе технологии Eclips Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.415

П.Д. Дробинцев, М.Ш. Даишев, В.П. Котляров

ИНТЕГРИРОВАННАЯ СРЕДА АВТОМАТИЗАцИИ ТЕСТИРОВАНИЯ НА ОСНОВЕ ТЕХНОЛОГИИ ECLIPSE

В ходе разработки программного обеспечения одним из наиболее трудоемких процессов является тестирование [1]. В настоящее время большое внимание уделяется сокращениям затрат на тестирование за счет автоматизации данного процесса. Это позволяет, с одной стороны, исключить влияние человеческого фактора, а, с другой, - ускорить процесс проверки ПО на наличие в нем дефектов. Для автоматизации тестирования необходимо решить проблему инвариантного задания тестов в некотором формальном виде, который может быть исполнен компьютером без участия человека или с его минимальным участием. В данном направлении ведется масса исследований по созданию новых стандартов и инструментальных средств, которые объединяются в рамках такого направления как Computer Aided Software Engineering (CASE). Наиболее известные графические стандарты, используемые в тестировании, - UML [2] и MSC [3]. В рамках языка UML (Unified Modeling Language) для тестирования обычно используются диаграммы последовательности (Sequence Charts), позволяющие описать последовательность воздействий на тестируемую систему и ее отклики. Широко зарекомендовавший себя в промышленном применении язык MSC (Message Sequence Charts) является подмножеством UML. Упомянутые выше языки содержат не только графическую нотацию для создания диаграмм, но и текстовую, которая преимущественно используется для автоматизации тестирования.

Другой компонентой автоматизации является инструментальное средство, поддерживающее выбранную нотацию. Существует огромное количество инструментов автоматизации, позволяющих в той или иной степени облегчить жизнь те-стировщику. Это такие инструменты, как Rational TTCN suite [4], Rational TAU, Test Real Time, Test Vector Generation [5], UniTestK [6], Conformiq Test [7], TAT[8] и др.

Перечисленные инструменты можно разделить на две категории. К первой относятся уни-

версальные средства автоматизации тестирования, а ко второй - специализированные средства автоматизации. Универсальные средства позволяют решать широкий круг задач, связанных с автоматизацией процессов настройки тестового окружения, генерацией и автоматизацией исполнения тестового набора, анализом результатов тестирования. Как правило, их применение требует серьезных затрат на адаптацию к платформе и применению. Их основная проблема - тяжеловесность и дороговизна лицензии. Недостатком специализированных средств является узкая область эффективного применения.

В данной статье рассматривается универсальная интегрированная среда, предоставляющая сервисы по настройке и управлению процессом автоматизации тестирования, основанная на использовании стандарта MSC в качестве языка описания тестов и инструмента TAT (Test Automation Toolset), предназначенного для генерации и автоматического исполнения тестового набора.

Интегрированная среда автоматизации тестирования. Основана на использовании технологии eclipse, что позволяет обеспечить платформо-независимость и максимально упростить работы по настройке и сопровождению. Интегрированная среда состоит из следующих модулей:

парсера, предназначенного для импорта и экспорта данных по настройке тестового окружения из внутренней модели данных;

модели данных, позволяющей хранить информацию из конфигурационного файла в специализированной модели среды eclipse;

пользовательского интерфейса, основанного на применении технологии GEF (Graphical Editing Framework), дающего возможность быстрого ввода и редактирования данных;

менеджера запуска - модуля, позволяющего легко собирать произвольные цепочки запуска инструментов TAT и вспомогательных скриптов.

Архитектура интегрированной среды представлена на рис. 1. Среда реализована в виде модуля (плагина) для eclipse, что позволяет макси-

Рис. 1. Интегрированная среда автоматизации тестирования

мально упростить ее инсталляцию и настройку. Используемая модулем модель данных содержит: описание объектов, участвующих в процессе тестирования;

описание сигналов между объектами; определение типов и параметров сигналов; описание списка тестов; данные по настройке инструментов; описание цепочек запуска инструментов. Информация, представленная в модели данных, отображается в графическом интерфейсе, позволяющем анализировать и редактировать данные, необходимые для настройки процесса тестирования.

Технология автоматизации тестирования. Технология автоматизации, основанная на ис-

пользовании интегрированной среды, состоит из трех этапов:

конфигурации тестового окружения; создании цепочек исполнения инструментов; исполнения и анализа тестового набора. Для удобства использования каждый из этапов реализуется с помощью специализированного пользовательского интерфейса. При этом, что немаловажно, данные по настройке процесса тестирования хранятся в общей модели данных, доступной из любого пользовательского интерфейса.

На первом этапе пользователь создает новую конфигурацию для хранения данных или импортирует уже существующую и на ее основе настраивает тестовое окружение, определяя объекты тести-

Менеджер инструментов Рис. 2. Технология настройки процесса тестирования

рования и их коммуникационный интерфейс. На втором этапе создается цепочка запуска инструментов, которые проводят подготовку теста к исполнению. На третьем этапе происходит непосредственно исполнение тестов и анализ результатов.

Этапы технологии автоматизации тестирования приведены на рис. 2.

Рассмотрим каждый из представленных этапов более подробно.

Настройка тестового окружения - одна из основных задач в рамках процесса автоматизации тестирования. Рассматриваемая в статье интегрированная среда основана на использовании нотации MSC, с помощью которой пользователь создает тесты. Пример теста приведен на рис. 3.

Основными элементами языка являются сущности (instances), описывающие объект тестирования и тестовое окружение, и сигналы (messages), описывающие воздействия на тестируемую систему и ее отклики. Таким образом, настройка тестового окружения заключается в ассоциации сущностей с реальными объектами и описании сигналов. В данном примере сущность TAT должна быть проассоциирована с системой тестирования, а сущность SUT (System Under Test) с тестовой системой. Пример подобной настройки приведен на рис. 4.

Рис. 3. Тест на языке MSC

В рамках настройки сигналов пользователь должен описать имена и направления сигналов, а также множество параметров сигналов и их типы. Данная информация будет использована системой автоматизации тестирования TAT для генерации коммуникационного модуля, позволяющего отправлять на тестируемую систему воздействия и анализировать ее отклики.

Настройка цепочки исполнения инструментов. Для успешного проведения тестирования пользователю зачастую необходимо провести ряд подготовительных работ. К ним относятся:

удаление из диаграмм тестов избыточной информации;

9 'WCccfoEdtor a' -J^umil.mpf | , CarRado.nti

Signals

Signals

ReOW«inq Soçk

u

rwfnc type 1 bmccxJt corrmer* I*

¡AuîoSe-îrth Down r _ IL

AuîôSeifiïi Up m

Char*?* îtanç* in

rt

freqjjp n zl

Perimeters

name tyoe j coonment

Il ratete

I Add

-a

À

ccrfi«.tatsxol Tool Setup [ Confia I >3"'^- Instant« [ UserFuncttons Lowing | Ими \ Datatypes f Run [

♦ 'TATGcrftgbits* ¡3\,L utmt.ru» | ^ CarRado.xfc j

Instances

IiHtwce

name I type | й | toymen*

lUitl tfn 1

Beil fiWeW 2

name typa [ sortottt» милИнЛНпя... *

.1 1 и

t.x<«.ta<[»<>: I It* setup <-«il.: 1 agiMti 11nйти ШЫъпОюк] Logging Маен» I DataT««|

Рис. 4. Настройка сущностей и сигналов

композиция инстанции; удаление невидимых сигналов из диаграмм; добавление конфигурационных сигналов; инициализация тестового приложения; генерация дополнительных конфигурационных файлов.

Перечисленные работы полностью автоматизированы с помощью специализированных скриптов.

Однако пользователю важна проблема создания цепочки запуска, т. е. последовательности исполнения инструментов тестирования, которая может быть различной для различных запусков тестового набора. В частности, сама система автоматизации тестирования TAT представляет набор подобных инструментов (модулей):

макропроцессор, позволяющий раскрывать макроподстановки, использованные в диаграммах тестов;

генератор абстрактного тестового набора, преобразующий тест на MSC в промежуточное платформонезависимое представление на скрип-товом языке tcl;

кодогенерирующий шаблон, позволяющий получить код теста на целевом языке программирования из промежуточного представления на tcl;

анализатор результатов тестирования, дающий возможность сбора статистики по исполненным тестам.

и др., в т. ч. вновь реализованные или третье-сторонние модули

Перечисленные модули служат компонентами процесса автоматизации тестирования и, в зависимости от задач пользователя, могут быть включены или исключены из цепочки автоматизации.

Для решения проблемы создания гибких цепочек запуска в интегрированной среде исполь-

Рис. 5. Запуск цепочки исполнения

зован механизм интеграции (склеивания) различных инструментов в общую последовательность. Пользовательский интерфейс запуска цепочки исполнения представлен на рис. 5. В рамках цепочки исполнения выполняются семь вспомогательных скриптов, затем управление передается на цепочку запуска модулей TAT для генерации теста на целевом языке, после чего происходит исполнение теста и анализ результатов.

При этом пользователь управляет запуском либо всей цепочки, либо ее части, вплоть до отдельного запуска любого из инструментов.

На рис. 6 представлен пользовательский интерфейс создания цепочки.

Рис. 6. Настройка цепочки исполнения

Рис. 7. Пользовательский интерфейс анализа результатов тестирования

В левой части рисунка представлен интерфейс по настройке отдельного инструмента в рамках цепочки. В качестве инструмента может быть использован как модуль системы автоматизации тестирования TAT, так и любой модуль стороннего разработчика.

Для настройки модуля пользователю необходимо указать имя модуля, которое будет использоваться для его идентификации в рамках цепочки, строку запуска, указывающую на расположение модуля и входные параметры, позволяющие его сконфигурировать. В правой части рисунка представлен интерфейс формирования цепочки. В рамках данного интерфейса пользователь может выбрать модуль из множества настроенных в системе модулей и добавить его в цепочку.

В интегрированной среде автоматизации пользователю предоставляется возможность:

перегруппировки моделей в рамках цепочки, что позволяет изменить последовательность их исполнения;

создания подцепочек, что дает возможность вторично использовать уже созданные цепочки.

Исполнение и анализ тестового набора. Исполнение тестового набора происходит на основе созданных цепочек. После предварительной об-

работки тестов и их генерации на целевой язык проводится компиляция тестового набора и его запуск. В результате запуска генерируется набор лог-файлов, которые облегчают пользователю анализ результатов. На рис. 7 изображен интерфейс, предоставляемый средой автоматизации тестирования для анализа результатов исполнения тестов.

В рамках данного интерфейса пользователь получает возможность просмотра статистики результатов проведенного тестирования, а также возможность анализа результатов каждого теста как в текстовом, так и в графическом (на MSC диаграмм) виде.

Представленная в статье интегрированная среда автоматизации тестирования на основе eclipse была апробирована в трех проектах из телекоммуникационной сферы. Результаты апробации показали, что использование среды позволяет существенно сократить время на настройку и адаптацию тестового набора, а также облегчить процесс анализа результатов исполнения тестового набора. Так, например, для тестового проекта CDMA было получено 20 % сокращение затрат на настройку тестового окружения.

СПИСОК ЛИТЕРАТУРЫ

1. Котляров, В. Основы современного тестирования программного обеспечения, разработанного на C# [Текст]/В. Котляров, Т. Коликова.

2. UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language [Электронный ресурс].

3. ITU Recommendation Z.120. Message Sequence Charts (MSC), 11/99 [Электронный ресурс].

4. Telelogic Tau TTCN Suite [Электронный ресурс] http://www.telelogic.com/products/tau/ttcn/ index.cfm

5. T-VEC Technologies [Электронный ресурс] http://www.t-vec.com/Home.asp

6. ISP RAS Red Verst [Электронный ресурс] http://www.ispras.ru/~RedVerst

7. Conformiq Software Ltd. [Электронный ресурс] http://www.conformiq.com/products.html

8. Веселов, А.О. Автоматизация тестирования телекоммуникационных приложений [Текст]/А.О. Веселов, А.С. Иванов, Б.В. Тютин, В.П. Котляров//Научно-технические ведомости СПбГПУ.-2009.-№ 3.

УДК 004.415

И.В. Никифоров, А.В. Петров, Ю.В. Юсупов

генерация формальной модели системы

ПО ТРЕБОВАНИЯМ, ЗАДАННЫМ В НОТАцИИ USE CASE MAP

Разработка программного продукта начинается с анализа требований, которым должна удовлетворять система, поскольку они разрабатываются вручную и им свойственны противоречивость, неполнота, недостаточная детальность и т. п. Для того чтобы на этапе проектирования требований более точно понять, как должна работать система, необходимо использовать описание архитектуры и поведения системы через диаграммы вариантов использования (UCM - Use Case Maps).

Формализуя высокоуровневый дизайн программной системы в нотации UCM, в результате получаем ее модель на формальном языке. Формальная модель позволяет применить математический аппарат верификации, получить спектр моделей различной детальности в процессе уточнений, а также имеется возможность автоматической генерации исполняемого кода из модели.

Верификация позволяет осуществить проверку корректности, полноты и непротиворечивости требований до этапа автоматической кодогенера-ции, что существенно снижает стоимость создания корректной исполнимой модели проектируемой системы.

В качестве языка описания формальной модели была выбрана нотация базовых протоколов,

используемая в теории взаимодействующих агентов и сред [1] для спецификации их поведения с помощью элементарных MSC диаграмм.

В статье описаны особенности использования языка UCM на этапе архитектурного описания проектируемой системы, автоматический переход от нотации UCM к формальной модели в виде базовых протоколов, средства проверки простых ошибок и описок ручной формализации, а также результаты применения разработанного подхода к разработке реальных проектов.

Use Case Maps

Варианты использования - это описание последовательности действий, которые может производить система в ответ на внешние воздействия пользователей или программных систем (компонентов). Варианты использования отражают функциональность системы с точки зрения описания архитектуры системы. Их применение привносит важные составляющие в процесс разработки программных систем [2]:

заполняет промежуток между словесным описанием требований и детальным дизайном системы;

позволяет разработать архитектуру системы на высоком уровне абстракции, а также за-