Размещено на http://www.allbest.ru/

[Введите текст]

Федеральное государственное автономное образовательное учреждение высшего профессионального образования

Национальный исследовательский университет

Высшая школа экономики

НИУ ВШЭ - Нижний Новгород

Факультет информатики, математики и компьютерных наук

Кафедра прикладной математики и информатики

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

На тему: «Разработка автоматических тестов для тестирования новой функциональности программного обеспечения»

Нижний Новгород 2015

Содержание

• Введение
• Автоматизация тестирования
• Преимущества автоматизации
• Возможные недостатки автоматизации
• Постановка задачи
• Практическая часть. Структура тестируемого приложения
• Инструмент Cucumber
• Файл с расширением .feаture
• Файл с расширением .rb
• Файл конфигурации
• Файл CucumberRunner и аргументы Java-машины
• Ход работы
• Результаты
• Заключение
• Список литературы
• Приложение 1. Файл CucumberRunner
• Приложение 2. Пример файла .feature
• Тест: Загрузка конфигурации. Режим Create, Update, Delete
• Приложение 3. Пример файла .rb
• Тест: Загрузка конфигурации. Режим Create, Update, Delete

Введение

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

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

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

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

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

Автоматизация тестирования

Автоматизированное тестирование программного обеспечения - это процесс проверки программного обеспечения, который включает в себя такие шаги как запуск, инициализация, выполнение, анализ и выдача результата, и выполняет их автоматически посредством специализированных инструментов. Автоматизированное тестирование является аналогом ручного функционального тестирования, но при этом выполняется программой по заданному сценарию (скрипту), а не человеком.

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

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

Данный вид тестирования является довольно объемным и его ресурсоемкость может достигать 90% от общего объема работ, при тестировании новых версий программного продукта. Частичная или полная автоматизация необходимых регрессионных тестов может существенно упростить задачу.

Преимущества автоматизации

Преимущества, которые даёт тестировщику автоматизация тестирования:

· Исключен «человеческий фактор». Существует некоторая гарантия того, что не один тест не будет пропущен при выполнении, и ничего не будет напутано в результатах.

· Скорость выполнения. Автоматизированный скрипт выполняется гораздо быстрее ручного теста, а также предоставляется возможность работы с приложением без использования графического интерфейса.

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

· Отчеты. Автоматически сохраняемые отчеты, содержащие результаты тестирования.

· Автономность выполнения. Во время выполнения тестов инженер-тестировщик может заниматься другими активностями, или тесты могут выполняться в нерабочее время.

Возможные недостатки автоматизации

Вместе с тем имеет место и ряд недостатков, таких как:

· Затраты на поддержку. Требуется время на разработку и поддержку скриптов.

· Стоимость инструмента автоматизации. Стоимость системы автоматизированного тестирования может оказаться неоправданно высокой.

· Пропуск мелких ошибок. Автоматический скрипт может пропускать мелкие ошибки, на проверку которых он не запрограммирован.

· Ограничения. Не все операции возможно протестировать с помощью авто-тестов.

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

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

Жизненный цикл программы версии 1.1, участвующей в тестировании, составляет один календарный год. За этот период реализуется 20 итераций, включающих в себя различные изменения.

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

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

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

Передо мной стояли задачи:

· автоматизировать тестирование новой функциональности ядра продукта;

· проанализировать и оценить эффективность использования автоматизации тестирования;

· оценить применимость автоматического тестирования регрессионных тестов ядра в текущем проекте.

Для оценки эффективности автоматизации в проекте будут приниматься во внимание следующие составляющие:

· сокращение временных затрат на выполнение тестирования;

· минимизация трудовых затрат, оптимизация человеческих ресурсов:

o за счет возможности автоматического сохранения отчетов с результатами выполнения тестирования;

o за счет возможности выполнения части автоматизированного тестирования машиной без непосредственного участия человека;

· локализация «слабых мест» тестируемого программного обеспечения;

· применимость авто-тестов к различным версиям продукта.

Практическая часть. Структура тестируемого приложения

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

