Оглавление

1. Объект автотестирования........................................................................................................................................3
1.1. Гибридный подход............................................................................................................................................3
1.2. Микросервисная архитектура..........................................................................................................................3
2. Инфраструктура........................................................................................................................................................4
2.1. Bitbucket..............................................................................................................................................................4
2.1.1. Версии проектов.........................................................................................................................................4
2.1.2. Ветки.............................................................................................................................................................4
2.2. Jenkins.................................................................................................................................................................4
2.2.1. Пайплайны...................................................................................................................................................4
2.2.2. Сборка, раскатка новой версии приложения и прогон автотестов.......................................................4
2.3. Selenium Grid......................................................................................................................................................5
3. Стек автоматизации..................................................................................................................................................6
3.1. Ruby..................................................................................................................................................................... 6
3.2. Selenium Webdriver............................................................................................................................................6
3.3. Cucumber.............................................................................................................................................................6
3.4. Capybara..............................................................................................................................................................7
3.5. SitePrism..............................................................................................................................................................7
3.6. ParallelTests.........................................................................................................................................................7
4. Структура проекта автотестов..................................................................................................................................8
4.1. Папка config........................................................................................................................................................8
4.2. Папка features....................................................................................................................................................8
4.2.2. Папка Features.............................................................................................................................................8
4.2.3. Папка step_definitions.................................................................................................................................9
4.2.4. Папка support..............................................................................................................................................9
4.3. Файл Cucumber.yml............................................................................................................................................9
4.4. Файл run_cucumber.sh.......................................................................................................................................9
4.5. Файл env.rb.........................................................................................................................................................9
4.6. Файл hooks.rb.....................................................................................................................................................9
5. Процесс запуска автотестов...................................................................................................................................11
5.1. Виды запуска....................................................................................................................................................11
5.1.1. Локальный запуск.....................................................................................................................................11
5.1.2. Удаленный запуск.....................................................................................................................................11
5.2. Многопоточный запуск на Selenium Grid......................................................................................................11
5.2.1. Что такое Selenium Grid............................................................................................................................11
5.2.2. Что такое Hub и Node................................................................................................................................11
5.2.3. Как работает Selenium-сервер.................................................................................................................12
5.2.4. Как работает Selenium-грид.....................................................................................................................12
5.2.5. Что же происходит с Hub’ом и Node’ами после старта грида?............................................................13
 5.2.6. Настройка тестового окружения env.rb..................................................................................................13
5.2.7. Установка gem parallel_tests....................................................................................................................14
5.2.8. Чем же отличается старт грида в докер-контейнерах?........................................................................14
5.3. Отчеты Cucumber Reports................................................................................................................................14
5.3.1. По фичам...................................................................................................................................................15
5.3.2. По тегам.....................................................................................................................................................15
 1. Объект автотестирования
Веб приложение для автоматизации работы оператора банка:
 фронт – React (HTML, CSS, JS);
 бэк – Spring (Java);

1.1. Гибридный подход

Гибридный подход:
 несколько страниц;
 каждая страница – законченный SPA модуль;

1.2. Микросервисная архитектура

Микросервисная архитектура:
 бэк – множество сервисов;
 2. Инфраструктура
2.1. Bitbucket
Bitbucket — веб-сервис для хостинга проектов и их совместной разработки,
основанный на системе контроля версий Mercurial и Git. По назначению и основным
предлагаемым функциям аналогичен GitHub, от которого отличается с одной стороны
меньшей пользовательской базой, а с другой, имеет определённые преимущества в
плане размещения непубличных репозиториев.
Тут хранится проект с автотестами.

2.1.1. Версии проектов

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

2.1.2. Ветки
Существуют следующие ветки в репозитории Битбакета:
 master – изменения идут на интеграцию и в прод
 dev – изменения идут на тестовую, разработческую среду

2.2. Jenkins
Jenkins – это программное обеспечение, обеспечивающее непрерывную
интеграцию.

