CC BY
26
сорных ядер). Для управления модулем визуализации можно использовать интерактивную среду программирования REPL.
Система визуализации опробована на графе сети Петрозаводского государственного университета (ПетрГУ). Сетевая структура ПетрГУ представлена 4551 объектом SON, включая 1349 объектов сетевых устройств. Система визуализации позволила исследовать структуру сети ПетрГУ в интерактивном режиме.
Библиотека Indyvon составляет 1333 строки кода, исключая пустые строки и комментарии, модуль визуализации - 1650 строк кода.
Представлен метод визуализации, основанный на использовании предметно-ориентированного языка для описания преобразования объектов трехструктурной модели архитектуры организации в граф интерактивных визуальных объектов
и программная реализация метода в виде модуля экспериментальной платформы Nest.
Для работы с интерактивными визуальными объектами разработана библиотека Indyvon, базовые элементы интерфейса которой не имеют состояния, что позволяет строить динамические интерфейсы с большим числом интерактивных элементов и обеспечивает многопоточное выполнение. Функции и макроопределения библиотеки, обеспечивающие простое построение интерактивных объектов, составляют часть предметно-ориентированного языка визуализации.
Основной интерес для дальнейшего исследования представляет интеграция в систему визуализации различных дополнительных динамических данных о работе Сети: информация о потоках, информация регистрационных файлов различных сетевых служб, изменения графа Сети во времени.
СПИСОК ЛИТЕРАТУРЫ
1. Report of NSF Workshop on Network Research Testbeds. 2002 [Электронный ресурс] / Режим доступа: http://www-net.cs.umass.edu/testbed_workshop/testbed_ workshop_report_final.pdf
2. IBM Corp. IBM Tivoli Network Manager Version 3.7 Topology Visualization Guide, 2007 [Электронный ресУРс].
3. Ellson, J. Graphviz and dynagraph — static and dynamic graph drawing tools [Текст] / J. Ellson, E.R. Gansner, E. Koutsofios [et al.] // GRAPH DRAWING SOFTWARE. -Springer-Verlag, 2003. -P. 127-148.
4. Bastian, M. Gephi: An Open Source Software for Exploring and Manipulating Networks [Электронный ресурс] / M. Bastian, S. Heymann, M. Jacomy. -Режим доступа: http://www.aaai.org/ocs/index.php/ICWSM/09/ paper/view/154
5. Крышень, М.А. Проект Nest: структурное представление системы поставщика сетевых услуг [Текст]/ М.А. Крышень, А.С. Колосов, А.С.
Тидор, Ю.А. Богоявленский // Матер. межвуз. конкурса-конф. студентов, аспирантов и молодых ученых Северо-Запада «Технологии Microsoft в теории и практике программирования». -СПб.: Изд-во СПбГПУ, 2008. -C. 49-51.
6. Крышень, М.А. Объектное представление и визуализация структуры поставщика сетевых услуг [Текст] / М.А. Крышень, А.С. Колосов, Ю.А. Богоявленский // Труды XV Всерос. науч.-метод. конф. Телематика 2008. -СПб.: 2008. -Т. 1. -С. 168-169.
7. Fruchterman, T.M.J. Graph drawing by force-directed placement [Text] / T.M.J. Fruchterman, E.M. Reingold // Softw. Pract. Exper. -1991. -Vol.21. -№11. -P. 1129-1164.
8. Hu,Y. Efficient and high quality force-directed graph drawing [Text] / Y. Hu // The Mathematica J. -2005. -Vol. 10. -P. 37-71.
9. Barrett,S. Immediage Mode GUIs [Text] / S. Barrett // Game Developer. -Sept. 2005. -P.34-36.
УДК 004.415
П.Д. Дробинцев, Р.И. Ким, В.П. Котляров
АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ СИМВОЛИЧЕСКИХ ТРАСС
В современном процессе разработки про- зуются методы верификации. Это связано с ра-граммного обеспечения (ПО) активно исполь- стущей сложностью разрабатываемого ПО, что
4
приводит к невозможности использования для обеспечения качества только методов традиционного тестирования. В то же время в связи с применением программных комплексов в проблемных областях, критичных к надежности, требования к качеству производимого ПО постоянно растут. Применение верификации позволяет гарантировать высокое качество продукта за счет детальной проверки функциональности разрабатываемых систем в различных условиях применения, сокращая при этом трудозатраты на этапе проектирования. Настоящая статья посвящена описанию технологии генерации символических трасс, получаемых в процессе верификации модели программы, а также их использования в процессе автоматизации тестирования.
Верификация модели приложения
Использование верификации в процессе разработки ПО позволяет обнаружить дефекты, которые могут быть пропущены в процессе традиционного тестирования. Это связано в первую очередь с тем, что для полной проверки разрабатываемого приложения необходимо выполнить огромное количество тестов на различных наборах данных, что вряд ли осуществимо на практике. В то же время методы верификации дают возможность статической проверки модели системы, что позволяет оперировать огромными пространствами состояний в ходе анализа. Следует отметить, что верификация проводится на этапе дизайна до момента разработки кода приложения, т. к. она основана на построении и анализе модели будущего ПО, таким образом, потенциальные дефекты могут быть обнаружены еще до начала стадии кодирования, что существенно сокращает затраты на их исправление [1]. В настоящее время известны различные подходы к верификации программ. Среди них - методы проверки на модели (model checking) [2] и дедуктивные методы (deductive methods).
Проверка на модели - это автоматический метод верификации последовательных и параллельных систем с конечным числом состояний. Основная парадигма метода - перебор состояний модели системы с целью поиска состояний, в которых не соблюдается определенное пользователем свойство. Главная проблема применения методов проверки на модели - эффект «комбинаторного взрыва» в пространстве состояний. Эта проблема на практике особенно проявляется
в системах, состоящих из десятков и сотен взаимодействующих компонент, а также в системах, обладающих сложными структурами данных, способными принимать большое количество значений. В таких системах количество глобальных состояний может оказаться настолько велико, что времена доказательства при верификации становятся малореальными. За последнее десятилетие в области усовершенствования методов проверки на модели был достигнут существенный прогресс, связанный с представлением моделей в виде BDD (Binary Decision Diagram). Однако в общем случае время на проверку промышленного программного комплекса остается неприемлемо большим, что приводит к ограничению (упрощению) верифицируемых моделей и к росту вероятности пропуска ошибок.
Дедуктивный анализ ориентирован на верификацию символических моделей, что подразумевает применение аксиом и правил вывода для доказательства правильности функционирования системы. На ранних этапах исследований приложений дедуктивного анализа основное внимание уделялось доказательству правильности работы небольших, но критичных для функционирования всей системы компонент. При этом время анализа не ограничивалось, поэтому разработчик или эксперт, в роли которого часто выступал математик или логик, мог проводить подобные доказательства даже вручную. Современные условия производства сильно ограничивают время фазы проектирования, поэтому инструментальные средства автоматизированы и адаптированы на направленный перебор различных путей продолжения доказательства из текущего состояния.
Следует отметить, что как при использовании методов проверки на модели, так и при использовании дедуктивных методов, доказывается правильность поведения не самого ПО, а его модели, созданной с использованием того или иного математического аппарата. Верификация на моделях позволяет обнаруживать возможные дефекты на ранних стадиях разработки и вносить необходимые корректировки, однако для проверки поведения приложения необходимо проводить эксперименты над кодом, для чего использовать методы тестирования. Таким образом, верификация и тестирование являются взаимно дополняемыми подходами в процессе обеспечения гарантии качества.
Интеграция верификации и тестирования
крупных программных комплексов возможна при проведении тестирования на основе результатов верификации. В рамках подобного тестирования проверяются не все варианты поведения системы, а лишь те, что были выделены в процессе верификации по определенному критерию.
Для использования результатов верификации в тестировании они должны быть представлены в виде, пригодном для создания тестов. Наиболее распространенной формой представления результатов в современных инструментах служат событийные сценарии или последовательности состояний системы и воздействий, переводящих одно состояние в другое. Такие последовательности называются поведенческими трассами или сценариями. В случае поиска с помощью верификации множества путей поведения, покрывающих некоторую функциональность системы, результат представляется в виде множества трасс.
В настоящее время большинство инструментов верификации предоставляют возможность получения результатов в виде трасс, описанных на одном из известных языков спецификаций (MSC [5], UML [6]). При этом поведение, описываемое трассой, содержит всю информацию, необходимую для генерации теста (конкретные значения параметров передаваемых системе сигналов, значения переменных и т. п.). Подобная трасса называется конкретной. При использовании конкретных трасс для генерации тестов наиболее существенной проблемой остается проблема «комбинаторного взрыва», т. к. количество конкретных трасс, сгенерированных системой верификации, огромно, и прогнать каждую из них в
виде теста не всегда представляется возможным. Для решения данной проблемы используются символические трассы, которые объединяют совокупность поведений системы и содержат символические, а не конкретные значения, определяющие заданное поведение.
Символические трассы и области толерантности
Символическая трасса - это сценарий поведения системы, объединяющий множество конкретных трасс, эквивалентных по управлению, и содержащий диапазоны значений переменных, для которых поведение системы будет лежать в рамках описанной трассы. Основное преимущество символической трассы перед трассой с конкретными значениями - существенное сокращение количества вариантов поведения системы, подлежащих рассмотрению на фазе тестирования, за счет объединения композиции множества поведений, основанной на доказательстве их поведенческой эквивалентности. Следует также отметить, что символическая трасса, полученная с использованием верификации, позволяет утверждать, что поведение системы после подстановки любого конкретного значения, лежащего в диапазоне, будет описывать доказанное в рамках трассы поведение системы.
Ряд современных инструментов верификации позволяет получать символические трассы как результат проведения фазы верификации. Одним из подобных инструментов является VRS (Verification of Requirements Specification) [3]. На рис. 1 и 2 использованы результаты, полученные
Рис. 1. Пример описания свойства ПО
4
VRS в процессе при верификации промышленного проекта.
На рис. 1 приведено конечно-автоматное представление свойств, содержащихся в требовании к программной системе, встроенной в автомобиль и контролирующей наличие пристегнутого ремня безопасности. В требовании задано, что при значении переменной Current_Speed больше 20 и отсутствии клипсы ремня в устройстве должен раздаваться звуковой сигнал, предупреждающий об опасности, при условии, что скорость автомобиля ограничена 250 км/ч.
Из рисунка видно, что находясь в состоянии idle, система может получить сигнал check_speed и в зависимости от результатов проверки перейти в состояние check_done или в состояние alarm, в котором возникает необходимость подачи звукового сигнала.
Если ограничить поведение системы только наличием описанного свойства, то с использованием системы верификации мы можем получить как 230 трасс с конкретными значениями параметра Current_Speed при превышении порога в 20 км/ч и 20 трасс без его превышения (при
условии, что скорость имеет тип integer и может изменяться на единицу), так и две эквивалентные символические трассы. На рис. 2 приведены две символические трассы, первая из которых представляет набор эквивалентных поведений, где описывается поведение без превышения допустимой скорости, а вторая - поведение при необходимости выдавать сигнал предупреждения.
С точки зрения тестирования при использовании трасс с конкретными значениями параметров мы имеем 250 вариантов тестов для каждого значения параметра, а также несколько тестов, проверяющих нарушение границ в 250 и нуль, например, задав значение скорости минус 1 и 251. Перебор всех вариантов для полного тестирования такого элементарного примера достаточно проблематичен. С другой стороны, в символических трассах мы получаем доказанные при верификации диапазоны значений переменной (области толерантности). В рамках этих областей поведение системы доказано, это диапазоны 21 ^ 250 и 0 ^ 20. Таким образом, для полного тестирования поведения системы необходимо сгенерировать всего четыре теста: один будет содержать значение из первого
Рис. 2. Символические трассы поведения системы
Рис. 3. Технология автоматизации тестирования (I I) исходные данные; (I I) инструментарий
диапазона, второй - из второго диапазона, а также тесты, выходящие за рамки диапазонов. Применение интегрированного подхода верификации и тестирования с использованием символических трасс в реальных промышленных проектах приводит к сокращению тестовых наборов на порядки без потери качества тестируемого приложения.
Генерация тестового набора
Использование сгенерированных в рамках верификации символических трасс для генерации тестов, исполняемых на готовом ПО, требует для каждого цикла тестирования автоматизации подстановки конкретных значений в параметры входных воздействий. На рис. 3 представлена технологическая цепочка автоматизации тестирования.
Процесс тестирования с использованием символических трасс и областей толерантности использует следующие этапы.
1. Анализ данных, полученных с помощью инструментария VRS. На данном этапе автоматически выделяются все области толерантности переменных, входящих в параметры входных воздействий на систему, с целью их дальнейшего использования для подстановки конкретных значений.
2. Автоматическое построение конфигурационного файла, содержащего следующие данные о параметрах: значения параметров на границах допустимых значений и за их границами. Значения разделяются на следующие категории: значения на границе, значения за границей допустимого
диапазона и значение внутри диапазона. Таким образом, по одной символической трассе можно автоматически получить по пять трасс для каждой области толерантности переменной типа integer и по две трассы для переменной перечислимого типа.
3. Автоматическое построение конкретизированных трасс для цикла тестирования. Данные из конфигурационного файла подставляются в исходную символическую трассу с целью получения трасс с конкретными значениями.
4. Тестирование модели с помощью инструмента автоматизации тестирования TAT [4]. Данный инструментарий преобразует полученную трассу в тест на целевом языке и позволяет провести его исполнение и анализ результатов.
Применение технологии, основанной на генерации и анализе символических трасс, позволяет существенно сократить количество тестов, которые необходимо выполнить в процессе тестирования и избежать проблемы «комбинаторного взрыва». При этом за счет использования средств верификации качество конечного кода приложения остается на заданном уровне, т. к. все поведения в рамках символической трассы доказаны системой верификации. Использование рассмотренной технологии хорошо зарекомендовало себя в рамках ряда промышленных проектов по разработке сложных телекоммуникационных комплексов.
Работа частично поддержана грантом РФФИ 11-07-90412-Укр_ф_а.
СПИСОК ЛИТЕРАТУРЫ
1. Barry, W. Boehm Characteristics of software quality [Текст] / W. Barry. -North-Holland Pub. Co, 1978.
2. Кларк, Э.М. Верификация моделей программ: Model Checking [Текст] / Э.М. Кларк, О. Грамберг, Д. Пелед. -МЦНМО, 2002.
3. Letichevsky, A. Basic Protocols, Message Sequence Charts and the Verification of Requirements Specifications [Текст] / A. Letichevsky, J. Kapitonova, A.(Jr). Letichevsky, V. Volkov, S. Baranov, V. Kotlyarov [et al.]. -ISSRE 2004, WITUL. -Rennes, 04.11.2005. -P. 30-38.
4
4. Веселов, А.О. Автоматизация тестирования в 5. Recommendation ITU-T Z.120. Message Sequence
области телекоммуникаций [Текст] / А.О. Веселов, В.П. Chart (MSC), 11/2000 [Электронный ресурс]. Котляров// Научно-технические ведомости СПбГПУ 6. [Электронный русурс] / Режим доступа: http://
-2010. -№4(103). -С. 180-185. www.uml.org/
УДК 004.415
И.В. Никифоров, А.В. Петров, Ю.В. Юсупов, В.П. Котляров ПРИМЕНЕНИЕ МЕТОДИК ФОРМАЛИЗАцИИ
для построения верификационных моделей систем
по ucm-спецификациям
Современные тенденции в создании качественного программного обеспечения (ПО) заключаются в более детальном анализе исходных требований и применении высокоуровневого дизайна системы на ранних этапах разработки. Это связано с тем, что наиболее дорогостоящими являются ошибки этапов анализа требований и дизайна, поэтому актуальна идея выявления и исправления ошибок на ранних стадиях процесса создания ПО.
Проектирование требований связано с выделением целей, функций и ограничений на систему. В нем выделяются задачи сбора и формализации требований, согласования формализации с заказчиком, моделирования проблемы, проверки полноты и непротиворечивости требований. Известен ряд промышленных инструментов [6, 9], позволяющих частично решать перечисленные выше задачи, основной недостаток которых -ориентация либо на прозрачную для пользователя формализацию, либо на доказательство корректности требований, сформулированных в алгебраической нотации.
Наиболее удачное решение перечисленных задач найдено в интеграции инструментов формализации (jUCMNav [7]), верификации (VRS [1]) и транслятора нотаций формализации в нотацию верификации (UCM2BP [3]).
Нотация формализации Use Case Map (UCM) [5] позволяет структурно изображать сценарии поведения разрабатываемой системы в удобной и понятной пользователю и заказчику графической форме. Исследуя модель системы в нотации UCM, разработчик может определить визуально
проблемные места в архитектуре, обнаружить ошибки и внести соответствующие изменения, разрешающие выявленные проблемы как в исходных требованиях, так и в рассматриваемой модели.
Ручной анализ модели по сравнению с автоматическим для реальных проектов, как правило, неприемлем, поэтому в статье приведено решение задачи преобразования модели системы в нотации UCM в модель, пригодную для автоматической верификации и тестирования (модель VRS - проект из базовых протоколов [2]).
Use Case Map - язык формализации
Нотация UCM [8] достаточно проста и содержит ограниченный набор элементов, предназначенных для спецификации поведенческих сценариев разрабатываемых систем. К элементам UCM-диаграмм относятся: компоненты Team, задающие на диаграмме объект исследования или наблюдения; элементы Responsibility, отображающие выполнение каких-либо действий; StartPoint и WaitingPlace, используемые для задания начальной точки сценария и точки ожидания соответственно, когда дальнейшее исполнение возможно после наступления некоторого события или выполнения условия, и др. Используя элементы UCM-нотации можно задавать линейные или параллельные сценарии (AndFork) поведения с последующей их синхронизацией (AndJoin). Элемент FailurePoint участвует в описании механизма генерации и обработки исключений. Элемент Timer используется для задания системного таймера как для случаев простой временной задерж-
