Home

Автор: Алтунин Алексей
Оригинал статьи
Перевод: Алтунин Алексей

Часть 1: Web / Android

Примечание: данная статья является переводом на русский язык оригинальной статьи "DevOps tools are not only for DevOps. Building test automation infrastructure from scratch." Однако все иллюстрации, ссылки, цитаты и термины сохранены на языке оригинала,чтобы избежатьискажения смысла при переводе на русский язык. Желаю вам приятного изучения!

В настоящее время специальность DevOps является одной из наиболее востребованных в IT-индустрии. Если вы откроете популярные сайты по поиску работы и зададите фильтр по зарплатам, то увидите, что вакансии, связанные с DevOps, находятся в начале списка. Однако важно понимать, что это в основном относится к позиции ‘Senior’, что подразумевает, что кандидат обладает высоким уровнем навыков, знанием технологий и инструментов. К этому также прилагается высокая степень ответственности, связанная с бесперебойной работой production. Однако мы стали забывать, что такое DevOps. Изначально это не был какой-то конкретный человек или департамент. Если поискать определения этого термина, то мы найдем много красивых и правильных существительных, таких как методология, практики, культурная философия, группа концептов и так далее.

Моя специализация – инженер по автоматизации тестирования (QA automation engineer), но я считаю, что она не должна быть связана только с написанием авто-тестов или разработкой архитектуры тестового framework. В 2020 году знания инфраструктуры автоматизации также необходимы. Это позволяет организовать процесс автоматизации самостоятельно, начиная от запуска тестов и заканчивая предоставлением результатов всем заинтересованным лицам в соответствии с поставленными целями. В результате чего, навыки DevOps являются обязательным фактором для выполнения данной работы. И все это хорошо, но, к сожалению, есть проблема (spoiler: данная статья делает попытки упростить это проблему). Она заключается в том, что DevOps – это сложно. И это очевидно, ведь компании не станут платить много за то, что легко сделать. В мире DevOps большое количество инструментов, терминов, практик, которыми нужно овладеть. Особенно это тяжело дается в начале карьеры и зависит от накопленного технического опыта.

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

О чем эта статья

В этой статье я собираюсь поделиться моим опытом построения инфраструктуры автоматизации тестирования. В интернете можно найти много источников информации о различных инструментах и как их использовать, но я бы хотел рассмотреть их исключительно в контексте автоматизации. Я полагаю, что многим инженерам по автоматизации знакома ситуация, когда разработанные тесты, кроме вас самих, никто не запускает и не заботится об их поддержке. В результате чего тесты становятся устаревшими и приходится тратить время на их актуализацию. Опять же в начале карьеры это может быть довольно сложной задачей: грамотно решить, какие инструменты должны помочь устранить данную проблему, как их выбрать, настроить и поддерживать. Некоторые тестировщики обращаются за помощью к DevOps (людям) и, будем честными, такой подход работает. Во многих случаях это может быть единственным вариантом, так как у нас отсутствует видимость всех зависимостей. Но, как мы знаем, DevOps – очень занятые ребята, ведь они должны думать об инфраструктуре всей компании, deployment, мониторинге, микросервисах и о других подобных задачах в зависимости от организации/команды. Как это обычно бывает, автоматизация не является приоритетом. В таком случае мы должны попытаться сделать все возможное с нашей стороны от начала и до конца. Это уменьшит зависимости, ускорит рабочий процесс, усовершенствует наши навыки и позволит увидеть более широкую картину происходящего.

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

Чего в этой статье нет

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

Это сделано по причине того, что:

• этот материал очень легко найти в различных источниках (документация, книги, видео курсы);
• если мы начнем углубляться, то придется написать 10, 20, 30 частей данной статьи (тогда как в планах 2-3);
• я просто не хочу тратить ваше время, так как, возможно, вы хотите использовать другие инструменты для достижения тех же целей.

Практика

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

План

Структура каждой секции

Для поддержания повествования в наглядном виде, каждая секция описана по следующему плану:

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

1. Локальный запуск тестов

Краткое описание технологии

Это всего лишь подготовительный шаг для запуска демонстрационных тестов локально и для проверки, что они успешно проходят. В практической части используется Node.js но язык программирования и платформа также не важны и можно использовать те, что используются в вашей компании.

Однако в качестве инструментов автоматизации я рекомендую использовать Selenium WebDriver для web-платформ и Appium для Android-платформы соответственно, так как на следующих шагах мы будем использовать Docker-образы, которые заточены на работу конкретно с этими инструментами. Более того, ссылаясь на требования в вакансиях, эти инструменты наиболее востребованы на рынке.

