5.

Процесс запуска автотестов

5.1. Виды запуска
5.1.1. Локальный запуск

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

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-
массива, в котором содержится вся информация по ноде.
 Следующая задача ноды — это исполнение тех запросов, которые она
принимает через хаб после того, как тот создал сессию с этой нодой.
 Под запросами я подразумеваю те команды, которые шлет наш jar-ник с
автотестами. Как пример, командой будет какой-нибудь шаг типа “Найди мне кнопку
на данной странице со следующим id”. Соответственно, хабу чтобы выполнить такой
шаг теста, нужно знать, к какому вообще тесту относится данный шаг. Ведь в один
момент он может выполнять несколько тестов. И этот шаг подразумевает, что тот, кто
будет выполнять эту команду, уже выполнил какую-то предысторию из других
команд, например, перешел как раз таки на соответствующую страницу. Вот именно
для этого и нужен уникальный идентификатор сессии с браузером в ноде, который
создает хаб и затем по этому ИД понимает, на какую ноду ему распределять запросы.
 Нода же просто ждет команды от хаба, и при получении http-запросов,
которые он перенаправляет на нее — она их выполняет.

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

Далее нам необходимо указать нашим тестам, чтобы они ходили на удаленные браузеры. Для этого
идем в файл env.rb и добавляем следующие настройки

5.2.7. Установка gem parallel_tests

Установка gem parallel_tests
Для того, чтобы наш сервер выполнял тесты в несколько потоков нам необходимо их распаралелить.
Для этих целей мы использовали гем parallel_tests
Установка стандартная. Добавляем gem "parallel_tests", :group => :development в Gemfile
Далее идем в настройки сборки на Jenkins’e
Нам необходимо создать дополнительные базы данных для выполнения тестов.
 А именно:

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
Чем же отличается старт грида в докер-контейнерах?

1. Нода на момент старта уже сконфигурирована.

Давайте посмотрим на содержимое ноды. Файл с json-конфигом для ноды находится в контейнере с
ней, затем мы его переименовываем, и наш сервер узнает о своих параметрах из этого файла:
/opt/selenium/generate_config > /opt/selenium/config.json
При этом если мы посмотрим на содержимое Dockerfile самой ноды, то увидим, что при
конфигурировании окружения ноды мы сразу задаем переменные окружения, которые потом записываются в
этот конфиг. Таким образом, нам не нужно лезть в “кишки” самого контейнера, чтобы изменить параметры
запуска ноды, нам достаточно в Dockerfile переопределить значения указанных переменных. И все.
2. Когда мы стартуем ноду в контейнере, мы всегда можем быть уверены в том, что у нашего
окружения уже есть браузер и драйвер для него. Потому что все это настраивается и устанавливается в
момент сборки самого образа.
$ /opt/selenium$ ls
chromedriver-2.29
selenium-server-standalone.jar
config.json
3. Также у нас есть скрипт sh, который выполняется после старта контейнера. И в этом скрипте мы
видим, что после того, как у нас поднялся контейнер — у нас сразу же стартует наш java сервер.

$ java ${JAVA_OPTS} -jar /opt/selenium/selenium-server-standalone.jar \

-role node \
-hub http://$HUB_HOST:$HUB_PORT/grid/register \
-nodeConfig /opt/selenium/config.json \
${SE_OPTS} &
Аналогично все по отношению к хабу.
В итоге запуск selenium grid в контейнере сводится к одной команде — старт докер-контейнера.
5.3. Отчеты Cucumber Reports
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. По тегам