Всем привет! Меня зовут Ренат Дасаев. Являюсь руководителем направления интеграционного автотестирования в компании MOEX и сегодняшний рассказ будет посвящен истории процесса внедрения E2E-автотестов в тестирование бизнес-процессов Московской Биржи. В статье расскажу про наиболее важные аспекты, фичи и сервисы нашего направления. Забегая вперёд, скажу, что сейчас это одно из самых востребованных направлений тестирования в Группе компаний.

Для начала вкратце разберемся, что такое E2E-автотест. Это вид тестов, который проверяет бизнес функционал от момента его начала до завершения.

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

Предпосылки внедрения E2E-автотестирования

Многие компании, в том числе и наша, сталкиваются с дорогостоящим тестированием бизнес-пользователей на стендах UAT (User Acceptance Testing):

• Поддерживать такой стенд — это большая задача, так как здесь представлены абсолютно все интеграции, как и на промышленном контуре. Полигон обновляется каждый день множеством версий различных микросервисов от разных продуктовых команд;

• бизнес-пользователям необходимо выделять время на проведение тестирования в отрыве от их основной работы - операционной деятельности в промышленном контуре. А представьте себе, что для проверки бизнес-процесса (далее БП) необходимо участие нескольких подразделений и каждое подразделение должно последовательно выполнять шаги, то есть на синхронизацию между подразделениями также уходит время. А если где-то случается ошибка в интеграции/данных/конфигурациях, то нужно снова всё начинать сначала после исправления ошибки;

• помимо тестирования нового функционала, бизнес-пользователям нужно проверять ещё критичные регрессионные кейсы, которые могли быть затронуты внедряемым изменением.

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

Команда

Для достижения выше поставленных задач была создана команда (в скобках поясняем, чем занимается на данном направлении):

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

• руководитель направления (техническая проработка потребности, делегирование задач в команде, участие в разработке автотестов и CI/CD процессов);

• ведущий разработчик автотестов (разработка автотестов, развитие CI/CD процессов);

• начинающий разработчик автотестов (разработка автотестов).

С недавнего времени нам также помогает бизнес-аналитик из нашего Управления с анализом функциональных задач, полученных от заказчика.

Направление E2E-автотестирование стартовало в феврале 2022 года.  Далее расскажем, как мы отбираем задачи для покрытия автотестами.

Процесс отбора функционала для E2E-тестов

Критериев для отбора бизнес-процессов на покрытие e2e-автотестами несколько:

• На ручную проверку функционала бизнес-пользователи регулярно тратят много своего времени, которое они могли бы направить в более ценное русло;

• БП проходит через несколько систем;

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

После определения трудозатрат и внесения БП в план на автоматизацию, заказчик приступает к написанию ТЗ (техническое задание) и описывает сценарии тестов, если их еще нет. Эту часть работы мы зачастую выполняем вместе с заказчиком для более глубокого погружения.
В ТЗ описываются сценарии тестов с отражением всех используемых параметров. Как правило, автоматизации подлежат всего 1–2 сценария, в основном позитивные (негативные практикуются тоже, но это скорее исключение).

Почему так мало сценариев тестирования:

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

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

Теперь перейдём к технической части вопроса.

Особенности процесса разработки E2E-тестов

При разработке автотестов стараемся придерживаться следующих положений:

Таблица 1. Список положений и эффект от их применения

Полигоны

В нашей компании представлено много полигонов. Мы используем несколько из них:

• QA – полигон для внутреннего тестирования. Для целей E2E развернуто два k8s-кластера с микросервисами, которые участвуют в БП, покрываемых тестами. Внутри этих кластеров есть множество неймспейсов (пространство имен), которые используются как инженерами по автоматизации тестирования смежных команд, так и инженерами функционального тестирования. На данном полигоне мы разрабатываем и отлаживаем тесты;

• UAT (stage) – полигон приемочного тестирования. Данный полигон повторяет промышленный как по данным (на определенную дату), так и конфигурационно. На нем тестируются текущие боевые версии систем и перспективные релизы. После разработки автотеста на QA мы включаем новый тест в сборку для прогона уже на UAT. Это целевой полигон для наших тестов, т. к. здесь же тестируются заказчики. На данном стенде раскатываются уже проверенные сборки сервисов с других стендов QA, проверенные конфигурации и пр. Таким образом исключаются нестабильности и прогон тестов очень показателен. Особенно важен прогон автотестов за день до крупных релизов (участие в quality gates). Перед крупными релизами к нам обращаются продуктовые команды с целью прогнать тесты на тот или иной функционал, чтобы убедиться:

  • критичный функционал работает, как и ранее (код, который не менялся, т. е. регрессионное тестирование);

  • конфигурации и сетевая связанность сервисов в рабочем состоянии и корректны;

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