Как вы могли заметить, мы рассматриваем только web и Android-тесты. К сожалению, IOS – совершенно другая история (спасибо Apple). Я планирую продемонстрировать решения и практики, связанные с IOS, в следующих частях.

Ценность для инфраструктуры автоматизации

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

Иллюстрация текущего состояния инфраструктуры

• Ссылки для изучения:
  • Selenium
  • Appium
  • Android Emulator
  • Selenium JS GitHub examples
  • Appium JS GitHub examples

• Аналогичные инструменты:
  • любой язык программирования, который вам нравится, в связке с Selenium/Appium - тестами;
  • любые тесты;
  • любой тест-раннер.

2. Системы контроля версий (Git)

Краткое описание технологии

Ни для кого не будет большим открытием, если я скажу, что система контроля версий – чрезвычайно важная часть разработки как в команде, так и индивидуально. Опираясь на различные источники, можно с уверенностью сказать, что Git является наиболее популярным представителем. Система контроля версий дает множество преимуществ, таких как обмен кодом, хранение версий, восстановление на предыдущие ветки, мониторинг проектной истории, бэкапы. Мы не будем обсуждать каждый пункт в деталях, так как я уверен, что вы с этим хорошо знакомы и используете в повседневной работе. Но если вдруг нет, то я рекомендую приостановить чтение данной статьи и как можно скорее восполнить данный пробел.

Ценность для инфраструктуры автоматизации

И тут вы можете задать резонный вопрос: “Зачем он нам рассказывает о Git? Все это знают и используют как для кода разработки, так и для кода авто-тестов”. Вы будете абсолютно правы, но в этой статье мы говорим об инфраструктуре и данная секция играет роль превью для секции 7: “Инфраструктура как код (IaC)”. Для нас это означает, что вся инфраструктура, включая тестовую, описывается в виде кода, соответственно мы к ней тоже можем применить системы версионирования и получить аналогичные преимущества как для кода разработки и автоматизации.

Мы рассмотрим IaC более детально на шаге 7, но даже сейчас можно начать использовать Git локально, создав локальный репозиторий. Общая картина будет расширена, когда мы добавим к инфраструктуре удаленный репозиторий.

Иллюстрация текущего состояния инфраструктуры

• Ссылки для изучения:
  • What is version control
  • Git
  • Getting Started - About Version Control

• Аналогичные инструменты:
  • SVN
  • Mercurial
  • Microsoft TFS (now is part of Azure DevOps Services)

3. Контейнеризация (Docker)

Краткое описание технологии

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

Следующим этапом эволюции стали виртуальные машины (VM), которые решили проблему траты средств на неиспользуемые ресурсы. Эта технология позволила запускать приложения независимо друг от друга внутри одного сервера, выделяя полностью изолированное пространство. Но, к сожалению, любая технология имеет свои недостатки. Запуск VM требует полноценной операционной системы, которая потребляет CPU, RAM, хранилище и, в зависимости от OS, нужно учитывать расходы на лицензию. Эти факторы влияют на скорость загрузки и усложняют переносимость.

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

Конечно, технология контейнеризации не является чем-то новым и впервые была представлена в конце 70-х. В те времена проводилось много исследований, наработок, и попыток. Но именно Docker адаптировал эту технологию и сделал ее легкодоступной для масс. В наше время, когда мы говорим о контейнерах, в большинстве случаев мы имеем ввиду Docker. Когда мы говорим о Docker-контейнерах, мы подразумеваем Linux-контейнеры. Мы можем использовать Windows и macOS-системы для запуска контейнеров, но важно понимать, что в таком случае появляется дополнительная прослойка. Например, Docker на Mac незаметно запускает контейнеры внутри легковесной Linux VM. Мы еще вернемся к этой теме, когда будем обсуждать запуск Android-эмуляторов внутри контейнеров, так так здесь появляется очень важной нюанс, который необходимо разобрать более подробно.

Ценность для инфраструктуры автоматизации

Мы выяснили, что контейнеризация и Docker – это круто. Давайте посмотрим на это в контексте автоматизации, ведь каждый инструмент или технология должны решать какую-либо проблему. Обозначим очевидные проблемы автоматизации тестирования в контексте UI-тестов:

• огромное количество зависимостей при установке Selenium и в особенности Appium;
• проблемы совместимости между версиями браузеров, симуляторов и драйверов;
• отсутствие изолированного пространства для браузеров/симуляторов, что особенно критично для параллельного запуска;
• тяжело управлять и поддерживать, если необходимо запустить 10, 50, 100 или даже 1000 браузеров одновременно.

