Автоматизация регрессионного тестирования (стр. 2 )

Система представляет собой клиент-серверное приложение, схема работы которого отображена на Рис. 1.

Клиентская часть реализует пользовательский интерфейс, формирует запросы к серверу и обрабатывает ответы от него. Основой клиентской части в тестируемом программном продукте является программная платформа Microsoft Silverlight.

Серверная часть получает запрос от клиента, выполняет операции, после этого формирует отчет и отправляет его клиенту. В текущем продукте сервер написан на языке Java. При этом весь функционал ПО, используемые плагины и библиотеки также находятся на стороне сервера. Основная работа в процессе автоматического тестирования будет проходить с плагинами при использовании библиотек сервера.

Процесс регрессионного тестирования

Ограничение ресурсов

Прежде, чем приступать к описанию процесса регрессионного тестирования, следует обратить внимание, на что затрачиваются ресурсы во время верификации элементов проверки соответствия.

Для того, чтобы выполнить регрессионное тестирование, тестировщику необходимо иметь файл с описанием конфигурации в формате XML (созданный во время ручного тестирования элемента проверки соответствия) и отчет с результатами проведения проверки соответствия на текущей конфигурации. Отчет имеет удобную форму, в которой сообщается о тестируемых объектах конфигурации и соответствующих им сообщениях после проведения тестирования. Таким образом, задачей тестировщика является запуск тестируемого приложения, загрузка файла конфигурации, запуск определенного элемента проверки соответствия, сравнение полученных результатов с имеющимся отчетом и анализ этих данных.

По стандарту, установленному нашим проектом, на выполнение ручного регрессионного тестирования одного элемента уделяется 0,5ч/ч (человеко-час). Максимальное количество членов команды, которое может быть задействовано в ручном регрессионном тестировании, ограничивается общим количеством людей в команде, выделяемых для проведения данного вида тестирования, и для нашего проекта составляет не более 4 человек.

Ручное регрессионное тестирование проверки соответствия

В начальной версии 2.0 тестируемого программного продукта не производилось регрессионное тестирование проверки соответствия, т. к. не было необходимых файлов с описанием конфигураций, участвующих в процессе тестирования элементов проверки соответствия, и отчетов ее выполнения. В течение года члены команды, в зависимости от своей деятельности, выполняли обычное тестирование элементов проверки соответствия. На один тест тестировщик, исходя из стандартов проекта, может потратить 2,5ч/ч.

В следующей версии 2.1 тестируемого программного продукта не только появились новые элементы проверки соответствия, но и образовалась база из файлов и отчетов проведенных тестов на проверку соответствия в предыдущей версии программного обеспечения.

В текущей версии 2.2 тестируемого приложения увеличилось количество тестов для регрессионного тестирования, и также прибавились новые элементы, структуры которых будут покрыты тестировщиками в течение жизненного цикла этой версии.

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

Приведенная схема на Рис. 2 отображает, какое количество времени тратится на тестирование элементов проверки соответствия и их ручное регрессионное тестирование при идеальных условиях, выполняемое один раз для различных версий продукта. (Прим.: Как уже было сказано, ручное регрессионное элементов проверки соответствия выполняется дважды за жизненный цикл продукта.) Под идеальными условиями подразумевается трудовая деятельность в течение 8 часов в день (нормальная продолжительность рабочего времени человека[1]) с минимальной производительностью.

 

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

Как показывает схема, если в версии продукта 2.1 регрессионное тестирование элементов проверки соответствия занимало не более 37 дней рабочего времени (md, “man-days”; единица измерения производительности трудящегося) инженера по тестированию в год, то для версии продукта 2.2 это заняло бы более 60 рабочих дней в год при его обычном выполнении дважды за версию одним человеком и в три раза меньше в условиях работы трех членов команды. Несмотря на то, что регрессионное тестирование является одним из самых важных видов тестирования любого программного продукта, проект не может позволить себе затрачивать столь значительные ресурсы. Это также стало одной из причин проявления интереса к автоматизации регрессионного тестирования элементов проверки соответствия.

