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

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

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

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

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

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

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

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

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

Команда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Положение

Эффект

Больше использовать в тестах rest API, меньше UI.

Это продиктовано более надежной и быстрой работой самого теста. Разработка и поддержка такого теста существенно дешевле, чем прохождение БП через UI. Но все же без использования UI в тестах не обошлось. В нашей компании сохраняется небольшое число крупных систем в виде монолита, у которых нет своих rest-api. В этих системах проводится крупный рефакторинг (перевод на микросервисы), но процесс этот не быстрый.

Генерация моделей на основе swagger-документов.

Генерируем модель сервиса на основе его swagger. На выходе получаем python-объект (со всеми методами из swagger), с которым работаем уже в тесте.

Совместная с другими командами разработка python-модулей и использование их в тестах.

 

Обсудили со смежной командой этот подход и решили его придерживаться. На каждый микросервис, с которым взаимодействуем в тесте, пишем python-модуль (пакет), помещаем его в pypi-репозиторий (nexus). Если необходимо написать тест на БП, в которых участвуют микросервисы, для которых уже существует python-модули, то задача сводится лишь к тому, чтобы собрать конструктор из этих модулей (загрузив их из биржевого pypi-хранилища) и описать тестовый кейс.

Генерация уникальных тестовых данных runtime.

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

Никаких зависимых тестов – все необходимые данные готовим фикстурами перед каждым тестом. Там, где нужно – подчищаем за собой после теста.

Все тесты атомарные, можно запустить любой из них когда угодно.

 

Детальное логирование всех запросов (http, sql, ftp, smb…).

Легко найти запрос и ответ в консоли выполнения теста. Особенно полезно при выяснении причин падения теста.

Маркировка тестов списком микросервисов и БП.

Легко запускать группы тестов по маркировке: бизнес-процесс/микросервис

Сбор всех инцидентов в БП.

Помогает в разборе падения тестов. Инциденты собираются на основе маркировок.

Сбор всех логов микросервисов при падении автотеста.

Помогает в разборе падения тестов. Логи собираются на основе маркировок.

Иметь все необходимые системы, сервисы и интеграции на стенде разработки автотестов.

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

Проведение ежедневных митингов.

Решаем технические проблемы.

Использование практики дежурства

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

- разбор ночных прогонов на QA/UAT;

- заведение артефактов на актуализацию автотестов;

- заведение артефактов на ошибки/улучшение в сервисах;

- актуализация конфигов сервисов; поддержка тестового контура.

Полигоны

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

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

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

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

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

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

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

Инструменты

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

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

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

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

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

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

CI/CD

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

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

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

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

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

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

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

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

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

Рисунок 1. Общий план выполнения ночного pipeline по подготовке стенда (-ов) для запуска E2E-тестов.
Рисунок 1. Общий план выполнения ночного pipeline по подготовке стенда (-ов) для запуска E2E-тестов.

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

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

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

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

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

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

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

Рисунок 2. Запуск автотестов
Рисунок 2. Запуск автотестов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Рисунок 3. UI сервиса статистики.
Рисунок 3. UI сервиса статистики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Рисунок 4. Сервис дашборды: общая информация по заведенным артефактам командой E2E.
Рисунок 4. Сервис дашборды: общая информация по заведенным артефактам командой E2E.
 Рисунок 5. Сервис дашборды: статистика по jira-артефактам в разрезе проектов.
Рисунок 5. Сервис дашборды: статистика по jira-артефактам в разрезе проектов.
 Рисунок 6. Сервис дашборды: статистика по открытым/закрытым артефактам с разбивкой по месяцам.
Рисунок 6. Сервис дашборды: статистика по открытым/закрытым артефактам с разбивкой по месяцам.
 Рисунок 7. Сервис дашборды: статистика по прошедшим сборкам автотестов за последние 7 дней.
Рисунок 7. Сервис дашборды: статистика по прошедшим сборкам автотестов за последние 7 дней.
 Рисунок 8. Сервис дашборды: статистика по продолжительности/количеству автотестов с разбивкой по месяцам.
Рисунок 8. Сервис дашборды: статистика по продолжительности/количеству автотестов с разбивкой по месяцам.

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

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

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

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

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

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

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

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

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

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

 Рисунок 9. Сервис, помогающий в дежурстве: главная страница сервиса.
Рисунок 9. Сервис, помогающий в дежурстве: главная страница сервиса.
 Рисунок 10. Сервис, помогающий в дежурстве: списки установленных и неустановленных микросервисов.
Рисунок 10. Сервис, помогающий в дежурстве: списки установленных и неустановленных микросервисов.
 Рисунок 11. Сервис, помогающий в дежурстве: отчет по запущенным пайпланам автодеплоя.
Рисунок 11. Сервис, помогающий в дежурстве: отчет по запущенным пайпланам автодеплоя.
 Рисунок 12. Сервис, помогающий в дежурстве: отчет по запущенным пайпланам автодеплоя.
Рисунок 12. Сервис, помогающий в дежурстве: отчет по запущенным пайпланам автодеплоя.
 Рисунок 13. Сервис, помогающий в дежурстве: отчет по различиям в конфигурациях волта между разными стендами.
Рисунок 13. Сервис, помогающий в дежурстве: отчет по различиям в конфигурациях волта между разными стендами.

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

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

 Рисунок 14. Доска в wiki для планирования E2E-задач.
Рисунок 14. Доска в wiki для планирования E2E-задач.

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Комментарии (3)


  1. alexandersadykov
    21.09.2023 11:13

    Выполнена большая работа, молодцы!

    Вопрос: ведете ли вы в каком-то виде расчет по формальным показателям ROI при выборе БП на E2E автоматизацию?


    1. ren_qa Автор
      21.09.2023 11:13

      Добрый день! Спасибо за вопрос!

      Расчет по формальным показателям ROI при выборе бизнес-процессов на e2e-автоматизацию у нас нет, так как в основном список этих БП формирует заказчик на основании своих собственных метрик (затраты на проведение 1 цикла регресса, частота проведения данного регресса и пр.). После нашего анализа технического задания по БП и консультации с заказчиком у нас появляется своя метрика, которая звучит как "высвобождение человеко-дней на тестирование 1 цикла данного БП у бизнес-пользователей и операционных подразделений". С этой метрикой мы и работаем.


      1. alexandersadykov
        21.09.2023 11:13

        все понятно, спасибо!