Нарыжная Н.С.

Национальный технический университет Украины «Киевский политехнический институт»

Архитектура системы автоматизированного тестирования распределенных систем на основе Keyword-driven подхода

Вступление

Широкое внедрение распределенных информационных систем (РИС) характерно сегодня почти для всех областей человеческой деятельности, где на них возлагается решение все более важных задач. Они отвечают за выполнение технологических процессов на производстве, за связь и телекоммуникации, энергетическое снабжение и транспортное обслуживание, выполнение социальных и медицинских программ, поддержку государственной, военной, научной деятельности. От качества функционирования РИС существенно зависит качество наработки и принятия решений, а также эффективность функционирования многих социальных, экономических, военных, политических структур и тому подобное.

В свою очередь, с появлением и развитием распределенных систем, встал вопрос, каким образом можно протестировать такие сложные системы. Тестирование является неотъемлемой частью разработки программного обеспечения. Цель тестирования программного обеспечения – найти информацию о неисправностях в разрабатываемом ПО и убедиться, что они исправлены. Важно найти недостатки как можно раньше, потому что их устранение дороже на поздних этапах разработки [1]. Целью тестирования также является предоставить информацию о текущем состоянии разработанного программного обеспечения с точки зрения качества.

В данной статье будет рассмотрено архитектура системы автоматизированного тестирования распределенных систем на основе Keyword-driven подхода. Основной идеей Keyword-driven тестирование является отделение автоматизации от дизайна тест-кейса. В результате этот подход разделяет процесс создания тестов на две стадии: на стадию проектирования и разработки, и стадию исполнения.

          На сегодняшний день существуют примеры реализации системы автоматизированного тестирования распределенных систем на основе Keyword-driven подхода. Но все они имеют схожую логику вся строка тест-кейса считывается, как одно «ключевое слово», программная инфраструктура Keyword-driven живет отдельно от программной инфраструктуры автотестов, которые создают члены команды автоматизированного тестирования.

Цель работы

          Описание созданного программной инфраструктуры “Keyword-driven testing” с использованием TFS, Coded UI и TeamCity, на основе уже существующего репозитория автоматических тестов. А также анализ и определение положительных и отрицательных сторон данного подхода и сравнение с существующими вариантами реализации Keyword-driven подхода.

Постановка задачи

          В качестве анализируемого web-приложения был выбран интернет-ресурс irm.ipreo.com – веб-приложение для финансовых услуг большим компаниям.

251658240Drawing1

Рис. 1. – Диаграмма реализации и работы созданной программной инфраструктуры “Keyword-driven testing”

          На рисунке 1 показана реализация Keyword-driven подхода, который описывается в данной статье и состоит из таких уровней:

1.     Создание тест-кейса в TFS по определенным Keyword-driven правилам, которые описаны в специальном словаре.

2.     Считывание шагов созданного тест-кейса при помощи реализованных в Coded UI методой

3.     Создание временного файла с тест методом, который будет автоматически исполнятся, на основе считаных шагов из тест-кейса.

4.     Запуск созданного временного файла с тест методом c помощью TeamCity. (После выполнения созданного теста, временный файл с тест методом автоматически удаляется)

5.     Анализ полученных результатов. 

Программная инфраструктура “Keyword-driven testing” созданная при помощи Coded UI отвечает за считывание шагов с тест-кейса, создание временного файла с тест методом [2], который готов к автоматическому исполнению.

Архитектура созданного продукта в Coded UI имеет такой вид:

251658240

Рис. 2. – Архитектура продукта в Coded UI

В BDAutomatiuonFramework лежат реализации основных видов элементов, реализация страницы логина, базовый объект страницы, а также конфигурационные XML файлы. Еще BDAutomatiuonFramework секция содержит реализацию Keyword-driven логики и пользовательского атрибута KeywordMethod. BDCodedUITest содержит реализацию всех страниц, всплывающих окон и реализация пользовательского атрибута UIElement, который описан ниже. В свою очередь KeywordDriven секция содержит реализацию считывания шагов с тест-кейса, создание временного файла с тест методом на основе воплощения специальных методов-помощников.

KeywordDriven секция состоит из двух основных классов CreatingTest и KeywordDrivenHelper, а также классы с тест методами, в зависимость от того сгенерированы они или нет.

251658240ClassDiagram1

Рис. 3. – CreatingTest класс с его методами

CreatingTest класс отвечает за создание класса с тест методом на основе считываниях шагов из тест-кейса и добавление этого класса в проект, для его выполнения.

251658240ClassDiagram1

Рис. 4. – KeywordDrivenHelper класс с его методами

KeywordDrivenHelper класс отвечает за распознавание ключевых слов в шагах из тест-кейса с помощью пользовательских атрибутов, а также этот класс содержит методы, которые определяют объекты с которыми тест работает в данный момент выполнения.

На примере тест-кейса я опишу процесс считывания шагов и их конвертацию в тест метод – код полноценного теста для исполнения:

Таблица 1. Пример синтаксиса определенного тест-кейса

ID

Action

1

Log in under @Container

2

Navigate to "People Advanced Search"

3

Select "BD Data"

4

Select "Show Institutions Funds"

5

Select "North America" from "Select
 Region/Location"

6

Select "Calgary" from "Select State"

7

Select "Bank" from "Institution/Fund Type"

8

Click "Search"

9