Данное обеспечение является Java-приложением и разработано исключительно для операционной системы Microsoft Windows.

В глобальном смысле приложение можно разделить на 2 составляющие:

· ядро программы,

· плагины.

Рис. 1 Структура тестируемого приложения

Ядро

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

Основной функцией ядра является определение структуры данных конфигурации сети.

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

Плагины

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

Все данные, используемые приложением, имеют формат XML.

Инструмент Cucumber

Для того, чтобы реализовать автоматизацию тестирования, был выбран специализированный программный инструмент Cucumber.

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

Тестирование с использованием Cucumber состоит из 3-х основных этапов.

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

2. Определение сценариев (step definition) на языке Ruby.

3. Цикл тестирования: проверка функционала инструментом и генерация отчета, содержащего результаты тестирования.

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

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

Структура и конфигурирование Cucumber

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

· файл CucumberRunner

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

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

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

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

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

Размещено на http://www.allbest.ru/

[Введите текст]

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

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

Файл с расширением .feаture - это сценарий выполнения теста, который записывается в текстовом формате.

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

Пример:

@Open_conf_version_1

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

Given I have an < configuration > specified

When I create < object > with <sub_object>

Then I should find < object > with < sub_object>

Затем указываются необходимые атрибуты и их значения:

| configuration | object | sub_object |

| configuration.xml | RNCobject | NodeBobject |

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

Файл с расширением .rb является основным файлом для тестирования с помощью инструмента Cucumber. В нем описан сценарий, по которому выполняется автоматизированное тестирование. В качестве языка используется Ruby.

Cucumber tool позволяет запускать сразу несколько .rb и .feature файлов одновременно. Однако, одному .feature файлу может соответствовать только один .rb файл, но одному .rb файлу может соответствовать несколько .feature файлов.

Пример:

When /^I create (.*) with (.*)$/ do |object, sub_object|

@root= Cucumber::Configuration.getRoot()

@context=@root

@element= Cucumber::Configuration.createElement(object)

@context=@object

@sub_element= Cucumber::Configuration.createElement(sub_object)

end

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

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

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

Пример:

<JаrDirectory> C:\Program Files\Program\v1.1.0\jars</JаrDirectory>

<PluginDirectory> C:\Program Files\Program\v1.1.0\plugins</PluginDirectory>

Файл CucumberRunner и аргументы Java-машины

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

Кроме того, неотъемлемой частью файла являются аргументы настройки виртуальной Java-машины, на которой запускается Cucumber. Очень важно, чтобы аргументы JVM Cucumber'a соответствовали настройкам JVM приложения, иначе результаты тестирования могут оказаться некорректными.

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

Пример:

:report_path_root_dir => "report"

-Xmx=1200m

-XX:MаxPermSize=150m

-OUTPUT_DIRECTORY=D:\output

В основном, это служебные значения, максимальный размер heap памяти и размер Permanent области. А также путь к файлам, которые генерируются Java машиной при работе инструмента с тестируемым приложением. Кроме того, необходимо указать путь, где будут храниться отчеты о тестировании с актуальными статусами тестов и корректными результатами тестирования программного продукта.

Пример файла CucumberRunner который использовался при тестировании показан в приложении №1 к данной работе.

Ход работы

В течении года от команды разработчиков пришло 6 пакетов, содержащих изменения в ядре программы. Для каждого пакета составлялось в среднем от 1-ого до 5-ти тестов необходимых для проверки функционала.



Рис. 3 Структура поступления версий и количество функциональных тестов ядра.

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

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

Тесты, которые были автоматизированы в ходе данной работы:

