CC BY
24
в теории и практике программирования. 16-17 марта 2010. -СПб.: Изд-во Политехнического ун-та, 2010. -С. 161-162.
6. Летичевский, А.А. Спецификация систем с помощью базовых протоколов [Текст] / А.А. Летичевский, Ю.В. Капитонова, А.А. Летичевский (мл.) [и др.] // Кибернетика и системный анализ. -2005. -№4. -С. 3-21.
7. Воинов, Н.В. Применение метода эвристик для создания оптимального набора тестовых сцена-
риев [Текст] / Н.В. Воинов, В.П. Котляров // Научно-технические ведомости СПбГПУ Сер. Информатика. Телекоммуникации. Управление. -2010. -№ 4 (103). -С. 169-174.
8. Дробинцев, П.Д. Автоматизация тестирования на основе покрытия пользовательских сценариев [Текст] / П.Д. Дробинцев, В.П. Котляров // Научно-технические ведомости СПбГПУ. Сер. Информатика. Телекоммуникации. Управление. -2012. -№ 4 (152).
УДК 004.4'22
Б.В. Тютин, И.В. Никифоров, В.П. Котляров
ПОСТРОЕНИЕ СИСТЕМЫ АВТОМАТИЗАЦИИ СТАТИЧЕСКОЙ И ДИНАМИЧЕСКОЙ ПРОВЕРКИ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ПРОДУКТУ
При создании программного продукта по мере детализации его архитектуры объем требований к нему увеличивается. Детализация спецификации требований, ее изменение и расширение приводят к существенным временным затратам на поддержание целостности и однозначности содержащейся в ней информации. Методы статического анализа проверяют сами требования, тогда как методы динамического анализа проверяют соответствие реализации программного продукта требованиям, их адекватность поставленной задаче и существующим ограничениям. Полнота и качество анализа требований играют ключевую роль в успехе проекта [1]. К статическим методам контроля требований принадлежат верификация и контроль семантики формализации, к динамическим - тестирование.
Таким образом, возможность использования тестовых наборов различной детализации и их параллельное выполнение позволят проводить тестирование на всех этапах разработки продукта. Автоматизация тестирования в данной ситуации существенно снижает затраты на его реализацию. Поддержка взаимосвязи между тестовыми сценариями и требованиями дает возможность в режиме реального времени адаптировать процесс тестирования в случаях изменения спецификации.
Цель работы. Основная цель работы состоит в создании технологии автоматизированного
тестирования многокомпонентного программного продукта с помощью системы тестирования, имеющей распределенную структуру и позволяющей производить автоматическое исполнение тестов с учетом архитектуры тестируемой системы. Тестовый набор создается путем проверки формальной модели системы с помощью символьного верификатора, тем самым обеспечивается его корректность и покрытие требуемых свойств.
В рамках данной технологии тестовые наборы получаются на основе формального представления системы, создаваемого вручную с помощью инструмента UCM Specification Translator (UST) и Verificator of Requirement Specification (VRS). Система тестирования TestCommander используется для автоматической генерации исполняемого кода и управления тестированием.
Формализация требований. Для обеспечения возможности однозначной интерпретации требований при создании тестового набора необходимо из неявного или неформального вида преобразовать их в нотацию, обеспечивающую смысловую инвариантность при работе со спецификацией системы. При этом требуется, чтобы она была удобна для восприятия и редактирования человеком. Выбранная категория задач тестирования также требует возможности описывать параллельные взаимодействия. Этим требованиям отвечает Use Case Map (UCM) нотация,
4
Рис. 1. UCM диаграмма для телекоммуникационного проекта
стандартизованная в ITU-T в 2003 г. [2]. UCM представляет собой набор связанных и структурированных диаграмм, каждая из которых состоит из последовательности UCM элементов. В совокупности набор диаграмм задает возможные поведения системы, описанные в требованиях [4]. На рис. 1 приведен пример UCM диаграммы, описывающий часть телекоммуникационного протокола.
В отличие от стандартных средств редактирования UCM, UST поддерживает возможность работы с потоком данных, задания точек отправки и приема сигналов и добавления условий ветвления и прерываний посредством работы с грамматикой метаданных. Информация из метаданных используется при формализации и полностью отображается в модели системы. Так же была добавлена возможность описания окружения системы, которое содержит начальные значения и атрибуты компонент.
Для автоматического перехода от высокоуровневого дизайна, заданного в нотации UCM, к формальному описанию на языке базовых прото-
колов [6], используется транслятор ^Т (рис. 2). К особенностям UST можно отнести: анализ иСМ на наличие ошибок; оптимизации генерируемой модели в нотации базовых протоколов; структурирование модели по компонентам, позволяющее проводить верификацию и генерацию тестов, абстрагируясь от отдельных частей системы [7].
С помощью данного инструмента происходит построение иСМ модели системы, внесение необходимых метаданных в модель и ее трансляция в нотацию базовых протоколов. Разработанный иСМ проект проверяется модулем ^Т для анализа формальной модели на наличие ошибок, по-
¡SUT
Рис. 2. Общий вид технологической цепочки
сле чего происходит их исправление. Затем, используя UST, пользователь проводит настройку опций трансляции и выбор метода генерации. После трансляции полученный набор базовых протоколов импортируется в символьный верификатор VRS, в котором происходит верификация модели и генерация символьных сценариев, покрывающих модель по заданному критерию [10]. Полученный таким образом набор MSC диаграмм конкретизируется с помощью внесения реальных значений данных и может использоваться в качестве описания тестового набора или для визуализации свойств и поведения системы.
Автоматизация тестирования. Для осуществления проверки системы на соответствие требованиям необходимо обеспечить контролируемый процесс запуска тестов и анализа их результатов [5]. Для этих целей создана система автоматизации тестирования TestCommander. С ее помощью на основании тестовых сценариев, записанных в нотации MSC [3], автоматически создаются приложения на одном из целевых языков программирования (C++, Java, скриптовые языки). На этапе исполнения они взаимодействуют с тестируемой системой и друг с другом посредством заранее определенных интерфейсов, воспроизводя заложенные в тестовый набор сценарии поведения. Для автоматизированного построения тестового набора в рамках данной работы предлагается технологическая схема, представленная на рис. 2.
Являясь объединением методов формализации требований и генерации поведенческих трасс на основе модели базовых протоколов [9], данный подход позволяет объединить управление требованиями, верификацию и тестирование. При этом автоматически созданные поведенческие сценарии описывают взаимодействие всех сущностей системы и ее окружения.
В TestCommander допускается использование любого способа создания MSC диаграмм. Рассматриваемый в статье метод обладает следующими преимуществами:
автоматизацией рутинных этапов работы;
простотой и ориентированностью на системного аналитика используемых формальных нотаций;
применением методов и средств верификации для проверки требований [6].
Тестовый набор состоит из одного управляющего и нескольких тестирующих модулей. Тестирующий модуль взаимодействует с тестируемой системой (system under test или SUT) согласно ло-
гике теста и обменивается контрольными сигналами с управляющим модулем, руководящим тестированием и сбором результатов. Для определения протокола взаимодействия между элементами тестирующей системы, а также самой тестирующей системы с окружением, используется язык спецификации протоколов (Protocol specification language, PSL). Он позволяет задать вид сообщений, которыми обмениваются участвующие в тестировании сущности. В рамках рассматриваемого в данной статье подхода предполагается ручное создание спецификации на языке PSL.
Для конфигурирования тестового набора, задания параметров генерации кода и развертывания процесса тестирования применяется конфигурационный файл в формате JSON [8]. Он позволяет определить физическое расположение модулей тестового набора и SUT, а также сконфигурировать тестовый набор, заменив часть элементов тестируемой системы тестирующими модулями. При этом проверяется поведение не всей системы, а только отдельных ее компонент. Данный файл создается автоматически на основании представления системы в UCM, и на этапе создания тестового набора пользователь может вручную задать необходимые значения.
После определения параметров тестового набора (участвующих в тестировании элементов системы, физическое расположение тестового набора и т. п.), автоматически создается код тестового набора на языке целевой платформы и происходит развертывание среды тестирования. Запуск теста осуществляется путем старта процесса управляющего модуля тестового набора, который самостоятельно осуществляет запуск и останов тестирующих модулей и SUT. Результаты формируются в виде журнала событий и MSC диаграмм хода тестирования.
Возможность гибкой настройки позволяет располагать тестирующие модули на различных рабочих станциях в рамках тестовой лаборатории. Ввиду независимости отдельных сценариев тестирования при наличии свободных мощностей возможно разбиение тестового набора на сегменты, исполняемые параллельно. Вместе эти свойства обеспечивают необходимые условия для организации высокопроизводительной виртуальной лаборатории тестирования в облачной или кластерной инфраструктуре.
Ограничения использования технологии. Рассмотренный подход чрезвычайно эффективен
4
ввиду практически полной автоматизации рутинных операций по созданию кода и внесению изменений в спецификацию. Однако используемые технологии и архитектура системы тестирования накладывают ряд ограничений:
формальное представление требований в расширенной нотации иСМ;
генерацию тестовых сценариев средствами верификатора VRS;
распределенность архитектуры. Стандартный иСМ позволяет описывать только функциональные свойства системы, характеризующие поток событийного управления. Для описания данных вычислительного процесса и семантики событий потока управления иСМ расширен дополнительными смысловыми элементами - метаданными, а информация метаданных активно использована в алгоритме UST.
Инструмент верификации VRS позволяет построить модель системы в виде машины состояний в нотации базовых протоколов. Артефактом процесса верификации требований в данной системе являются MSС диаграммы, используемые в качестве тестовых сценариев для генерации кода тестового набора. Процесс обеспечения полного покрытия требований тестами для реальных промышленных систем сложен, но в данной технологии он решается путем автоматической генерации тестовых сценариев на основе формальной спецификации эвристик, задающих актуальные режимы поведения системы, и используемых в VRS при анализе модели системы и генерации трасс.
Еще один ограничивающий фактор - архитек-
СПИСОК ЛИТЕРАТУРЫ
тура системы тестирования. Она ориентирована на удаленное взаимодействие элементов, жесткую спецификацию протоколов, наличие определенных прав доступа к аппаратным средствам и подготовленную лабораторию тестирования.
Перечисленные ограничения не препятствуют успешному применению разработанной технологии для телекоммуникационных систем.
Главный аспект данной работы - интеграция управления требованиями, верификации и тестирования. Это существенно снизило влияние, оказываемое изменением спецификации программного продукта на процесс тестирования. Рассмотренный метод позволяет осуществлять проверку системы на соответствие требованиям в едином производственном цикле. Тестирование осуществляется на основании набора тестовых сценариев, корректность которых доказана при верификации модели системы. При этом существенно снижаются затраты, связанные с регрессионным тестированием при изменении требований или их дополнении. Этапы данного технологического процесса частично или полностью автоматизированы. Программные инструменты, относящиеся к различным этапам работы, взаимонезависимы; использующиеся форматы представления данных стандартизованы. Разработанные методики и программные средства опробованы в проектах тестирования протокола SIP и отдельных компонентах телекоммуникационных систем, использующих протоколы стандартов WiMax и LTE.
Работа поддержана грантом РФФИ 11-07-90412-Укр_ф_а
1. Леффингуелл, Д. Принципы работы с требованиями к программному обеспечению [Текст] / Д. Леффингуелл, Д. Уидриг. -М.: Вильямс, 2002.
2. Buhr, R.J.A. Use Case Maps for Object-Oriented Systems [Text] / R.J.A. Buhr, R.S. Casselman. -London: Prentice Hall, 1996.
3. ITU-T Recommendation Z.120: Message sequence chart (MSC) [Электронный ресурс] / Geneva, Switzerland, Oct. 1996 // Режим доступа: http://eu.sabotage.org/www/ ITU/Z/Z0120e.pdf
4. ITU-T Recommendation Z.151 : User requirements notation (URN) [Электронный ресурс] / Language definition. Geneva, Switzerland, Sept. 2003 // Режим доступа: http://www.itu.int/rec/T-REC-Z.151-200811-I/en
5. Kaner, C. Testing Computer Software [Text] / C. Kaner, J. Falk, H.Q. Nguyen; 2nd ed. -New York: Wiley, 1999.
6. Letichevsky A. Basic protocols, message sequence charts, and the verification of requirements specifications [Text] / A. Letichevsky [et al.] // Computer Networks: The International J. of Computer and Telecommunications Networking. -5 Dec. 2005. -Vol. 49. -№ 5. -P. 661-675.
7. Никифоров, И. Генерация формальной модели системы по требованиям, заданным в нотации USE CASE MAPS [Текст] / И. Никифоров, А. Петров, Ю. Юсупов // Научно-технические ведомости СПбГПУ Сер. Информатика. Телекоммуникации. Управление. -2010. -№ 4 (103). -C. 191-195.
8. RFC 4627: The Application/JSON Media Type for JavaScript Object Notation (JSON), July 2006 [Электронный ресурс] / Режим доступа: http://www.ietf.org/ rfc/rfc4627.txt
9. Veselov, A.O. Testing automation of projects in telecommunication domain [Text] / A.O. Veselov, V.P. Kotlyarov // Proc. of the 4th Spring/Summer Young Researchers' Colloquium on Software Engineering. -Nizhny Novgorod, June 1-2, 2010. -P. 81-86.
10. Baranov, S. The technology of Automation Verification and Testing in Industrial Projects [Text] / S. Baranov, V. Kotlyarov, A. Letichevsky, P. Drobintsev // Proc. of St.Petersburg IEEE Chapter, International Conf., SPb., May 18-21, 2005 -P. 81-86.
УДК 004.415
П.Д. Дробинцев, В.П. Котляров, И.Г. Черноруцкий
АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ НА ОСНОВЕ ПОКРЫТИЯ ПОЛЬЗОВАТЕЛЬСКИХ СЦЕНАРИЕВ
Программное обеспечение (ПО) активно используется в различных областях деятельности человека. При этом следует отметить, что сложность разрабатываемых программных комплексов неуклонно растет, что приводит к появлению существенных проблем при анализе их поведения. В то же время требования к качеству постоянно ужесточаются в силу того, что ПО все чаще используется в областях, критичных к ошибкам и сбоям. Подобная ситуация приводит к необходимости разработки и внедрения новых методов анализа поведения программного продукта на фазе тестирования. Одно из наиболее активно развивающихся направлений в этой области - использование формальных моделей при разработке программ. К данному направлению относится огромное количество как средств разработки (CASE-средств), так и методов, используемых для построения моделей программ. Это, например, нотация языка UML [1] и поддерживающие ее средства разработки таких фирм, как IBM (линейка Rational) [6], Microsoft, Altova [7] и др. или нотации для описания программ в терминах процессов, такие, как BPMN [8] и IDEF [9], поддержанные в инструментах компаний Visual Paradigm и CA Technologies. Представленные средства позволяют проводить анализ функционирования программ на различных этапах разработки, начиная с самых ранних стадий, что позволяет существенно сократить издержки на выявление дефектов и таким образом повысить качество разрабатываемого ПО.
Следует отметить, что использование CASE средств в процессе разработки ПО связано с дополнительными трудозатратами на построение
формальных моделей. Существенно снизить данные издержки возможно путем применения простой для инженерной практики нотации описания моделей. В данной статье рассматривается подход, основанный на использовании стандартизированной нотации UCM [5] для построения формальной модели системы с последующей генерацией поведенческих сценариев для целей тестирования.
Нотация UCM. Язык UCM является стандартом описания поведения системы в виде определения совокупности взаимодействующих процессов. Отличительные особенности языка: графическая нотация, использующая небольшое множество основных элементов, достаточное для описания функционирования сложных программных комплексов; использование высокоуровневых абстракций для создания многоуровневых описаний сложных программных комплексов, сохраняющих семантические особенности; объединенное представление потоков управления и данных в моделях. Следует отметить, что представленные особенности играют существенную роль, т. к. подход, описанный в настоящей статье, предполагает тесное взаимодействие с заказчиком ПО при формализации UCM сценариев поведения проектируемого ПО.
Пример простой UCM диаграммы изображен на рис. 1. На диаграмме приведена спецификация системы, описывающая подмножество функций медиаплеера. Для уменьшения сложности приложения в описание введены элементы - Stub, абстрагирующие часть описываемого поведения для упрощения представления функциональности системы в целом.