2.2.1. Пайплайны
Jenkins Pipeline — это сочетание заданий для непрерывной доставки
программного обеспечения с использованием Jenkins.
Jenkins Pipeline позволяет создавать сценарий сборки, состоящий из одной или
нескольких задач, и визуально отслеживать рабочий процесс. Можно увидеть, какие
задания уже запущены или все еще находятся в очереди на исполнение.

2.2.2. Сборка, раскатка новой версии приложения и прогон автотестов

На нашем проекте в зависимости от того на какую среду идет раскатка новой
сборки приложения пайплайн состоит из разных этапов. Но в каждом из них есть этап
запуска автотестов. Это очень удобно, раскатил новую версию, прогнал автотесты и
можешь сразу увидеть, что где упало или не упал
Соответственно на дев стенде гоняются одни тесты, а на интеграции другие.
Сразу хочу сказать, что в силу специфики архитектуры и проекта, на интеграции
невозможна постоянная прогонка всех автотестов.
 Как уже говорил ранее автотесты можно запускать локально и через сборку
Jenkins. Для того чтоб запустить через Jenkins достаточно нажать на кнопку
«Собрать».
2.3. Selenium Grid
Selenium Grid – мощный инструмент, позволяющий запустить выполнение ваших
тестов на несколько машин. Предоставляет возможность управлять несколькими
средами из центральной точки, что позволяет легко запускать тесты с большим
сочетанием браузеров и ОС.
Selenium Grid позволяет запускать тесты на разных машинах в разных браузерах
параллельно.
В основном Selenium Grid используют по нескольким причинам:
 для распараллеливания запуска тестов на различных операционных системах, в
различных браузерах;
 для того, чтобы уменьшить общее время прогона тестов.
На нашем проекте используется для параллельного запуска тестов. Более
подробно о нем поговорим далее.
 3. Стек автоматизации
3.1. Ruby
Ruby — интерпретируемый язык программирования высокого уровня. Обладает
независимой от операционной системы реализацией многопоточности, строгой
динамической типизацией, «сборщиком мусора» и многими другими возможностями,
поддерживающими много разных парадигм программирования, прежде всего
классово-объектную.
Достаточно легко освоить имея опыт программирования на других языках.
Авто тесты написаны на Ruby.
https://www.ruby-lang.org/ru/

3.2. Selenium Webdriver

Selenium Webdriver — инструмент для автоматизации действий веб-браузера.
По назначению Selenium WebDriver представляет собой драйвер браузера, то
есть программную библиотеку, которая позволяет разрабатывать программы,
управляющие поведением браузера.
По своей сущности Selenium WebDriver представляет собой:
 спецификацию программного интерфейса для управления браузером,
 реализации этого интерфейса для нескольких браузеров,
 набор клиентских библиотек для этого интерфейса на нескольких языках
программирования.
С его помощью выполняются все взаимодействия с браузером.
https://www.selenium.dev/

