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

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

Файл с расширением. rb также является одним из основных файлов для тестирования с помощью инструмента Cucumber. Он представляет собой пошаговое описание сценария тестирования на языке Ruby.

Одному. rb файлу может соответствовать несколько. feature файлов, в то время как одному. feature файлу может соответствовать только один. rb файл. Именно первая особенность подходит для реализации автоматического регрессионного тестирования элементов проверки соответствия, поскольку, как правило, количество feature-файлов равно либо больше, чем самих элементов проверки соответствия.

Пример:

When /^I load version (.*) with (.*)$/ do | conf, model|

@confpath = "data/dir/confs/" + conf

@conf = Cucumber::Conf. new(@consElementSession. getServiceDirectory())

@conf. openConf(@confpath)

end

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

В файле конфигурации указывается путь к библиотекам и плагинам тестируемого приложения.

Пример:

<JаrDirectory> C:\Program Files\program\jars</JаrDirectory>

<PluginDirectory> C:\Program Files\program\plugins</PluginDirectory>

Настраиваемые аргументы инструмента Cucumber

Файл CucumberRunner. mwe2 содержит специализированные аргументы для настройки и корректной работы инструмента для тестирования Cucmber. Обязательной частью данной файла является наличие указанных путей к директориям проекта, где располагаются .feature и. rb файлы. Кроме того, очень часто в нем указываются настройки для виртуальной Java-машины, на которой запускается Cucumber. Для корректных результатов значения аргументов JVM Cucumber’a должны точно соответствовать настройкам JVM приложения.

Также тут указываются значения других необходимых аргументов.

Наиболее часто используемые настраиваемы аргументы JVM – это Xmx и XX:MаxPermSize.

Xmx{число}m – максимальное количество оперативной памяти, выделяемой под виртуальную машину Java, в мегабайтах. Вместо {число} указывается любое требуемое число, исходя из суммарного количества оперативной памяти на компьютере.

Пример записи: - Xmx1500m

XX:MaxPermSize={число}m – количество памяти Permanent Generation (сокр. PermGen), выделяемой под виртуальную машину Java, в мегабайтах. В этой памяти хранится исполняемый код программы. Если выдаётся ошибка OutOfMemory:PermGenSpace, необходимо увеличить выделение PermGen. Вместо {число} указывается любое требуемое число. Слишком большое число указывать не рекомендуется, так как исполняемый код занимает немного места, а излишнее выделение PermGen зачастую приводит к задержкам в работе инструмента для тестирования.

Пример записи: -XX:MaxPermSize=150m

Здесь очень важно найти баланс между установленными значениями аргументов для JVM и техническими возможностями машины. Слишком маленькие значения могут сделать процесс тестирования медленным. А слишком большие значения аргументов окажут неблагоприятное влияние на работу компьютера, поскольку значительное количество оперативной памяти будет занимать работа инструмента для тестирования.

Алгоритм работы Cucumber по определению статуса теста

Пояснение статусов тестов

Во время определения статуса теста Cucumber не просто решает, насколько удачно выполнился тест, но работает с исключениями в случае неудачного выполнения тестирования. Если сценарий шаг за шагом не вызывает никаких исключений, тест однозначно получает статус “PASSED”, и продолжает свое выполнение. В другом случае тест может иметь статус “FAILED”, “PENDING SCENARIO” или “UNDEFINED SCENARIO”. Эта особенность Cucumber, как инструмента для внедрения автоматизации тестирования в проекте, помогает тестировщику, как разработчику автоматического сценария, отследить прогресс выполнения тестирования.

PASSED – статус для успешно пройденного теста, при условии что все шаги сценария в. feature файле соответствуют шагам кода в. rb файле и были полностью выполнены.

FAILED – статус для неудачно пройденного теста, при условии что все шаги сценария в. feature файле соответствуют шагам кода в. rb файле и были полностью выполнены, учитывая отсутствие ожидаемых исключений, которые могут быть выполнены дальше по коду сценария.

PENDING SCENARIO – статус для теста, для которого определены шаги как в сценарии – .feature файле, так и в коде – .rb файле, но по ходу выполнения были объявлены возможные исключения. Исключения необходимы в том случае, когда для дальнейшего выполнения сценария нужны дополнительные параметры, которые будут получены в другой части кода, за которую отвечает иной раздел сценария. feature или .rb файла. При отсутствии объявленных исключений там, где они нужны, выполнение сценария будет прекращено.

UNDEFINED SCENARIO – статус для теста, который показывает, что существует несоответствие сценариев, описанных в. feature и .rb файле. Этот статус полезен для инженера по тестированию во время разработки автоматического сценария, чтобы показать, какие шаги были пропущены в том или ином файле.

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

Инструкция по использования тестового сценария

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

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

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

Применяемые метрики

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

Для анализа полученных результатов использовались следующие метрики.

Производительность выполнения тестовых сценариев ручным способом (кол-во/час)

, где

ТР – производительность ручного тестирования,

NT – количество выполненных тестовых сценариев,

Тm – время, затраченное на выполнение всех ручных тестовых сценариев.

Производительность выполнения тестовых сценариев автоматическим способом (кол-во/час)

, где

АТР – производительность автоматического тестирования,

NАT – количество выполненных автоматических тестовых сценариев,

Тa – время, затраченное на выполнение всех автоматических тестовых сценариев.

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

Выигрыш перехода от ручного вида тестирования к автоматическому (ч)

, где

n – количество выполненных автоматических тестов,

tm – время, затрачиваемое на выполнение одного теста ручным способом,

ta – время, затрачиваемое на выполнение одного теста автоматическим способом,

tap – время, затрачиваемое на подготовку к автоматическому тестированию.

Количественный анализ

Расчет разницы между ручным и автоматическим тестированием по времени

Анализ работы применяемого инструмента для тестирования Cucumber показал, что на выполнение теста на один элемент проверки соответствия тратится от 0,5 до 1,5 минут в зависимости от конфигурации. Автоматическое тестирование всех имеющихся элементов проверки соответствия в версии продукта 2.1 занимает 7,5 часов, то есть около одного рабочего дня одного члена команды (Рис. 5).