1. Загрузка конфигурации. Режим Create.
2. Импорт конфигурации. Режим Update.
3. Импорт конфигурации. Режим Delete.
4. Сохранение конфигурации. Режим Create.
5. Сохранение конфигурации. Режим Update.
6. Сохранение конфигурации. Режим Delete.
7. Создание зашифрованного объекта.
8. Конфигурирование зашифрованного объекта.
9. Замещение зашифрованного объекта.
10. Удаление зашифрованного объекта.
11. Копирование/вставка зашифрованного объекта.
12. Активация/дезактивация зашифрованного объекта.
13. Расшифровка объекта.
14. Загрузка настроек.
15. Выгрузка настроек.
16. Загрузка таблицы.
17. Сохранение таблицы в .csv формате.
18. Сохранение таблицы в .xls формате.
19. Сохранение таблицы в .xlsx формате.
20. Сохранение таблицы в .txt формате.

Результаты

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

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

Рис. 4 Время выполнения ручных и автоматизированных тестов для 1-ой итерации регрессионной кампании.

Согласно полученным результатам в среднем время выполнения 1 теста вручную инженером-тестировщиком составляет 2,2 часа (132 минуты). В свою очередь, среднее время, за которое выполняется автоматический тест, составляет 2,4 часа (144 минут). При этом результаты времени не сильно отличаются друг от друга, т.к., несмотря на то, что на выполнение автоматизированного теста и отчетность затрачивается гораздо меньше времени, на подготовку к тесту затрачивается времени больше за счет разработки сценариев автоматизированных тестов.

Однако, это справедливо лишь для тестов первой итерации. В дальнейшем тесты на функциональность ядра, как было сказано выше, выполняются на каждой четвертой итерации в течение одной версии продукта. Рассмотрим результаты выполнения тестов на 2 и n-й итерациях теста:

Рис. 5 Время выполнения ручных и автоматизированных тестов для 2-ой и n-ой итерации регрессионной кампании.

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

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

Введем понятие выигрыша по времени для регрессионной кампании:

Где: N - количество версий,

Y - количество запусков регрессионного тестирования,

Num - количество тестов участвующих в тестировании.

- время выполнения i-ого ручного теста на любой из итераций, включающее в себя время на подготовку к тестированию, а также само время выполнения теста и время на заполнение отчета.

- время выполнения i-ого автоматического теста на 1-ой итерации тестирования, включающее в себя время на подготовку к тестированию, написание тестового скрипта и время на его выполнение.

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

Подставив в данную формулу результаты, полученные во время тестирования версии v1.1, получаем следующие значения для первой итерации тестов:

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

Для 3-х же версий продукта, с выполнением регрессионного тестирования ядра на каждой четвертой итерации тестируемого приложения, выигрыш получается равным:

Для того чтобы лучше проиллюстрировать выгоду, полученную от автоматизации, переведем полученный результат в рабочие дни. Один рабочий день инженера-тестировщика составляет 8 часов. Таким образом, за 3 года использования автоматического тестирования реализованных тестов, работник получает выигрыш в 59 рабочих дней. Итого, каждый год экономия составляет 19,6 дней или примерно один рабочий месяц.

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

Рассмотрим эффективность использования автоматизации регрессионного тестирования функционала ядра в проекте, как отношение времени автоматического тестирования к времени ручного тестирования с ростом количества итераций, на примере одного теста.

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

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

Таблица 1. Затрачиваемое время при ручном тестировании для выбранного теста

на подготовку и отчетность	0,5 часа
на ручное тестирование для 1-й итерации	1,5 часа
всего на 1-й тест	2 часа
на ручное тестирование для n-й итерации	1,5 часа
всего на n-й тест	2 часа

Для выполнения того же теста автоматически, необходимо также выделить время на подготовку, равное времени подготовки перед выполнением ручного теста. Кроме того, необходимо реализовать скрипт, который будет выполнять необходимые для тестирования действия. На все эти действия уходит достаточно большое количество времени, однако время выполнения автоматического теста гораздо меньше времени выполнения ручного теста. За счет этого достигается преимущество при частом запуске регрессионного тестирования. Благодаря автоматической генерации отчета инженеру по тестированию не нужно фиксировать результаты и заполнять отчет вручную, экономя на этом большое количество времени.

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

Таблица 2. Затрачиваемое время при автоматическом тестировании