Но поскольку Selenium является самым популярным инструментом автоматизации, а Docker – самым популярным инструментом контейнеризации, то ни для кого не должно быть сюрпризом, что кто-то попытался их объединить, чтобы получить мощный инструмент для решения вышеупомянутых проблем. Рассмотрим такие решения более подробно.

Selenium grid in docker

Этот инструмент является самым популярным в мире Selenium для запуска нескольких браузеров на нескольких машинах и управления ими из центрального узла. Для запуска необходимо зарегистрировать как минимум 2 части: Hub и Node(s). Hub – это центральный узел, который получает все запросы от тестов и распределяет их по соответствующим Nodes. Для каждого Node мы можем настроить конкретную конфигурацию, например, указав нужный браузер и его версию. Однако нам все еще необходимо самим позаботиться о совместимых драйверах для браузеров и установить их на нужные Nodes. По этой причине Selenium grid не используется в чистом виде, за исключением тех случаев, когда нам нужно работать с браузерами, которые нельзя установить на Linux OS. Для всех остальных случаев значительно гибким и правильным решением будет использование Docker-образов для запуска Selenium grid Hub и Nodes. Такой подход сильно упрощает управление узлами, так как мы можем выбрать нужный нам образ с уже установленными совместимыми версиями браузеров и драйверов.

Несмотря на негативные отзывы о стабильности работы, особенно при запуске большого числа Nodes параллельно, Selenium grid все еще остается самым популярным инструментом для параллельного запуска Selenium-тестов. Важно отметить, что в open-source постоянно появляются различные доработки и модификации данного инструмента, которые борются с различными узкими местами.

Selenoid for Web

Этот инструмент является прорывом в мире Selenium, так как он работает сразу из коробки и сделал жизнь многих инженеров по автоматизации значительно проще. Прежде всего, это не очередная модификация Selenium grid. Вместо этого разработчики создали абсолютно новую версию Selenium Hub на языке Golang, что в связке с легковесными Docker-образами для различных браузеров дало толчок в развитии автоматизации тестирования. Более того, в случае Selenium Grid мы должны определить все требуемые браузеры и их версии заранее, что не является проблемой, когда работа идет только с каким-то одним браузером. Но когда речь идет о нескольких поддерживаемых браузерах, то Selenoid – это решение номер один, благодаря функции ‘браузер по требованию’. Все, что от нас требуется, это заранее выгрузить нужные образы с браузерами и обновить файл конфигурации, с которым взаимодействует Selenoid. После того как Selenoid получит запрос от тестов, он автоматически запустит нужный контейнер с нужным браузером. Когда тест завершится, Selenoid отставит контейнер, тем самым освободив ресурсы для следующих запросов. Такой подход полностью устраняет известную проблему ‘деградации узлов’, что мы часто встречаем в Selenium grid.

Но, увы, Selenoid все еще не серебряная пуля. Мы получили функцию ‘браузер по требованию’, но функция ‘ресурсы по требованию’ все еще не доступна. Для использования Selenoid мы должны развернуть его на физическом железе или на VM, что означает, что мы должны заранее знать, сколько ресурсов необходимо выделить. Я полагаю, это не проблема для маленьких проектов, которые запускают 10, 20 или даже 30 браузеров параллельно. Но что если нам нужно 100, 500, 1000 и больше? Не имеет никакого смысла поддерживать и платить за такое количество ресурсов постоянно. В секции 5 и 6 данной статьи мы обсудим решения, которые позволяют масштабироваться, тем самым значительно снижая расходы компании.

Selenoid for Android

После успеха Selenoid в качестве инструмента для web-автоматизации, люди хотели получить что-то подобное для Android. И это свершилось – Selenoid был выпущен с поддержкой Android. С высокоуровневой пользовательской точки зрения принцип работы аналогичен web-автоматизации. Единственное отличие заключается в том, что вместо контейнеров с браузерами Selenoid запускает контейнеры с Android-эмуляторами. На мой взгляд, на сегодняшний момент это самый мощный бесплатный инструмент для запуска Android-тестов параллельно.

Мне бы очень не хотелось говорить о негативных сторонах данного инструмента, так как он действительно мне очень нравится. Но все же тут присутствуют те же недостатки, относящиеся и к web-автоматизации, связанные с масштабированием. В дополнение к этому нужно рассказать о еще одном ограничении, которое может стать неожиданностью, если мы настраиваем инструмент впервые. Для запуска Android-образов нам необходима физическая машина или VM с nested virtualisation - поддержкой. В практическом руководстве я демонстрирую, как это активировать на Linux VM. Однако если вы являетесь macOS пользователем и хотите развернуть Selenoid локально, то для запуска Android-тестов это будет невозможно. Но вы всегда можете запустить Linux VM локально с настроенной ‘nested virtualisation’ и развернуть Selenoid внутри.

