CC BY
49
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, абстрагирующие часть описываемого поведения для упрощения представления функциональности системы в целом.
^ Научно-технические ведомости СПбГПУ 4' 2012 Информатика. Телекоммуникации. Управление
Рис. 1. Пример UCM диаграммы
Детальное описание языка UCM приведено в работах [3, 5].
Подход к проверке качества. Использование формальных моделей при разработке программного обеспечения дает возможность применить как формальные методы проверки правильности ПО, так и различные методы автоматической генерации, нацеленные на получение целевого кода приложения и тестов. UCM модель представляет полную совокупность сценариев поведения системы и позволяет получить подмножество сценариев, достаточное для покрытия поведения модели тестами в соответствии с выбранными критериями. В предлагаемом подходе UCM модель используется для получения двух типов сценариев:
с полным покрытием поведения системы по ветвям;
с покрытием путей, определенных пользователем.
Получение множества сценариев первого типа связано с полным обходом UCM диаграммы и автоматической генерацией путей, ведущих в каждую ветвь. Детальное описание метода обхода может быть найдено в [3]. Однако опыт тестирования реальных программных проектов показывает, что применение только критерия ветвей недостаточно, т. к. при этом не рассматривается ряд сценариев поведения системы, важных для пользователя. Например, конечное прохождение циклов с определенным количеством повторов или различные варианты поведения параллельных взаимодействующих процессов. Отсутствие в полученном автоматически тестовом наборе тестов, направленных на проверку подобных поведений, приводит к ухудшению качества проверяемого ПО. Таким образом, возникает проблема описания и последующего тестирования сценариев с
покрытием путей, определенных пользователем.
Трудоемкость создания пользовательского поведенческого сценария связана в первую очередь со степенью его детализации. В случае недостаточной детализации в сгенерированном тесте будут отсутствовать необходимые тестовые воздействия на систему, что чревато невозможностью исполнения пользовательского сценария, тогда как при избыточно детальном описании сценария трудозатраты на его создание будут достаточно велики. Для уменьшения трудозатрат при детализации пользовательских сценариев предлагается использовать подход, основанный на формировании гида, т. е. ручного указания для генерации сценария только тех точек (элементами UCM диаграммы) поведенческого сценария, которые интересны пользователю. Последующая детализация сценария осуществляется автоматически генератором/верификатором сценариев. Схема предложенного подхода изображена на рис. 2.
На первом этапе генератор сценариев по заданным пользователем точкам проводит генерацию детального сценария. В случае если расстояние между указанными пользователем точками больше одного UCM элемента, инструмент генерации вычисляет путь максимальной длины между двумя точками, и эта длина используется генератором для детализации сценария между этими точками.
На втором этапе инструментарий верификации [4] осуществляет конкретизацию сценария путем подбора такого пути между точками, который может быть пройден с учетом начальных установок в системе и ограничений, указанных в метаданных каждого элемента UCM диаграммы.
Язык описания пользовательских сценариев. Для задания пользовательских сценариев в предложенном подходе используется специали-
Этап 1 Этап 2
Рис. 2. Технологическая цепочка генерации пользовательских сценариев
зированный язык GDL (guides definition language). Данный язык построен на основе определения пользователем формул гидов четырех различных типов.
• формулы подмодели M определяются как M = U с AU , где AU- множество всех элементов UCMдиаграммы. Формулы данного типа позволяют определить подмодель путем указания множества элементов UCM диаграммы. Таким образом, формула M описывает элементы, которые будут использоваться при обходе UCM диаграммы;
• формулы альтернативного выбора S определяются как S = u е AU, где AU - множество всех элементов UCM диаграммы. Данные формулы позволяют задать подмножество M указанием одного элемента. При этом в определяемое множество M попадут все элементы, достижимые из элемента и, а также все элементы, лежащие на путях из точки s UCM диаграммы в точку и;
• определение формулы пользовательских последовательностей R: R = щ* n ^ u2* n ^... ... ^ un * n,(uj, ..., un } е AU, где AU - множество всех элементов UCM диаграммы и n - количество повторений рассматриваемого элемента и. при описании цикла. Таким образом, формулы определяют последовательности UCM элементов и, которые должны быть представлены в генерируемом сценарии;
• формулы T определяются как T = (M*,S*, R*}. Формулы данного типа определяют совокупность правил, описанных в формулах типа M, S, R, которая будет использована при генерации конкретного тестового набора.
Рассмотрим пример использования языка
GDL для спецификации. Предположим, что поведение системы описывается спецификацией, представленной на рис. 3.
С точки зрения покрытия по ветвям в автоматическом режиме будет сгенерировано четыре тестовых сценария, где «,» определяет последовательную композицию протоколов, «()» определяет количество протоколов между двумя элементами UCM диаграммы:
А, В - для покрытия В;
А, F - для покрытия А и F;
А, С(2), D - для покрытия С и D;
А, С(2), Е - для покрытия Е.
Как видно из представленных тестов, каждая ветвь системы будет покрыта как минимум один раз. При этом в процессе уточнения трассы все дерево поведения будет пройдено.
Предположим, что пользователь хочет сократить время генерации и не рассматривать полный обход дерева поведения при работе с большими программными проектами. Для решения этой задачи могут использоваться формулы М и Например, уберем из рассмотрения ветку F, для этого необходимо задать формулу М = А, В, С, D, Е. При этом последовательность элементов не важна, т. к. данной формулой формируется подмодель нашей системы. И определим формулу для тестового набора Т1 = М1. В результате будет сгенерировано два теста: А, В, С, D и А, В, С, Е, которые в совокупности покроют все элементы диаграммы за исключением элемента F. Аналогично можно решить данную задачу с использованием формулы 51 = В, данный вариант более предпочтителен в силу меньших трудозатрат в определении формул со стороны пользователя. Таким образом, форму-
Научно-технические ведомости СПбГПУ 4' 2012 ^ Информатика. Телекоммуникации. Управление
лы M и S позволяют решить проблемы, связанные с необходимостью частичного рассмотрения модели и дают возможность сокращения как обхода дерева поведения системы при уточнении сценария, так и уменьшения тестового набора.
В тестах, полученных для рассматриваемого примера, обеспечено покрытие по ветвям, однако не рассмотрены проблемы множественного прохождения цикла, содержащего элемент D. Следует отметить, что рассмотрение этого вопроса может быть важным при обеспечении качества. Так, например, пользователя может интересовать поведение системы при максимальном количестве прохождений цикла, определяемом метаданными, скрытыми в элементах диаграммы (предположим, что в этом примере это число равно пяти). Для создания подобного тестового набора необходимо воспользоваться формулой R = C, D*5 , E, задающей пятикратное повторение цикла и выход из него в точку E. В результате применения этой формулы в процессе генерации тестового набора будет получено две тестовых последовательности: A, B, C, D, D(2), C, E и A, F, C, D, D(2), C, E, покрывающие пятикратное прохождение цикла по всем возможным путям, начинающимся в стартовой точке. В отличие от тестовых наборов, нацеленных на покрытие поведения системы по ветвям,
СПИСОК Л
1. Грейди, Буч. Язык UML. Руководство пользователя = The Unified Modelling Language user guide [Текст] / Буч Грейди, Джеймс Рамбо, Айвар Джекобсон; 2-е изд. -М.: -СПб.: ДМК Пресс; Питер, 2004. -432 с.
2. Recommendation ITU-T Z.120. Message Sequence Chart (MSC), 11/2000 [Электронный ресурс].
3. Никифоров, И.В. Использование Use Case Map в современной технологической цепочке разработки программного обеспечения [Текст] / И.В. Никифоров, Ю.В. Юсупов // Технологии Microsoft в теории и практике программирования. Матер. межвуз. конкурса-конф. студентов, аспирантов и молодых ученых Северо-Запада. 16-17 марта 2010. -СПб.: Изд-во Политехнического ун-та, 2010. -С. 107-108.
использование данных тестов при тестировании представленной системы поможет выявить дефекты, связанные с некорректной обработкой данных при множественном прохождении цикла.
Таким образом, использование формул в процессе создания тестовых наборов позволяет решить следующие проблемы, возникающие при создании специфических тестовых сценариев:
определение пользовательских сценариев путем задания интересующих точек поведения на UCM диаграмме, при этом путь от точки к точке будет вычислен с использованием системы верификации, что гарантирует его корректность;
сокращение дерева поведения при его обходе с целью покрытия поведения по ветвям;
определение специфических сценариев для циклических конструкций и параллельного поведения системы.
В общем случае практика применения подхода, основанного на использовании покрытия пользовательских сценариев, дает возможность существенного увеличения тестового покрытия и за счет этого повышения качества разрабатываемого программного обеспечения.
Работа частично поддержана международным грантом РФФИ 11-07-90412-Укр_ф_а.
ГЕРАТУРЫ
4. Колчин, А.В. Разработка инструментальных средств для проверки формальных моделей асинхронных систем: Дис. ... канд. физ.-мат. наук [Текст] / А.В. Колчин. -Киев, 2009. -140 с.
5. Z.151 : User requirements notation (URN) -Language definition [Электронный ресурс] / Режим доступа: http://www.itu.int/rec/T-REC-Z.151-200811-I/en
6. [Электронный ресурс] / Режим доступа: http:// www-01.ibm.com/software/ru/rational/
7. [Электронный ресурс] / Режим доступа: http:// www.altova.com/umodel.html
8. [Электронный ресурс] / Режим доступа: http:// www.bpmn.org/
9. [Электронный ресурс] / Режим доступа: http:// www.idef.com/IDEF0.htm