Check that column contains search values "Primary Institution Type", "Bank" in "Grid"

Рассмотрим, например, шаг 5 («Select "North America" from "Select Region/Location"»). Для того, чтобы при помощи кода распознать обычную строку из тест-кейса были созданы два специальные пользовательские атрибуты.

Первый, называется [KeywordMethod("…")], который отвечает за действия, например такие как: Выбрать, Открыть, Отсортировать колонку и т.д. В нашем примере – это [KeywordMethod("Select")]. Select – это ключевое слово в шаге 5, которое отвечает за действие выбора чего либо от куда угодно.

Второй, называется [UIElement("…")], который в свою очередь принимает название элемента, с которым мы хоти выполнить то или иное действие. В примере, который рассматривается, это выражение "Select Region/Location". В коде это выглядит так – [UIElement("Select Region/Location ")].

Так как, элемент "Select Region/Location" – это выпадающий список и нам нужно что-то из него выбрать, то нам необходимо указать значение или значения, которые мы хотим выбрать из него. Это значение представлено в рассматриваемом примере в таком виде: "North America". Такие значения не требуют специальных пользовательских атрибутов, для их считывания был реализован специальный метод, который распознает эти значения.

Следовательно, в специальном словаре описываются только имена всех элементов и действий, которые пользователь может для создания тест-кейсов.

В результате, мы получаем такой тест метод:

251658240

Рис. 5. – Пример сгенерированного тест метода

Так выглядит сгенерированная строчка кода для рассматриваемого, как пример, шага тест-кейса: KeywordDriven.KeywordDrivenHelper.SelectKeyword("Select Region/Location","North America");.

При помощи пользовательского атрибута [KeywordMethod("Select")] мы получили KeywordDriven.KeywordDrivenHelper.SelectKeyword() метод, а его входящие параметры – это имя элемента, который мы получаем с помощью пользовательского атрибута [UIElement("Select Region/Location ")]; и так же значение, которое мы хотим выбрать из указанного элемента.   

          Таким подходом тестирования распределенных систем могу пользоваться как мануальные тестировщики, бизнес-аналитики, заказчики и так члены команды автоматизированного тестирования. Для мануальных тестировавщиков, бизнес-аналитиков, заказчиков этот подход будет особо полезен для дымового и регрессионного тестирования. А члены команды автоматизированного тестирования смогут сгенерировать большее количество тестов для прогона и покрытия приложения автоматическими тестами [3].

Для любого члена команды необходимо лишь создать правильно тест-кейс, используя словарь, зайти на TeamCity, ввести номер или несколько номеров созданных тест-кейсов и нажать кнопку Run. А после дождаться результатов прогона тестов и проанализировать их.

Выводы

В результате использования Keyword-driven подхода было выявлено, что количество протестированного функционала увеличилась на 35%, и при этом качество не пострадало. Также были определены плюсы и минусы данного подхода.

 Положительные стороны:

·        Уровень поддержки низкий в долгосрочной перспективе:

o       Тест-кейсы краткие;

o       Тест-кейсы читабельные для заинтересованных сторон;

o       Тест-кейсы легко изменять;

o       Новые тест-кейсы могут использовать существующие ключевые слова более легко.

·        Повторное использование ключевых слов для нескольких тест-кейсов

·        Разделение труда

o       Создание тест-кейсов требует более сильных знаний о тестовой документации, но не требует глубоких знаний в программировании и специальных инструментов для реализации этого подхода;

o       Реализация подхода требует более сильных знаний в программировании и специальных инструментов, но не требует особых знаний в тестовой документации.

Отрицательные стороны:

·        Дольше выходит на рынок, по сравнению с ручной проверкой ПО

·        Требует сильной внимательности при создании тест-кейсов при помощи ключевых слов.

При сравнении с существующими реализациями получили такие преимущества:

·        Реализация пользовательских атрибутов делает использование Keyword-driven подхода более гибким и удобным для использования. В то время как существующие реализации принимают всю строку, как одно «ключевое слово», данный реализованный подход при помощи пользовательских атрибутов разделяет одну строку тест-кейса на несколько «ключевых слов», которые могут быть переиспользованы и являются более независимыми при их эксплуатации. Например, [KeywordMethod("Select")] атрибут может быть использован для разных видов элементов, которые присутствуют в тестируемом продукте, следовательно, нет необходимости создавать большого количества обработчиков таких «ключевых слов» для отдельных элементов тестируемого приложения.

·        Использование уже существующего репозитория автоматических тестов в разы сокращает этап разработки Keyword-driven подхода. Так как все что нужно это реализовать логику Keyword-driven, считывание шагов из тест-кейса и их конвертацию в вызываемые методы в автотесте, а также пользовательские атрибуты, которые помогаю при считывании шагов из тест-кейса.

С полученных результатов можно сделать вывод, что тестирование Keyword-driven подходом имеет положительный эффект, но только для долгосрочных проектов, так как этот подход имеет свойство длительного старта.

Литература

1.     R. Binder. Testing object-oriented software: a survey. Software Testing, Verification and Reliability, 6:125–252, 1996.     

2.     K. C. Tai, R. H. Carver: Testing of distributed programs; in A. Zomaya (ed.): Handbook

3.     A. Ulrich, S. T. Chanson: An approach to testing distributed software systems; 15th PSTV 1995; Warsaw, Poland; pp. 107-122; 1995.