Иллюстрация текущего состояния инфраструктуры

В контексте этой статьи мы добавим 2 инструмента для иллюстрации инфраструктуры. Это Selenium grid для web-тестов и Selenoid для Android-тестов. В руководстве на GitHub я также покажу, как использовать Selenoid для запуска web-тестов.

• Ссылки для изучения:
  • Docker: what container is
  • Docker: get started
  • 5 Container Alternatives to Docker
  • Selenium Grid
  • Selenium docker
  • Selenoid
  • Selenoid Github
  • KVM setup for Android emulators
  • Docker Deep Dive book

• Аналогичные инструменты:
• Существуют другие инструменты контейнеризации, но Docker – самый популярный. Если вы хотите попробовать что-то еще, то учтите, что те инструменты, которые мы рассмотрели для параллельного запуска Selenium-тестов, не будут работать из коробки.
• Как уже было сказано, существует много модификаций Selenium grid, например, Zalenium.

4. CI / CD

Краткое описание технологии

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

Итак, существуют 3 термина: CI - Continuous Integration (непрерывная интеграция), CD - Continuous Delivery (непрерывная поставка) и снова CD - Continuous Deployment (непрерывное развертывание). (Далее я буду использовать эти термины на английском языке). Каждая модификация добавляет несколько дополнительных этапов к вашему конвейеру разработки. Но слово continuous (непрерывная) является самым главным. В этом контексте мы подразумеваем что-то, что происходит от начала и до конца, без прерываний или ручного воздействия. Давайте посмотрим на CI & CD и CD в данном контексте.

• Continuous Integration – это начальный шаг эволюции. После отправки нового кода на сервер, мы ожидаем получить быструю обратную связь, что с нашими изменениями все в порядке. Обычно CI включает запуск инструментов статического анализа кода и модульные/внутренние API тесты Это позволяет получать информацию о нашем коде уже несколько секунд/минут спустя.
• Continuous Delivery является более продвинутым шагом, на котором мы запускаем интеграционные/UI-тесты. Однако на данном этапе мы не получаем результаты так же быстро, как в случае с CI. Во-первых, эти типы тестов требует больше времени для прохождения. Во-вторых, перед запуском мы должны развернуть наши изменения на test/staging - среде. Более того, если мы говорим о мобильной разработке, то появляется дополнительный этап для создания сборки нашего приложения.
• Continuous Deployment предполагает, что мы автоматически выпускаем (release) наши изменения на production, если все приемочные тесты были пройдены на предыдущих этапах. В дополнение к этому после этапа release можно настроить различные этапы, такие как запуск smoke - тестов на production и сбор интересующих метрик. Continuous Deployment возможно только при хорошем покрытии автоматизированными тестами. Если требуются какие-то ручные вмешательства, в том числе и тестирование, то это больше не Continuous (непрерывное). Тогда мы можем говорить, что наш конвейер соответствует только практике Continuous Delivery.

Ценность для инфраструктуры автоматизации

В этом разделе я должен уточнить, что, когда мы говорим об end-to-end UI-тестах, это подразумевает, что мы должны разворачивать наши изменения и связанные сервисы на тестовых средах. Continuous Integration - процесс не применим для данной задачи и мы должны позаботиться о внедрении как минимум Continuous Deliver практик. Continuous Deployment также имеет смысл в контексте UI-тестов, если мы собираемся запускать их на production.

И перед тем как мы посмотрим на иллюстрацию изменения архитектуры, я хочу сказать несколько слов о GitLab CI. В отличие от других CI/CD-инструментов, GitLab предоставляет удаленный репозиторий и много других дополнительных функций. Таким образом, GitLab – это больше чем CI. Он включает из коробки управление исходным кодом, Agile управление, CI/CD pipelines, инструменты логирования и сборы метрик. Архитектура GitLab состоит из Gitlab CI/CD и GitLab Runner. Привожу краткое описание с официально сайта:

Gitlab CI/CD is a web application with an API that stores its state in a database, manages projects/builds and provides a user interface. GitLab Runner is an application which processes builds. It can be deployed separately and works with GitLab CI/CD through an API. For tests running you need both Gitlab instance and Runner.

Иллюстрация текущего состояния инфраструктуры

• Ссылки для изучения:
  • Martin Fowler: Continuous Integration
  • GitLab CI/CD
  • Continuous Integration book
  • Continuous Delivery book

• Аналогичные инструменты:
  • Jenkins
  • TeamCity
  • Travis
  • И многие другие

Продолжение следует....

Обсудить в форуме