• PROD – полигон промышленной эксплуатации. На данном полигоне мы пока не запускаем E2E-автотесты на регулярной основе, но в планах на текущий год такая задача имеется.

Инструменты

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

Тестовый фреймворк

• разработка автотестов и фреймворка ведется на языке программирования Python 3.8 (в текущем году планируется переход на 3.11);

• в качестве тест-менеджера используется Pytest;

• для работы с backend в основном используются:

  • rest-api: обертка над requests;

  • databases: ORM (SQLAlchemy), fdb (Firebird engine), cx_oracle (Oracle engine), psycopg2 (postgresql);

  • UI: обертка над selenium;

• исходный код автотестов и фреймворка хранится в git.

CI/CD

Наш CI/CD – конвейер состоит из:

• Jenkins – запуск автотестов;

• GitlabCI – работа с конфигурациями, исходным кодом, создание базовых образов сервисов и тестов;

• Vault – хранение конфигов для микросервисов;

• Nexus – хранилище артефактов различного типа (docker, pypi и др.).

Как правило, конвейер завершает свою работу:

• генерацией образа и отправки его в nexus;

• и/или разворачиванием deployment в k8s через helm (где запускаются сервисы/тесты).

Ниже (см. рисунок 1) схематично изображен базовый pipeline по ночному регрессионному автотестированию в нашей команде.

Под стендом подразумевается совокупность всех k8s – кластеров, баз данных, торговых систем, шин и прочего, что покрывается интеграционными автотестами в рамках БП.

Запуск тестов

В запуске автотестов участвует самописный скрипт, который обходит папку tests и составляет списки тестов со всеми маркировками (в том числе своими). На выходе получаем несколько списков тестов:

• которые можно запускать только в одном потоке;

• которые можно запускать в несколько потоков (через multiprocessing. pool).

Также в каждом из этих списков учитывается время, пришедшее от сервиса статистики.

Затем, в зависимости от числа исполнителей, выполняется распараллеливание тестов (см. рисунок 2)

E2E-автотесты могут запускаться:

• по расписанию каждую ночь на QA/UAT-полигонах посредством нашего CI/CD – сервера Jenkins;

• при изменениях в версиях микросервисов, которые участвуют в покрытых БП (на основании маркировок) в течение дня (GitlabCI + Jenkins);

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

Результаты тестов

Важно не только прогнать автотесты, но и получить отчет, по которому можно легко анализировать:

• сколько тестов упало;

• места падений;

• сообщения об ошибках;

• логи микросервисов, скриншоты.

У нас используется:

• allure framework: для построения отчетности на уровне инженеров автоматизации тестирования непосредственно в Jenkins;

• allure test ops: для построения отчетности на уровне руководства.

Среди инструментов имеются полноценные сервисы (backend + frontend), которые мы разработали с нуля своими силами.

Сервис статистики

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

В данном сервисе есть разделение тестов по типу запуска – regress (как правило весь набор тестов)/smoke, а также debug (одиночный запуск)/multiple (с распараллеливанием). В зависимости от того, с какими параметрами запустилась сборка на CI/CD, из сервиса статистики запрашивается та или иная информация (формируется json на стороне тестового фреймворка и отправляется в сервис).

Данный сервис установлен как на QA-полигоне, так и на UAT-полигоне.

Основные параметры:

• сервис написан на Python 3.8 с использованием библиотек: Django, Django REST Framework, Marshmallow;

• для Django используются вспомогательные библиотеки: django-bootstrap4 , django-crispy-forms, django-filter и django-tables2;

• в качестве БД используется SQLite;

• для тестирования используется библиотека PyTest;

• на Gitlab CI используются библиотеки: Coverage, Coverage-Badge и AnyBadge.

Сервис дашборды для руководства

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