на подготовку и отчетность	0,3 часа
на создание скрипта	4,2 часа
на автоматизированное тестирование для 1-й итерации	0,5 часа
всего на 1-й тест	5 часов
на автоматизированное тестирование для n-й итерации	0,5 часа
всего на n-й тест	0,8 часа

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

Рис. 6 Отношение времени автоматического тестирования к времени ручного тестирования

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

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

Таблица 3. Дефекты, обнаруженные в ходе ручного и автоматизированного тестирования

Важность дефекта Тип тестирования	Незначительные	Важные	Критичные
Ручное	5	3	1
Автоматическое	3	3	1

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

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

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

Заключение

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

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

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

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

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

Стоит так же отметить тот факт, что увеличение количества итераций в регрессионном тестировании также способствует еще большему выигрышу в будущем.

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

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

· знакомство с инструментом для автоматизированного тестирования Cucumber;

· получение опыта в автоматизации тестирования;

· улучшение навыков написания тестовых сценариев на языке Ruby;

· получение опыта оценки результатов автоматизированного тестирования и целесообразности его применения.

Список литературы

1. Automation Testing Using Cucumber Tool and Selenium [Электронный ресурс] - Режим доступа: http://www.softwaretestinghelp.com/cucumber-bdd-tool-selenium-tutorial-30/. (Дата обращения: 24.11.2014).

2. Test Automation Snake Oil [Электронный ресурс] - Режим доступа: http://www.satisfice.com/articles/test_automation_snake_oil.pdf. (Дата обращения: 16.03.2014).

3. A. Hellesшy, The Cucumber Book: Behaviour-Driven Development for Testers and Developers / M. Wynne, A. Hellesшy, The Pragmatic Bookshelf. - Jan. 2012. - 313 pp. - ISBN 978-1934356807.

4. Corrкa de Oliveira J., Costa Gouveia C., Quidute Filho R. “A way of Improving Test Automation Cost-Effectiveness.”, C.E.S.A.R., 2006, pp.1-5.

5. Fewster M. “Common Mistakes in Test Automation.”, Grove Consultants, 2001, pp.1-7.

6. Marik B. “When Should a Test Be Automated?”, Testing Foundations, 1998, pp.1-20.

7. Success with Test Automation [Электронный ресурс] - Режим доступа: https://www.prismnet.com/~wazmo/succpap.htm. (Дата обращения: 10.02.2014).

8. Rossmiller M. “6 Tips to Getting Started with Automated Testing.”, SmartBesar Software, 2011, pp.1-7.

9. Vihari. S. “A System of Humanizing Test Automation Outlay Efficiency.” International Journal of Emerging Science and Engineering, May 2013, pp.74-78.

10. Винниченко, И. Автоматизация процессов тестирования / И. Винниченко. - СПб.: питерб 2005. - 203с. - ISBN 5-469-00798-7.

11. Котляров, В. П. Основы тестирования программного обеспечения: учебное пособие / В.П. Котляров, Т.В. Коликова. - М.: Интернет-Ун-т Информ. Технологий, 2006. -- 288с. - ISBN 5-94774-406-4.

Приложение 1. Файл CucumberRunner

def user_default_configuration

{

:report_path_policy => "timestamp_as_suffix",

:report_path_root_dir => "/report/",

:dry_run => false,

:root_features_dir => "/features/",

:jvm_args => "-Xmx4600m -XX:PermSize=128m",

:cucumber_args => "--backtrace",

:java_exe => "#{ENV['JAVA_HOME']}/bin/java",

:features_dir => "/features/"

}

end

run_configurations=[

{:features_dir => "/features/"},

]

runner = CucumberRun::CRunner.new(ARGV, user_default_configuration)

runner.run(run_configurations)

Приложение 2. Пример файла .feature

Тест: Загрузка конфигурации. Режим Create, Update, Delete

Feature: Configuration import. Create, Update, Delete mode.

As a user of the application

I want to know if there are any issues for loading configuration functionality in Create, Update, and Delete mode

Scenario Outline: Configuration loading

Given I load configuration <configuration> in mode <mode>

