Автоматизированное тестирование программного обеспечения

метки: Тестирование, Автоматизированный, Средство, Режим, Подготовка, Update, Require, Необходимо

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

• Исключен «человеческий фактор». Существует некоторая гарантия того, что не один тест не будет пропущен при выполнении, и ничего не будет напутано в результатах.
• Скорость выполнения. Автоматизированный скрипт выполняется гораздо быстрее ручного теста, а также предоставляется возможность работы с приложением без использования графического интерфейса.
• Меньшие затраты на поддержку. При уже имеющихся написанных скриптах не требуется такого большого количества времени на их поддержку и анализ результатов, как при проведении того же объема тестирования вручную.
• Отчеты. Автоматически сохраняемые отчеты, содержащие результаты тестирования.
• Автономность выполнения. Во время выполнения тестов инженер-тестировщик может заниматься другими активностями, или тесты могут выполняться в нерабочее время.

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

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

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

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

• сокращение временных затрат на выполнение тестирования;
• минимизация трудовых затрат, оптимизация человеческих ресурсов:
• o за счет возможности автоматического сохранения отчетов с результатами выполнения тестирования;
• o за счет возможности выполнения части автоматизированного тестирования машиной без непосредственного участия человека;
• локализация «слабых мест» тестируемого программного обеспечения;
• применимость авто-тестов к различным версиям продукта.

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

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

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

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

Данное обеспечение является 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, прежде всего необходимо иметь представление о структуре инструмента и каким образом его можно настроить. Конфигурирование происходит путём изменения следующих файлов:

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

... работы является разработка и реализация универсальной системы автоматизированного тестирования web-приложений, ... Cucumber больше нацелен на тестирование приложений на Java. Тестировать приложения на других языках с помощью Cucumber ... тестирования был изучен фреймворк PyTest языка Python. В данном языке хорошо развиты методологии объектно-ориентированного программирования, создания фикстур (конфигураций) ...

• файл CucumberRunner
• файл с расширением .feаture
• файл с расширением .rb
• файл конфигурации
• аргументы виртуальной Java-машины (JVM),

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

Рис 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;
• получение опыта оценки результатов автоматизированного тестирования и целесообразности его применения.

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