3.3. Cucumber
Сucumber — инструмент для написания BDD тестов, позволяющий писать тесты
на человеческом языке. Для этого используется нотация Gherkin, которая определяет
структуру и правила написания сценариев. Он позволяет описать поведение системы с
позиции внешнего наблюдателя (читать как «заказчика, конечного пользователя»).
При этом описание дается на естественно языке, никаких вам begin end.
Каждый вариант использования системы в огурце называется «фичей» (feature).
Все они лежат в одноименной папочке features с расширением файла *.feature. В
каждом файле описывается один или несколько «сценариев» (scenario),
характеризующих фичу. Сценарии состоят из ряда шагов, объявленных в файлах из
папки features/step_definitions/*_steps.rb.
Шаги бывают трех типов:
 Given (что-то данное, некоторое предварительное условие);
 When (что-то, что происходит, какие-то действия пользователя);
 Then (результат, реакция, отклик);
Через собачку (@) расставляются метки, позволяющие наложить
дополнительные условия на всю фичу или конкретный сценарий, а так же выборочно
выполнить тест. В принципе все читабельно. В идеале должно быть так, чтобы
заказчик взял этот файл, открыл простым текстовым редактором и не напрягаясь
прочел, все понял, осознал и подтвердил: «Оно!»
 В проекте автотестов имеются следующие основные метки:
@development – разработческая среда
@integration – интеграционная среда
@prelive – прелайв среда
@prod – продуктовая среда

Что касается настройки огурца, то она проводится в сгенерированном файле

features/support/env.rb. Там добавляются необходимые строчки кода для
подключения всего, что необходимо для тестирования.
Огурец позволяет реализовать BDD подход.
https://cucumber.io/
https://github.com/cucumber
https://wellbehaved.readthedocs.io/Gherkin.html
https://habr.com/ru/post/423123/

3.4. Capybara
Capybara — гем, позволяющий искать/кликать/… по элементам браузера. Т.е.
представляет собой связующее звено между Cucumber шагами (steps) теста, и
webdriver-ом (экземпляр вызываемого браузера).
На Огурце мы пишет наши тесты простым языком, а сами шаги реализуем с
использованием Capybara. А Capybara уже взаимодействует с webdriver'ом
https://github.com/teamcapybara/capybara

3.5. SitePrism
SitePrism – гем, который предоставляет вам простой и чистый DSL для описания
страниц сайта с использованием шаблона Page Object.
С помощью этого гема релизован паттерн PageObject.
https://github.com/site-prism/site_prism
https://rdoc.info/gems/site_prism/frames

3.6. ParallelTests
ParallelTests – гем, который разбивает тесты на группы и запускает каждую
группу в отдельном потоке (процессе).
С помощью этого гема реализован параллельный запуск тестов.
https://github.com/grosser/parallel_tests
 4. Структура проекта автотестов
Структура папок и файлов проекта следующая:
 config – параметры сред, в которых запускаются тесты;
 features – тестовые сценарии, реализации шагов сценариев и прочие
вспомогательные файлы;
 resources – файлы необходимые для выполнения сценариев (например для
вложения и отправки);
 screenshots – скриншоты сделанные во время выполнения тестов;
 cucumber.yml – параметры для Cucumber;
 Gemfile – файл с списком необходимых гемов проекта;
 Gemfile.lock – файл с списком необходимых гемов проекта с их версией и
зависимостями;
 run_cucumber.sh – файл для запуска тестов;

4.1. Папка config

Параметры и настройки хранятся в папке config.
В ней расположены подпапка environments и файл settings.yml.
В подпапке environments yml-файлы с параметрами для разных сред:
 development – разработческая;
 local – локальный запуск;
 integration – запуск на интеграционной среде;
 prelive – запуск на прелайв среде;
 prod – запуск на продуктовой среде;
В каждом файле прописаны следующие важные параметры для запуска:
 HOST – url среды на которой будут гонятся тесты;
 HUB_URL – url хаба Selenium Grid;
В файле settings.yml прописаны:
 параметры окна запускаемого браузера;
 параметры для Capybara – время ожидания по умолчанию, путь к скринам;

4.2. Папка features

Сценарии на Gerkhin, реализации шагов сценариев и прочие вспомогательные
файлы хранятся в папке features.
В ней расположены подпапки:
 Features – features-файлы с сценариями на Gerkhin;
 step_definitions – rb-файлы, реализации шагов сценариев на Ruby;
 support – различные вспомогательные файлы, страницы PageObject, а также
файлы hooks.rb и env.rb.

4.2.2. Папка Features

Раньше все файлы features хранились в ней. Теперь было решено раскидать их
по подпапкам, в зависимости от типа сценариев – проверок UI или проверок API бека.
Соответственно и подпапки называются – UI Features и API Features.
Внутри UI Features файлы распределены по папкам:
  Business Events Features;
 Card Emission Features;
 Card Order Features;
 Role Model Features;
То есть у нас имеется два больших бизнес процесса: заказ карты и выдача
карты.
Внутри каждой папки – фичи с сценариями.

4.2.3. Папка step_definitions

Раньше также как и с feature файлами, все файлы Ruby лежали в одной папке,
теперь решено было их поделить на API Steps и UI Steps.
Внутри каждой из этих папок файлы .rb с реализациями шагов сценариев.

4.2.4. Папка support

Тут расположены следующие папки и файлы
 helpers – различные вспомогательные модули;
o api_helper – работа с api;
o methods_helpers – получение логов;
o factory – реализация PageFactory;
o и т д;
 pages – описания страниц (локаторы);
 файл Env.rb
 файл Hooks.rb
О них мы поговорим далее более подробно

4.3. Файл Cucumber.yml

Конфигурация Огурца.
Здесь можно прописать конфигурацию запуска, формат отчетов.
https://github.com/AdrianHwang/cucumber/wiki/cucumber.yml

4.4. Файл run_cucumber.sh

Скрипт для запуска Cucumber автотестов.

4.5. Файл env.rb

Файл env.rb — ключевой .rb файл для запуска UI тестов. При инициализации
переменных и файлов теста именно env.rb будет самым первым.
В нем происходит регистрация браузера, на котором будут выполняться тесты,
указывается путь к папкам, в которые будут сохранятся скриншоты, настрофка
выполнения скриншотов, настройка параметров (например url хаба Selenium Grid).

4.6. Файл hooks.rb

Файл hooks.rb описывает действия совершаемые до и после выполнения
автотеста.
 Cucumber перед выполнением того или иного сценария, вызывает секцию
Before do … end. А после завершения сценария — After do … end. Если вы помните, то
Cucumber поддерживает работу с тегами, т. е. мы можем указать перед сценарием
какое-нибудь имя тега и в секции «Before» устанавливать драйвер для Capybara. Так
же можно выводить названия не пройденных тестов из раздела «After», или
отправлять письма, отчеты и так далее.

https://www.testdevlab.com/blog/2018/02/adding-browser-logs-to-your-capybara-
cucumber-ui-test-report/
 5. Процесс запуска автотестов
5.1. Виды запуска
5.1.1. Локальный запуск
Локальный запуск можно выполнять через Ruby Mine.

5.1.2. Удаленный запуск

Удаленный запуск выполняется через запуск сборки Jenkins.

5.2. Многопоточный запуск на Selenium Grid

5.2.1. Что такое Selenium Grid
Все кто занимается автоматическим тестированием, в частности написанием
тестов, рано или поздно сталкиваются с одной и той же проблемой известной всем -
ВРЕМЯ. Время, затраченное на прохождение всех тестов. Оно растет
прямопропорционально с количеством написанных сценариев и никаким образом не
хочет уменьшатся. Количество тестов растет - хорошо. Покрываем все больше и
больше написаных фич. Время растет - плохо. Разработчики перестают прогонять
тесты после изменения кода, ссылаясь на нехватку времени (и их можно понять).
Есть решение запускать тесты в несколько потоков, причем удаленно, чтоб не
мешали работать. Данную задачу решают с помощью Jenkins’a и Selenium Grid.
Selenium Grid – это кластер, включающий в себя несколько Selenium-серверов.
Он позволяет организовать распределённую сеть, позволяющую параллельно
запускать много браузеров на разных машинах.

5.2.2. Что такое Hub и Node

Selenium Grid оперирует такими составляющими, как Hub и Node.
Что такое Hub?
Hub – это центральная точка, которая принимает запросы и направляет их к
Node. Такой себе командный пункт. В гриде может быть только один Hub.
Что такое Node?
Node – это узел, Selenium инстанс, который будет запускать команды,
загружаемые в Hub. Node может быть много в гриде. Node - может запускаться на
разных операционных системах с разными браузерами.
 5.2.3. Как работает Selenium-сервер
Для того, чтобы начать управлять браузером нужно послать запрос create session
на Selenium-сервер.
В результате на ноде открывается браузер, а к вам возвращается токен sessionId,
отправляя который в каждом запросе, вы управляете браузером.

5.2.4. Как работает Selenium-грид

Selenium Grid работает следующим образом:
 имеется центральный сервер (Hub), к которому подключены узлы (Node).
 работа с кластером осуществляется через Hub, при этом он просто транслирует
запросы узлам.
 узлы могут быть запущены на той же машине, что и Hub или на других.

Сервер и узлы могут работать под управлением разных операционных систем,

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

5.2.5. Что же происходит с Hub’ом и Node’ами после старта грида?

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

Под запросами я подразумеваю те команды, которые шлет наш файл с

автотестами. Как пример, командой будет какой-нибудь шаг типа «Найди мне кнопку
на данной странице со следующим id». Соответственно, хабу чтобы выполнить такой
шаг теста, нужно знать, к какому вообще тесту относится данный шаг. Ведь в один
момент он может выполнять несколько тестов. И этот шаг подразумевает, что тот, кто
будет выполнять эту команду, уже выполнил какую-то предысторию из других
команд, например, перешел как раз таки на соответствующую страницу. Вот именно
для этого и нужен уникальный идентификатор сессии с браузером в ноде, который
создает хаб и затем по этому ИД понимает, на какую ноду ему распределять запросы.
Нода же просто ждет команды от хаба, и при получении http-запросов, которые
он перенаправляет на нее — она их выполняет.

5.2.6. Настройка тестового окружения env.rb

Далее нам необходимо указать нашим тестам, чтобы они ходили на удаленные
браузеры. Для этого идем в файл env.rb и добавляем следующие настройки:
 указываем адрес хаба в зависимости от среды;
 указываем настройки браузера;
 регистрируем драйвер удаленного браузера
 5.2.7. Установка gem parallel_tests
Для того, чтобы наш сервер выполнял тесты в несколько потоков нам
необходимо их распаралелить. Для этих целей мы использовали гем parallel_tests, о
котором упоминалось ранее.

http://bug-bang-theory.blogspot.com/2015/01/selenium-grid-with-jenkins.html
https://www.software-testing.ru/library/around-testing/processes/2601-apache-
mesos

5.2.8. Чем же отличается старт грида в докер-контейнерах?

1. Нода на момент старта уже сконфигурирована.
2. Когда мы стартуем ноду в контейнере, мы всегда можем быть уверены в том,
что у нашего окружения уже есть браузер и драйвер для него. Потому что все это
настраивается и устанавливается в момент сборки самого образа.
3. Также у нас есть скрипт sh, который выполняется после старта контейнера.
Аналогично все по отношению к хабу.
В итоге запуск selenium grid в контейнере сводится к одной команде — старт
докер-контейнера.

5.3. Отчеты Cucumber Reports

Cucumber Reports – плагин Jenkins, который позволяет публиковать результаты
прогонов тестов Cucumber в виде красивых HTML-отчетов, размещенных на сервере
сборки Jenkins.
После выполнения тестов на Cucucmber необходим подробный отчет, чтобы
проинформировать команду о благополучии нашего приложения и сравнить релизы,
если возникнет какая-либо ошибка. Плагин преобразует отчет json в обзорный html-
файл с ссылками на отдельные html файлы по каждой фиче, со статистикой и
результатами.

https://libraries.io/github/jenkinsci/cucumber-reports-plugin
https://github.com/jenkinsci/cucumber-reports-plugin
https://plugins.jenkins.io/cucumber-reports/
https://jenkins.io/doc/pipeline/steps/cucumber-reports/#cucumber-cucumber-
reports

https://medium.com/faun/running-cucumber-tests-with-jenkins-a5a3a8df07eb
https://cucumber.io/docs/cucumber/reporting/#built-in-reporter-plugins

Чтобы использовать с обычным огурцом, просто запустите огурец следующим

образом: cucumber --plugin json -o cucumber.json

https://github.com/jenkinsci/cucumber-reports-plugin
http://www.seleniumframework.com/continuous-test-automation/cucumber-
jenkins-plugins/
5.3.1. По фичам

5.3.2. По тегам