When loading is finished, I switch to Report and checkup Loaded Configuration

Then number of errors in application Report should be equal <numberErrors>

And number of notifications in application Report should be equal <numberWarnings>

Then Loaded Configuration should be <configuration>

And Session list should contain only <conf_Name> actions

Scenarios:

|configuration|mode|numberLogErrors|numberAppReportErrors| numberAppReportNotifications|reportName|

| CreateConfType1.xml|Create|1 |0|0 |ReportOfCreateConfType1|

| CreateConfType2.xml|Create|1 |0|0 |ReportOfCreateConfType2|

| UpdateConfType10.xml|Update|1 |0|0 |ReportOfUpdateConfType10|

| DeleteConfType4.xml|Delete|1 |0|0 |ReportOfDeleteConfType4|

Приложение 3. Пример файла .rb

Тест: Загрузка конфигурации. Режим Create, Update, Delete

begin

require 'rspec/expectations';

rescue LoadError;

require 'spec/expectations';

end

require 'cucumber/formatter/unicode'

require 'Configuration'

require 'CucumberAppTest'

require 'CucumberAppUtils'

require 'csv'

require 'CucumberAppLogs'

require 'CucumberAppReport'

Given /^ I load configuration (.*)$ in mode (.*)$/ do |@configuration, mode|

@StartTime = Cucumber::getSysTime()

@sessionInit=Cucumber::Configuration.getCurrentSession()

@conf=Cucumber::Configuration.new(@AppTest.getServiceDirectory())

@conf.loadConfiguration("datadir/configurations/" + @configuration, mode)

@conf.checkLoadLogExcludes("error")

end

When /^ loading is finished, I switch to Report and checkup Loaded Configuration$/ do

@report=Cucumber::Configuration.getReport()

@loadedConf=Cucumber::Configuration.loadedConf()

end

Then /^ number of errors in application Report should be equal (.*)$/ do | numberErrors |

@appReportErrorsNum=@loadedConf.getAppReportErrorsNumber(true)

@appReportErrorsNum.should == @numberErrors

@GlobalReportAppErrorsStatus.Add(@loadedConf.getAppReportErrorsStatus())

If @appReportErrorsNum != @numberErrors

@GlobalReportAppErrors.Add(@loadedConf.getAppReportErrors(true))

end

end

And /^ number of notifications in application Report should be equal (.*)$/ do | numberNotifications |

@appReportNotificationsNum = @loadedConf.getAppReportNotifications(true)

@appReportNotificationsNum.should == @numberNotifications

@GlobalReportAppNotificationsStatus.Add(@loadedConf.getAppReportNotificationsStatus())

If @appReportNotificationsNum != @numberNotifications

@GlobalReportAppNotifications.Add(@loadedConf.getAppReportNotifications(true))

end

end

Then /^ Loaded Configuration should be (.*)$/ do | configuration |

@loadedConfName=@loadedConf.getName().to_s

@loadedConfName.should == configuration.to_s @GlobalReportAppConfigurationStatus.Add(@loadedConf.getAppReportConfigurationStatus())

end

And /^ Session list should contain only (.*) actions$/ do | mode |

@sessionConf=Cucumber::Configuration.getCurrentSession()

@sessionConf.should != @sessionInit

@GlobalReportAppSessionStatus.Add(@loadedConf.getAppReportSessionStatus())

@sessionActions=@session.getActions()

If mode == `create'

@sessionActions.should contain `Create'

end

If mode == `update'

@sessionActions.should contain `Create,Update'

else

@sessionActions.should contain `Delete'

end

end

@EndTime = Cucumber::getSysTime();

@time=@EndTime - @StartTime

csv.generateReport(@ReportName, @GlobalReportLogErrors,@GlobalReportAppErrors,@GlobalReportAppNotifications,

@GlobalReportLogErrorsStatus, @GlobalReportAppErrorsStatus, @GlobalReportAppNotificationsStatus, @GlobalReportAppConfigurationStatus, @GlobalReportAppSessionStatus,@time);

end

Размещено на Allbest.ru