Cucumber-инструмент

Общие сведения

В качестве инструмента для автоматизированного регрессионного тестирования был выбран Cucumber.

Cucumber – приложение, широко используемое для тестирования программного обеспечения, выполняющее приемочное тестирование в стиле BDD (Behaviour-Driven Development) процесса. Это означает, что во время тестирования инструмент фокусируются не на тестах, а на спецификациях поведения объектов, с которыми он работает; также существует связь кода с требованиями, которые записываются с помощью обычных фраз, тем самым рождается специфичный для предметной области язык (DSL) и улучшается общение с пользователем.

Другими словами, Cucumber позволяет описывать ожидаемое поведение приложения обычным текстом. Текст написан на предметно-ориентированном языке. Cucumber может работать с Ruby, Jаvа, .NET, Flex, а также с веб-приложениями, написанными на любом языке.

Cucumber способен автоматически сохранять отчёты в заданном пользователем формате. Для использования Cucumber как инструмента тестирования в нашем проекте потребовалось добавить функции, специфичные для тестируемого приложения.

История Cucumber

Cucumber – свободно распространяемое приложение, является переписанным Аслаком Хеллесойем вариантом RSpecStoryRunner Дэна Норта.

В апреле 2008 Аслак Хеллесой начал развивать проект Cucumber, чтобы устранить внутренние дефекты дизайна и проблемы удобства использования проекта RSpecStoryRunner. Затем к проекту присоединились Джозеф Уилк и Бен Мэбей. После этого, в октябре 2009, к проекту присоединились Майк Сассак и Грегори Хнатик, создавшие самый быстрый парсер для Cucumber.

Язык Gherkin, который используется в Cucumber, был создан Дэном Нортом, Крисом Маттсом, Лиз Ког и Дэвидом Келимски.

На данный момент Cucumber только набирает популярность в качестве приложения для автоматизированного тестирования.

Структура Cucumber

Рис. 3 Структура Cucumber

Тестирование с использование программы Cucumber происходит как с помощью встроенных функций Cucumber, так и с помощью дополнительных функций, которые были получены от разработчиков тестируемого программного продукта.

Также есть 4 внешние составляющие.

Данные – файлы формата XML, описывающие конфигурации для тестирования элементов проверки соответствия.

Файл конфигурации с указанием путей к директориям, где располагаются плагины и библиотеки сервера тестируемого ПО.

Настраиваемые аргументы JVM для корректной работы инструмента Cucumber на базе используемой машины.

Файл CucumberRunner, где описаны пути к внутренним директориям проекта автоматизации, содержащим. rb и. feature файлы, необходимыми для выполнения автоматического тестирования.

Конфигурирование Cucumber

Для корректного выполнения автоматических тестов Cucumber должен быть правильно настроен. Настройка происходит путём изменения следующих файлов (описанных выше):

·  файл CucumberRunner. mwe2,

·  файл с расширением. feаture,

·  файл с расширением. rb,

·  файл конфигурации,

·  аргументы виртуальной Java-машины (JVM),

а также с помощью добавления необходимых пользовательских файлов в соответствующие директории.

Файл с расширением. feаture

Feature-файл является неотъемлемой частью Cucumber. Файл используется для записи шагов тестирования на понятном для пользователя языке. Все feature-файлы имеют расширение. feature.

Описанный сценарий впоследствии будет отображаться в html отчете, который автоматически генерируется инструментом для тестирования:

Given I have an <consElementId> specified

When I load version <conf> with <model>

Then I run all elements on the <confElementId> with <fix>

Then I can receive a <severity> and <nbMsg> MESAND <nbAutoMsg> describe in <msg1> MESAND <msg2> MESAND <msg3> MESAND <msg4> MESAND <auMsg1> MESAND <auMsg2>

Затем должны быть указаны необходимые атрибуты:

| conf | model | confElementId | consElementId | severity | nbMsg | msg1 | msg2 | msg3 | msg4 | nbAutoMsg | auMsg1 | auMsg2 |