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

Файл с расширением .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. Затрачиваемое время при ручном тестировании для выбранного теста

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

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

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

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

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

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

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

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

На основании полученных результатов можно отметить, что в результате тестирования вручную и автоматически было обнаружено одинаковое количество «критических» и «важных» ошибок, т.е. автоматические тесты не пропустили ни одного «значительного» дефекта (как и не нашли новых). Однако не все «незначительные» ошибки были обнаружены с помощью автоматических тестов. Изначально было обнаружено лишь 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:

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

Тест: Загрузка конфигурации. Режим 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()