• артефакты, заведенные командой E2E в разрезе проектов, типов и времени:

  • o   можно с легкостью узнать, сколько и каких типов артефактов завели в любой месяц;

  • агрегировать число артефактов за определенный период в любом проекте;

  • соотношение числа открытых и закрытых артефактов по месяцам.

• численные параметры прогонов тестов на UAT, из которых можно легко узнать:

  • с каким результатом выполняются прогоны (число падений);

  • как меняется число автотестов со временем;

  • как изменяется время исполнения тестов.

Прежде всего этот инструмент разрабатывался для руководства, чтобы оценивать метрики эффективности команды E2E.

Данный сервис установлен только на UAT-полигоне.

Основные параметры:

• сервис написан на Python 3.8 с использованием библиотек: Dash, Gunicorn, Plotly, Pandas, самописные модули по работе с jira и сервисом статистики;

• на Gitlab CI используются библиотеки: Coverage, Coverage-Badge и AnyBadge.

Теперь посмотрим на сервис дашборды в картинках (см. рисунок 4-8) чтобы лучше понимать в каком виде мы визуализируем информацию.

Сервис, помогающий в дежурстве

 Сервис по формированию различных отчетов по мониторингу окружений с CI/CD процессов позволяет получить ответы на следующие вопросы:

• какие сервисы и версии установлены на тестовом стенде;

• насколько успешно работают процессы по автоматическому обновлению сервисов в течение дня и запуска после их обновлений смоук-тестов;

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

Данный сервис установлен только на QA-полигоне. На UAT у нас нет доступа к системе управления версиями микросервисов. Но у нас есть доступ (как и подписка) к проекту в баг-трекинговой системе, через который проходят все артефакты, и поэтому мы в курсе, какие версии ушли на данный полигон.

Основные параметры:

• сервис написан на Python 3.8 с использованием библиотек: Flask, Werkzeug, Gunicorn, самописная библиотека по работе с gitlabci;

• на Gitlab CI используются библиотеки: Coverage, Coverage-Badge и AnyBadge.

Традиционно ниже представляем скриншоты данного сервиса (рисунок 9-13).

Дашборды для квартального планирования деятельности направления E2E

 Также у нас есть доска, созданная в wiki, которая позволяет увидеть общее планирование всех задач на нашем направлении по кварталам со всеми оценками по трудоемкости и другими атрибутами.

Результаты направления за год и планы на будущее

Почти 1,5 года пролетели незаметно, и мы можем подвести промежуточные итоги нашей работы по направлению E2E-автотестирования бизнес-процессов:

• бизнес-процессы:

  • покрыто 42 интеграционных БП Операционного блока, что высвободило у бизнес-пользователей 25,2 человеко-дня при проведении всего того регрессионного тестирования на UAT, что покрыто автотестами. При этом запуски Е2Е тестов проводятся не несколько раз за релиз (как руками бизнес-пользователей до этого), а каждую ночь или при каждом обновлении сервиса, покрытого е2е тестом. Релизный график больших информационных систем в нашей компании как правило раз в полтора месяца. Есть системы, которые выпускаются на еженедельной основе;

  • выстроен процесс отбора и согласования задач на автоматизацию E2E;

  • заведено более 278 артефактов в баг-трекинговую систему;

• процессы автоматизации:

  • испробован новый подход с разделяемыми модулями, и он полностью себя оправдал. На данный момент со смежными командами (привет команде автоматизации тестирования проекта ЦУП/ЦРММ ????) разработано более 140 модулей по работе с rest-api микросервисов, базами данных фондового и валютного рынка, взаимодействующих с внешними сервисами, утилитами;

  • разработаны 3 сервиса (сервис статистики/дашборды/дежурства), которые предоставляют очень нужную информацию как для инженеров по автоматизации тестирования, так и для руководства;

  • выстроено множество CI/CD процессов по деплою сервисов, запуску автотестов, зачистке данных и др.

Руководство позитивно оценило нашу работу и ставит новые амбициозные цели, например:

• увеличение числа покрываемых систем и БП интеграционными тестами;

• верификация релизных установок в промышленный контур путем запуска E2E-автотестов.

Заключение

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

Спасибо всем, кто дочитал эту статью до конца. Если остались вопросы, пишите их в комментариях – с радостью ответим!

Особую благодарность хочу выразить своему начальнику управления - Дмитрию Чугую за помощь в старте данного направления и подготовке материала для публикации.