CC BY
32
критериев, входящих в совокупный крите- Предложенная методика позволяет сделать
рий (10), может быть расширен или изме- правильный выбор критерия качества тести-
нен, с учетом выбранного режима тестиро- рования, с наибольшим эффектом, и обнару-
вания или дополнительных ограничений. жить на ранних стадиях возможные риски.
СПИСОК ЛИТЕРАТУРЫ
I. Sun Performance Library User's Guide. Sun 2. Черноруцкий И.Г. Методы оптимизации
@ТМ Studio 12. http://docs.sun.com/source/819- и принятия решений. СПб.: "Лань", 2001. 5268/index.html.
УДК 004.415
Н.В. Воинов, В.П. Ко тля ров ВЕРИФИКАЦИЯ И АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ УМЬПРОЕКТОВ
В документах, описывающих требования к программному продукту, может содержаться большое количество ошибок различных типов, среди которых основные — ошибки несоответствия требований, доработанных и детализированных исполнителем с исходными требованиями заказчика. Неоценимую помощь в решении данного вопроса оказывает использование формальных языков и нотаций для создания требований, которые позволяют заказчику и разработчику вести диалог на одном языке и служат процессу искоренения различного рода двусмысленностей в спецификациях. В практике индустриального программирования все чаше используются формальные нотации и формальные методы контроля свойств программного продукта. Среди наиболее популярных формальных нотаций выделяется язык UML (Unified Modeling Language) [1], в котором интегрировано большинство изобразительных возможностей современных формальных спецификаций.
Одна из основных проблем, которую решают разработчики программного обеспечения (ПО), — проверка корректности его функционирования. Она начинается с разработки требований к проектируемой системе и продолжается до момента вывода системы из эксплуатации. Этим определяется повышение требований к полноте и
производительности подобных проверок, что приводит к появлению на рынке новых технологий и инструментария автоматизации контроля правильности функционирования ПО, включающего его верификацию и тестирование.
Несмотря на существование множества различных инструментов верификации (например, Spin от BellLabs, SCR от Naval Research, VRS и др. [2, 3)) и автоматизации тестирования (Rational Rose от IBM, Together от Borland), можно выделить две серьезные проблемы. Во-первых, сегодня практически нет промышленных технологий, позволяющих совместно использовать инструментарий тестирования и верификации. Особенно актуальна данная проблема для систем, у которых проверка корректности поведения связана с проверкой десятков и сотен тысяч сценариев за время, не превышающее предусматриваемые программным проектом сроки. Во-вторых, при верификации, т. е. при проверке на моделях (model-checking), когда строится модель системы и проверяются требования для каждого возможного состояния этой модели, используется некоторый формальный язык для построения модели системы. При этом процесс построения формальных спецификаций может оказаться весьма длительным и трудоемким.
В данной статье описана методика верификации и автоматизации тестирования UML-проектов, состоящая из автоматического построения верификационных моделей на языке базовых протоколов [4], полученных из UML-спецификаций, проверки полученных моделей с помощью верификационной технологии VRS [5], а также автоматической генерации тестов на языке TTCN [6] средствами инструментария TAT (Test Automation Toolset) [7]. Кроме того, представлены результаты применения методики в проекте из области телекоммуникаций.
Лвтоформализация UIYIL спецификаций.
Чтобы использовать возможности VRS для верификации, сначала необходимо описать требования или спецификацию системы в виде набора базовых протоколов. Ручное создание такого описания — очень трудоемкая задача и может сравниться по этому показателю с ручной разработкой тестов. В определенных случаях процесс формализации может быть значительно ускорен путем автоматического создания базовых протоколов из начальных спецификаций. Такой подход называется автоформализацией.
В тех проектах, где спецификация системы представлена в виде графа переходов, соответствующий набор базовых протоколов может быть получен автоматически с помощью специально разработанного инструмента — модуля VRS uml2bp. Данный модуль для каждого графа переходов в проекте Telelogic Tau G2 формата .ttp создает набор базовых протоколов, а также файлы окружения и сигналов, необходимых для описания проекта в VRS. Полученные файлы импортируются в VRS для процесса верификации.
Верификация средствами VRS. Процедура проверки требования — это формулировка последовательности наблюдаемых причин и следствий некоторых событий. После анализа этой последовательности можно сделать вывод о том, удовлетворяется требование или нет. Такая процедура может быть принята за критерий покрытия определенного требования и для ее обозначения использован термин "цепочка".
После того, как в поведенческом сценарии модели системы установлен факт покрытия критерия, можно утверждать, что соответствующее требование покрывается также и в анализируемой системе.
Процедура покрытия требования (цепочка) задается формулировкой всех ее элементов: начальных условий (причин), требуемых для выполнения определенной активности, самой активности и наблюдаемых результатов выполнения соответствующей активности.
В определенных случаях для описания причин и результатов активностей могут использоваться состояния переменных (в виде их значений или ограничений на диапазон допустимых значений). Эти переменные используются для перехода из одного состояния в другое. В случае недетерминизма возможно несколько вариантов переходов. Прямой переход из одного состояния в другое возможен также и без активностей.
Таким образом, цепочка с последовательностью активностей и состояний может служить критерием выполнимости требования, достаточным для его демонстрации. Недетерминизм в формулировках также покрывается набором цепочек.
Реализация этапа верификации.
Шаг /. После того, как получены наборы базовых протоколов, файлы с описанием окружения и сигналов, осуществляется создание фильтров и эвристик для конкретного проекта. Они позволяют сократить число трасс, указывая трассовому генератору направление поиска.
Шаг 2. Осуществляется цикл автоматической генерации трасс.
Шаг 3. Анализ найденных в поведении модели дефектов, в том числе тупиков, неполноты описания и других проблем, которые не позволяют завершить генерацию трасс в конечном состоянии. Исправление ошибок и их обсуждение с разработчиками. На основании результатов обсуждения осуществляется правка базовых протоколов или начальных требований. Повтор шагов 1—3.
Шаг 4. Анализ полученных трасс с помощью специального модуля, чтобы определить, удовлетворяется ли критерий
покрытия требований. При необходимости повтор шагов 1—4.
Из множества полученных трасс выбираются те. для которых требуется автоматически сгенерировать тесты средствами TAT.
Ручное создание трасс в VRS. Технология позволяет создавать трассы вручную, путем фиксации последовательности искомых базовых протоколов в процессе пошаговой генерации (на каждом шаге генерации пользователь сам выбирает базовый протокол из списка доступных). Данный подход позволяет покрыть конкретный сценарий поведения модели на различных уровнях абстракции.
На рис. 1 приведен пример UML-диаг-раммы графа переходов.
Его основные части — четыре композитных состояния (Suspended. UDILDI, UEI_LEI. UEA) и переходы между ними. Каждое композитное состояние в свою очередь представляет собой граф переходов со сложным поведением внутри.
Модуль uml2bp позволяет получить набор базовых протоколов для всего графа переходов. Базовые протоколы импортируются в VRS для анализа модели.
На основании полученного набора базовых протоколов может быть построен граф модели. На рис. 2 изображен граф без описания детального поведения четырех композитных состояний.
Есть возможность раскрыть любое композитное состояние для изучения его детального поведения. На рис. 3 изображен тот же граф, но уже с подробным описанием поведения состояния Suspended.
Поведение модели на графе представляется в виде набора состояний (овалов) и переходов между ними. Каждый переход осуществляется базовым протоколом. Таким образом, в соответствии с графом можно сконструировать собственную трассу на любом уровне абстракции (с описанием детального поведения или без) для всех композитных состояний и для всего начального графа переходов. На рис. 4 изображены трассы, покрывающие поведение начального графа без описания детального поведения отдельных состояний и одно из возможных поведений состояния Suspended соответственно.
Две данные трассы могут быть совмещены: вторая трасса может быть вклеена в то место первой, где состояние Suspended покрывается как композитное, т. е. без де-
Рис. I. Пример UML-диаграммы графа переходов
Рис. 2. Граф переходов с композитными состояниями
UEI_LEI
Рис. 3. Граф переходов с детальным поведением состояния Suspended
\
\ V
Suspended
UDI LDI
v
Start
Рис. 4. Примеры трасс, покрывающих поведение модели
тального описания его поведения. Склейка трасс изображена на рис. 5.
Трассы, полученные таким способом, также могут быть использованы для автоматической генерации тестов.
Автоматизация тестирования средствами TAT. Рассматриваемая методика предназначена для автоматической генерации тестов на стандартном языке тестирования телекоммуникационных приложений — TTCN (Testing and Test Control Notation). Предлагаемый подход позволяет исключить ручную разработку и сосредоточить усилия те-
стировшиков исключительно на сценариях тестирования, что ускоряет процесс тестирования и фиксации ошибок.
Методика поддерживается системой скриптов и шаблонов автоматической генерации результирующих ТТС^-файлов, использующих вспомогательные файлы описания типов данных, описания шаблонов сигналов, описания конфигураций и т. п.
Генерация тестов базируется на использовании двух входных файлов: непосредственно трассы (сценария) с сигналами и их параметрами и .х15 файла, где перечислены
<
<
<5
<r С
г _>
с
»Kl a»l.i>
ödtZ>
Ш1 сМч» toiC IX'Jl ttfll71U~frw4 t» t- III '•^UUrJ
,.., MI.»
553
■ fr Цт ^л LI«} MPU
SP'.
«au 1Х7Л адзпш
[JXXCMJJ9_U)»tni««U»Mur 04.I> s*
juyng
Gr
uz
ü>
|»иа»/ЙЙд5££Г||| -I.ii .>
«i »л uxrp_ ¡.X*a__i. □ у .
I.f| *C\.l>
IfrMUMw »^ü&Ii^yci.ti -
[•. ji. яоашйяЗлл. roftUktm ||
<шк ie«w* \
H4>13bp_c*i>yroeLtaoD7fMo*>f»«.,r 0Ы.1>
[m»uJ • ■ИОГсиду «1 »fl.CfpCy>e*;lxüftOU»_b,>n>St»tu»It.«t._Hca«_ifU - üMUCIn
•«Uftt.taY СМ ■.frj- rrp-x im::»k.ort'/: s»t»uc cei.r.
IUIU1 CDU) III
>
<
!.«)>_UOI_cmu>l*i>atifl*r*rB-.f nitt.l)
UJdlaclL mt«it«4
■.•, map*
-s
IM . /
Рис. 5. Склейка трасс
значения параметров сигналов, представленных на трассе.
Процесс генерации тестовых сценариев включает в себя несколько этапов:
автоматическая генерация описаний функций, которые обеспечивают доступ к тестируемому приложению в соответствии с сигналами в диаграмме. Сгенерированный файл с описаниями функций доступа фиксируется в тестовом проекте. В результате в самом тестовом сценарии используются только вызовы этих функций доступа;
присвоение параметрам в исходной диаграмме конкретных значений. Значения берутся из .xls файла, прилагаемого к исходной UML-диаграмме. Заполнение MSC-файла значениями параметров происходит автоматически: генерация тестового набора из MSC-файла с подставленными значениями параметров реализуется непосредственно TAT. в котором используется шаблон, специализированный на генерацию TTCN тестов;
генерация дополнительного ТТС1М-фай-ла, выполняющего запуск тестовых наборов на исполнение.
Все полученные файлы фиксируются в тестовом проекте. После компиляции и сборки проекта возможен прогон тестов в автоматическом режиме. Результаты тестирования сохраняются в 1о§-файле.
Результаты применения методики. Разработанная методика применена при создании модуля телекоммуникационного проекта беспроводной сети. Оценка общего объема модели сети составляет -50000 базовых протоколов.
На этапе автоформализации пилотируемого модуля получено около 4000 базовых протоколов, на генерацию которых потребовалось несколько минут работы модуля ит12Ьр. Учитывая, что производительность ручного создания базовых протоколов оценивается в 10—50 протоколов в день, можно сделать вывод о существенной экономии времени.
Этап верификации исходной иМЬ-мо-дели позволил выявить порядка 100 неточностей, 12 из которых разработчиками были признаны дефектами, исправленными в последующих версиях продукта.
Этап автоматической генерации тестов занимает несколько минут, что значительно меньше времени на ручную разработку. Даже учитывая затраты, необходимые на разработку иМЬ-диаграммы (в случае отсутствия готовой спецификации тестового сценария) и .х15 файла для настройки кон-
кретного тестового прогона, выигрыш по времени на получение только одного ТТСЫ-теста в соответствии с предложенной методикой составляет несколько часов.
Разработанная методика верификации и автоматизации тестирования доказала свои преимущества в крупном телекоммуникационном проекте и может быть в дальнейшем переиспользована во многих других проектах, поддерживающих иМЬ-проекти-рование.
СПИСОК ЛИТЕРАТУРЫ
1. U ML Distilled Second Edition. A Brief Guide to the Standard Object Modeling Language.
2. Visser W., Havelund K., Brat G., Park S. and Lcrda F. Model checking programs // Automated Software Engineering Journal, 10(2), April 2003.
3. Fernandez J.-C., Jard C., Jeron Th. and Viho C. Using on-the-fly verification techniques for the generation of test suites // Proc. 8th Conference on Computer Aided Verification, volume 1102 of Lecture Notes in Computer Science, New Brunswick, August 1996.
4. Летнчевский A.A., Капитонова К).В.. Jle-тичевский А.А. (мл.) и др. Спецификация систем с помощью базовых протоколов // Кибернетика и системный анализ. 2005. № 4. С. 3—21.
5. Letichevsky A., Kapitonova J., Ixtichevsky A Jr., Volkov V., Baranov S., Kotlvarov V., Weigert T. Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications. Proc of ISSRE04 Workshop on Integrated-reliability with Telecommunications and UML Languages (ISSRE04:WITUL), 2 Nov. 2004:1RISA Rennes France.
6. ITU-T Recommendations Z. 140—142 (2002): The Testing and Test Control Notation Version 3 (TTCN-3).
7. Kotlyarov V., Drobintsev P., Peskov D., Yusupov Y. Implementation of an Integrated Verification and Testing Technology in Telecommunication Project // Proc. of St. Petersburg IEEE Chapter. International Conference, May 18-21, St. Petersburg. Russia, 2005. P. 87-92.
УДК 004.4*2
Д.А. Григорьев
РАЗРАБОТКА И ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ АСПЕКТНО-ОРИЕНТИРОВАННОЙ СРЕДЫ ПРОГРАММИРОВАНИЯ ДЛЯ ПЛАТФОРМЫ MICROSOFT.NET
В традиционных объектно-ориентированных программах актуальной является задача декомпозиции компонентов по "сквозной" функциональности, реализация которой рассредоточена сразу по нескольким уровням системы. Примерами такой функциональности могут служить протоколирование событий, авторизация и управление безопасностью, обработка транзак-
ций и т. п. С помощью объектно-ориенти-рованного программирования (ООП) [1] можно достаточно подробно описать понятия предметной области. При этом, однако, одну и ту же задачу необходимо отдельно решать для каждого уровня абстракции архитектуры.
Применение шаблонов проектирования ООП характеризуется тем, что необходимо [I]
