CC BY
14
ний и подходы к решению проблемы достижимости [Текст] / С.В. Потиенко // Искусственный интеллект. -2009. -№ 1. -С. 192-197.
4. Jones, C. Software Defect-Removal Efficiency [Text] / C. Jones // IEEE Computer. -1996. -P. 94-95.
5. Shull. What We Have Learned About Fighting Defects [Text] / Shull [et al.] // IEEE Computer. -2002. -P. 78-81.
6. Veanes, M. Model-Based Testing of Object-Oriented Reactive Systems with Spec Explorer, in Formal Methods and Testing [Text] / M. Veanes, C. Campbell, W. Grieskamp [et al.]. -Springer Verlag, 2008. -Vol. 49. -P. 39-76.
7. Baranov, S. The technology of Automation Verification and Testing in Industrial Projects [Text] / S. Baranov, V. Kotlyarov, A. Letichevsky, P. Drobintsev // Proc. of SPb IEEE Chapter, International Conf., May 18-21, 2005. -P. 81-86.
8. Никифоров, И. Генерация формальной модели системы по требованиям, заданным в нотации USE CASE MAPS [Текст] / И. Никифоров, А. Петров, Ю. Юсупов // Научно-технические ведомости СПбГПУ Сер. Информатика. Телекоммуникации. Управление. -2010. -№ 4 (103). -С. 191-195.
УДК 004.415
И.В. Никифоров, А.В. Петров, В.П. Котляров
СТАТИЧЕСКИМ МЕТОД ОТЛАДКИ ТЕСТОВЫХ СЦЕНАРИЕВ, СГЕНЕРИРОВАННЫХ С ИСПОЛЬЗОВАНИЕМ ЭВРИСТИК
В современном подходе к разработке программного обеспечения активно используются модели приложений различной детальности. Они позволяют уже на ранних стадиях проектирования проводить статический анализ поведения модели, а также создавать тестовые сценарии, поэтому задача отладки моделей и автоматически генерируемых по модели тестовых сценариев на сегодняшний день является актуальной и важной для создания качественного программного продукта.
Пример современной технологии, в которой применяется модель для верификации и тестирования, - система автоматической генерации и
исполнения тестов VRS/TAT [1]. Для высокоуровневого описания модели в рассматриваемой технологической цепочке используется нотация Use Case Maps (UCM) [2, 3].
В настоящей работе стандартная нотация UCM, позволяющая в гибкой и удобной форме задавать потоки управления, расширена средствами задания потоков данных [4] с помощью механизма метаданных. Метаданные определяют условия изменения состояний приложения, реализуемые элементом UCM: описывают состояния предусловий и постусловий, взаимодействия с переменными системы, а также действия и сигналы,
Рис. 1. Использование метаданных на UCM элементе
отправляемые и принимаемые. На рис. 1. приведен простой пример использования метаданных, описывающий процесс увеличения громкости радио, при нажатии на кнопку 'Volume Up'.
В предусловие входят две переменные, которые проверяют состояние радио и нажатую кнопку. После чего происходит отправление сигнала увеличения громкости и изменение соответствующего параметра.
Использование одновременно потока управления и потока данных в модели делает нотацию UCM мощным языком моделирования индустриальных проектов.
Для отладки модели в технологии VRS/TAT используется интерактивный режим, позволяющий в пошаговом режиме статического анализа отслеживать состояния модели приложения и диагностировать проблемные места поведения модели. На проектах средней и большой сложности подобный процесс отладки трудоемок, что приводит к существенным временным затратам в процессе разработки тестовых сценариев. Поэтому ставится задача создания методов быстрого и гибкого статического анализа для отладки автоматически генерируемых тестовых сценариев.
Автоматическая генерация тестовых сценариев
Структура процесса генерации символьных сценариев приведена на рис. 2. По исходным требованиям к системе вручную строится UCM модель. Методика формализации описана в работе [4]. Созданная UCM модель с помощью транслятора UCM2BP [5] преобразуется в формальную модель на языке базовых протоколов [6], являющемся входным языком для инструментов VRS/TAT.
Основная проблема процесса генерации тестовых сценариев по модели - взрыв состояний. Дерево поведения модели уже для проектов среднего размера может содержать огромное число поведений, поэтому полный обход всех поведений практически невозможен. Для решения этой проблемы используются эвристики (гиды) [7], которые содержат упорядоченные подмножества подцелей, направляющих поиск в соответствии с критериями покрытия актуальных поведений [8].
Затем формальная модель на языке базовых протоколов и эвристики поступают на вход трассового генератора VRS (см. рис. 2), осуществляю-
щего автоматический обход дерева и построение символьных тестовых сценариев.
Результат трассовой генерации - информация о покрытии, т. е. информация о том, по каким эвристикам тестовые сценарии сгенерированы успешно, а по каким - нет.
Задача автоматического получения символьных трасс по эвристикам не всегда решается без проблем. Причина заключается в особенности построения эвристик инструментом UCM2MSC, учитывающим зависимости от потока управления (явно отображенного на UCM диаграммах), но не учитывающим зависимости от данных, входящих в предусловия базовых протоколов и влияющих на поток управления. По этой причине некоторые эвристики не могут быть покрыты тестами, что приводит к анализу причин непокрытия, сосредоточенных либо в UCM модели, либо в автоматически сгенерированной эвристике.
Для целей отладки и выяснения причин расхождения эвристик с трассами используется анализатор последовательностей событий UCM диаграммы - UCM Events Analyzer (UCM EVA). Процесс анализа и отладки на рис. 2 выделен жирными линиями.
Рис. 2. Процесс генерации тестовых сценариев с использованием инструмента статического анализа - EVA
Рис. 3. Алгоритм поиска ошибок в эвристиках и их корректировка
Методика поиска ошибок
К наиболее частым причинам расхождения относятся: недостаточная детализация эвристик и ошибки в последовательности UCM элементов в эвристике из-за некорректного использования переменных (ошибки идентифицируются как deadlock на ветвях или ветвлениях).
В статье предложен метод поиска мест и причин ошибок, выявленных для случаев расхождения эвристики с трассой. На рис. 3 представлен итерационный алгоритм поиска и исправления ошибок.
1. Эвристики и полученные в VRS трассы представлены в виде MSC диаграмм с последовательностью имен базовых протоколов, поэтому первым шагом алгоритма является отображение базовых протоколов на иСМ элементы.
2. Сравнивая эвристику и трассу в терминах иСМ элементов, можно определить последний элемент трассы, удовлетворяющий порядку иСМ элементов эвристики. Следующий за ним элемент назовем элементом расхождения.
3. По непокрытому в символьной трассе элементу эвристики - элементу расхождения можно рассмотреть соответствующие ему метаданные и
Рис. 4. иСМ диаграмма с двумя параллельными участками и использованием разделяемых ресурсов
Рис. 5. Эвристики в терминах иСМ, покрывающие ветви иСМ диаграммы
зафиксированное в них предусловие.
4. Далее следует выделить переменные предусловия в отдельный список и проанализировать только те места на иСМ диаграмме, в которых осуществляется изменение переменных этого списка. Анализ следует вести снизу вверх, начиная с событий, ближайших к элементу расхождения.
5. После обнаружения причины расхождения необходимо скорректировать эвристику или внести изменения в иСМ модель.
Предложенную последовательность действий требуется повторять до тех пор, пока все эвристики не будут покрыты трассами.
Пример анализа UCM проекта
Наглядная иллюстрация поиска расхождения трассы с эвристикой - пример многопоточной системы с разделяемыми ресурсами. На рис. 4 приведен пример иСМ диаграммы с двумя параллельными участками, заданными с помощью элементов параллельного ветвления и объединения AndFork и AndJoin.
На верхнем пути использован элемент WP (WaitingPlace) с условием 'var==1' для ожидания потоком момента его выполнения. На нижнем пути переменная 'var' изменяет свое значение дважды. Сначала ей присваивается значение '1', затем '8'.
С помощью инструмента UCM2MSC проводится генерация набора диаграмм, покрывающего UCM проект по критерию ветвей. Результатом работы являются две эвристики (рис. 5), которые обходят верхнюю и нижнюю ветви рассматриваемого примера.
На следующем шаге генерируются трассы по эвристикам. После запуска трассового генератора инструмент VRS создает файл вердикта. Вердикт показывает, что обе эвристики остались непокрытыми. Генератор, пытаясь покрыть эвристику, сохраняет трассу на каждом шаге генерации, т. е. после каждого успешного применения очередного базового протокола. Это позволяет анализировать сохраненные непокрытые трассы, в которых зафиксировано расхождение.
Используя механизм сравнения, реализованный в инструменте UCM EVA, проводится анализ эвристики и трассы по предложенному методу. На рис. 6. показана вкладка анализа инструмента EVA, предназначенная для поиска элемента расхождения эвристики и трассы.
Несложно увидеть, что элементом расхождения между эвристикой и трассой является элемент 'WP'. Это означает, что не выполняется условие 'var==1' при попытке пройти через этот элемент. Теперь можно определить, какие другие элементы используют данную переменную и в каком отношении они находятся с элементом 'WP'.
▼ UME s UCM EVA S3
J
в т
Ь Guides | [т] Traces © Analysis
Щ Trace analysis (*)= UCM Analysis □ BS Name Viewer
® Generated Guides О Traces □ 0 О Generated Guides ® Traces □ '„
UCMmap2_A_H_2 С g_UC Mmap2_A_H_l_trace0001 0
XA Xa
Хв Xe
Xf
#WP Xg
Xd Xb
Xh
Рис. 6. Анализ эвристики и трассы для поиска элемента расхождения
4
Рис. 7. UCM элементы, использующие переменную 'var'
на параллельных ветвях ИСМ, что приводит к непредсказуемому результату исполнения системы и потенциальным тупикам, связанным с гонкой данных. Чтобы исправить ошибку, нужно скорректировать ИСМ, добавив синхронизацию (рис. 8).
После повторной генерации эвристик на выходе У^Б получаются четыре последовательности, покрывающие все ветви проекта (рис. 9).
Предложенный в работе метод итерационного анализа расхождения трасс и эвристик позволяет сократить количество шагов анализа с общего числа ИСМ элементов в трассе, до числа элементов, в метаданных которых используется
Рис. 8. ИСМ проект с синхронизацией элементов, использующих разделяемый ресурс 'уаг' <7 иСМтар2_А_Н_3 (3) ^ & 11СМтар2_А_Н_2 (О) ^ & иСМтар2_А_Н_4 (1) ^ иСМтар2_А_Н_1 (2)
X А (20) X Е (250) X F (252)
X А (20)
X В (22) X С (24)
X А (20) X Е (250) X F (252)
X А (20) X В (22)
X С (24)
> Ij-AndJoin264 (264) > =1" AndJoin264 (264) > AndJoin264 (264) > AndJoin264 (264)
X D (248) t> X H (258)
X G (254) > X H (258)
X G (254) > X H (258)
X D (248) > X H (258)
Рис. 9. Последовательности, покрывающие все ветки UCM диаграмм
Из рис. 7 видно, что переменная 'уаг' присутствует на четырех элементах проекта, в то время как два из них принадлежат параллельной ветви с 'WP'. Более детальное изучение ИСМ показывает, что переменная 'уаг' не использует синхронизацию
переменная, участвующая в условиях расхождения. Предложенный метод визуализирует и существенно упрощает процесс создания и отладки тестовых сценариев.
Работа поддержана грантом РФФИ 11-07-90412-Укр_ф_а.
СПИСОК ЛИТЕРАТУРЫ
1. Веселов, А.О. Автоматизация тестирования в области телекоммуникаций [Текст] / А.О. Веселов, В.П. Котляров // Научно-технические ведомости СПбГПУ. Сер. Информатика. Телекоммуникации. Управление. -2010. -№4 (103). -C. 180-185.
2. Никифоров, И.В. Использование Use Case Map в современной технологической цепочке разработки программного обеспечения [Текст] / И.В. Никифоров, Ю.В. Юсупов // XXXVIII Неделя науки СПбГПУ: Матер. межвуз. науч.-техн. конф. -СПб.: Изд-во Политехнического ун-та, 2009. -С. 92-93.
3. Recommendation ITU-T Z.151 [Электронный ресурс] / User requirements notation (URN), 11/2008.
4. Никифоров, И.В. Генерация формальной модели системы по требованиям, заданным в нотации USE CASE MAP [Текст] / И.В. Никифоров, А.В. Петров, Ю.В. Юсупов // Научно-технические ведомости СПбГПУ Сер. Информатика. Телекоммуникации. Управление. -2010. -№ 4 (103). -C. 191-195.
5. Никифоров, И.В. Преобразование высокоуровневого дизайна программного продукта в нотации Use Case Map в модель на формальном языке [Текст] / И.В. Никифоров, Ю.В. Юсупов // Технологии Microsoft
в теории и практике программирования. 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) нотация,
