Все мы знакомы с термином “DevOps”.  Для кого-то это смежный отдел в компании, а для кого-то – коллега из соседней комнаты. Но в первую очередь это методология, которая меняет и проходит через множество процессов разработки. Автоматизация тестирования здесь не является исключением. Автотесты неразрывно связаны с такими понятиями, как «непрерывная интеграция», «непрерывное развертывание», “pipelines”, ведь тесты мы пишем не для себя и не для запуска на нашей локальной машине. Для автоматического запуска тестов всей командой необходимо настроить приличное количество компонентов, тут мы и обращаемся за помощью к DevOps отделу. В этой статье мы рассмотрим базовые технологии и инструменты из мира DevOps, необходимые для запуска E2E тестов, написанных с помощью Selenium для Web и Appium для mobile.

Требования для запуска тестов

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

Предположим, у нас есть 50 Selenium тестов для Web и 50 Appium тестов для Android. Допустим, все тесты написаны по известным best practice: атомарные, независимые друг от друга, без ложных падений. Теперь составим список требований для того, чтобы вся команда могла этими тестами пользоваться.

1. Тесты должны запускаться автоматически при каждой отправке кода в ветку разработчика и блокировать merge ветки в master в случае ошибок.

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

3. Тесты должны проходить за определенное количество времени (например, 5 минут) как для Web, так и для Android.

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

Инфраструктурные инструменты

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

№1 - Git

Самой популярной системой контроля версий является Git. Большинство из нас владеет и пользуется им на регулярной основе. Именно Git лежит в основе построения pipelines, так как все начинается с добавления (push) разработчиком своего кода в  ветку разработки. Git еще не покрывает наше первое требование, но является предусловием для его выполнения.

№2 - CI /  CD

Для полного выполнения первой задачи нам необходима технология, позволяющая запускать тесты автоматически на какое-либо событие (например, push) и устанавливающая набор правил в случае неудачного запуска (например, блокировка кнопки merge). Именно за это и отвечают CI / CD инструменты, которых сейчас на рынке большое количество (Jenkins, GitLab CI, TeamCity). И если быть более точным с точки зрения терминологии, раз мы говорим о Selenium и Appium E2E тестах, то речь идет именно о построении CD (Continues Delivery) процесса. Подразумевается, что сначала мы должны развернуть и привести наш тестовый стенд в нужное состояние, применив новые изменения разработчика, а уже потом запускать тесты в браузерах и эмуляторах. На этом выполнение первой задачи завершено.

№3 - Docker

Для выполнения второй задачи нам нужно установить и настроить инструмент логирования. Сам инструмент в контексте данной статьи нам не очень интересен, поэтому для примера можем взять один из самых популярных, например, Allure или Report Portal. Но тот же Report Portal состоит из множества взаимосвязанных компонентов, каждый из которых может обновляться отдельно (см. скриншот). В отдельной части находится сервис, отвечающий за пользовательский интерфейс, в другой сервис для сбора метрик,  в третьей – сервис, предоставляющий api, и так далее. Каждая из этих частей упакована в изолированное пространство, называемое контейнером. Docker же это компания, которая популяризировала технологию контейнеризации. Поэтому часто говорят: “Docker container”.

Для полноценной работы всего инструмента  необходимо запустить все эти взаимосвязанные контейнеры вместе, и на этом установка будет завершена. Мы не должны думать про зависимости, что этим компонентам необходимо для запуска, или о версиях инструмента. Разработчики Report Portal уже обо всем позаботились за нас и зашили все необходимое внутри контейнеров. Вторая задача завершена! Но для полноценного раскрытия потенциала Docker перейдем к третьей задаче. 

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

Рассмотрим инструменты параллельного запуска Selenium и Appium тестов и кратко обсудим, как нам помогает Docker в контексте их запуска.

1. Selenium grid

Очевидно из названия, Selenium grid является официальным и самым известным инструментом параллельно запуска Selenium тестов. Он состоит из двух групп компонент: Hub (центральный узел, принимающий все запросы на запуск тестов) и множество Nodes (узлы, где запускаются браузеры и выполняются тесты). По аналогии с Report Portal, мы можем разделить их на разные контейнеры, например, Hub в отдельном контейнере и 50 Nodes контейнеров с браузерами, если мы хотим запускать 50 тестов одновременно. Контейнеризация дает нам следующие преимущества:

• каждый браузер независим от остальных, так как запускается в своем изолированном пространстве;

• не нужно переживать о совместимости версий браузера и драйвера, все уже вшито в контейнер;

• если хотим сменить версию браузера и драйвера, то просто создаем новый Docker образ и на его базе новые контейнеры. Никакой ручной работы.

  2. Selenoid

Еще одним популярным инструментом для параллельного запуска является Selenoid. Выделю два (их больше) основных отличия от Selenium grid:

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

• Selenoid позволяет запускать внутри контейнеров Android Emulators, что позволяет запускать E2E Android тесты.

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

Это еще не конец

В статье мы рассмотрели только базовые технологии для запуска наших тестов. Мы не затронули железную составляющую, ведь даже в контейнерах для запуска Web браузеров и Android эмуляторов нужны вычислительные ресурсы (CPU и память). Где взять такие ресурсы и как ими правильно пользоваться, мы обсудим в отдельной статье, посвященной продвинутым инструментам. 

Также мы не рассмотрели тему инфраструктуры для запуска IOS тестов. Так как из-за политики компании Apple мы не можем запускать IOS симуляторы в Docker контейнерах, то правила игры здесь меняются – к сожалению, в сторону удорожания. 

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

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

А уже завтра состоится вебинар «Реализация подхода DDT в автотестах», на котором разберемся, что из себя представляет подход DDT (Data Driven Testing), в чём его плюсы/минусы и как его можно реализовать, используя pytest. Регистрируйтесь по ссылке.