Е2Е-тестирование: как за 2 года вырасти от внепроектной идеи до проекта и увеличить покрытие автотестами в 4 раза

Всем привет! Меня зовут Ренат Дасаев, и я продолжаю рассказ о развитии E2E‑тестирования в Московской Бирже. За два года после публикации первой статьи многое изменилось: мы переупаковали процессы, расширили команду и существенно обновили технический стек. Хотите узнать, как нам удалось масштабироваться и какие инструменты сегодня ускоряют работу? Тогда — эта статья для вас!

Изменения в команде

Наше направление изначально существовало вне проекта, что серьезно ограничивало бюджет и возможности. В 2024 году мы запустили полноценный проект, показав высокий ROI автоматизации. После сбора потребностей мы пересмотрели сотни бизнес‑процессов (БП) и выделили 215 приоритетных. План проекта рассчитан на 2,5 года, в команде — 18 человек. Найм занял десять месяцев, и сейчас коллектив работает на полную мощность.

Вот как изменилась команда количественно и качественно (табл. 1).

Таблица №1. Изменения в составе команды за два года

Связь между ролями в нашем проекте в виде схемы:

Оптимизация внутри команды

Число разработчиков автотестов выросло в 4,5 раза, поэтому мы разделили их на три доменные группы:

• Кросс‑рыночные операции — процессы, работающие на нескольких рынках

• Отчетные системы — генерация и отправка отчетов

• Листинг — постановка инструментов на торги и сопутствующие процессы

В каждой группе назначен ответственный, который:

• Отслеживает прогресс задач

• Решает внутренние технические вопросы

• Участвует в планировании

Изменения в процессах

1. Дежурство

Каждый день один разработчик автотестов из каждой подгруппы и DevOps‑инженер проверяют инциденты и падения ночного регресса. Статусы публикуются в общем треде корпоративного мессенджера — это ускоряет реакцию на проблемы.

2. Ежедневные митинги

Голосовые стендапы заменены текстовыми в мессенджере: до 09:30 каждый участник отправляет:

• Отчет о выполнении задач за вчера

• План на день

• Текущие блокеры

Плюсы:

• История задач всегда под рукой

• Руководителям проще анализировать статус

• Подготовка отчета занимает менее 5 минут

• Унификация: вся информация за день собирается в одном треде

3. Участие в финальном релизном тестировании

С прошлого года мы участвуем в финальном релизном тестировании на PROD‑контуре. Перед запуском E2E — тестов:

• Согласовываем список тестов и тестовых сущностей (участники торгов, организации, инструменты)

• Определяем тайминги и порядок обновления сервисов

• Выполняем откат тестовых сущностей

По итогам прогона готовим подробный отчет о тестировании и заводим артефакты в Jira — с ошибками и предложениями.

Технические изменения

За прошедшие 2 года изменения произошли не только в процессах, но и в техническом плане.

1. Тестовый полигон

На полигоне появились:

• Торгово — клиринговая система срочного рынка (ТКС СР)

• Личные кабинеты участника и эмитента (ЛКУ и ЛКЭ)

• Компоненты Единой регистрации клиентов (ЕРК) и рынка депозитно‑кредитных операций (ДКО):

  • торговые базы

  • базы ЭДО

• ИТАС (IT Automated Service — система обслуживания потребителей технических услуг)

• Zabbix — мониторинг QA — ресурсов с уведомлениями в мессенджер

• Apache Guacamole — песочница для разработчиков автотестов

• Nginx — кластер — SSL для тестовых сервисов

• pg_ctlcluster — управление кластерами PostgreSQL

Активно переводим тестовые ресурсы на Red OS в рамках импортозамещения.

2. Инструменты

Интерпретатор Python

Мы перешли с Python 3.8 на 3.11. Что мы получили в итоге?

• Безопасность

  • Жизненный цикл Python 3.8 закончился 7 октября 2024. Python 3.11 планируется поддерживать до октября 2027.

• Расширенная типизация (Type Hints)

• Улучшения в collections

• Улучшенная поддержка match/case (структурное сопоставление)

• Быстродействие

  • Судя по бенчмаркам улучшение в быстродействии может достигать до 20%. У нас длинные E2E-тесты, где много различных ожиданий, поэтому тут и не ждали чудес. Главное, что медленнее не стало.

Линтер и автоформатер

До этого использовали связку flake8 + isort + yapf.

К недостаткам можно отнести:

• Обновляется один компонент, скорее всего требуется обновить всю связку.

• Каждый компонент настраивается отдельно со своим конфигом.

Этих недостатков лишен ruff.

• Если какого‑то функционала в нём нет, его можно расширить через плагины.

• Единый конфиг ruff.toml или pyproject.toml.

• При небольших изменениях разница заметна лишь при внимательном сравнении. Для больших MR»ов скорость обработки важна меньше, так как мы избегаем их создания. В конвейере GitLabCI шаг линтера и форматера составляет доли процента времени работы CI/CD‑сервера.

• Ruff изначально выводит отчет в формате JSON (по состоянию на январь 2025). Разработали скрипт, генерирующий HTML — отчет, который прикрепляется к pipeline

• Инструмент активно развивается: регулярные релизы, широкое комьюнити.

Healthcheck сервисов перед запуском автотестов

Каждый наш E2E-автотест промаркирован списком микросервисов, задействованных в его выполнении. На основании этого списка перед запуском теста проверялось, что все pod’ы с соответствующими микросервисами в кластере Kubernetes находятся в статусе Running. Если проверка проходила успешно — тест запускался. В противном случае он помечался как skipped с указанием причины.

Однако на практике такой проверки часто было недостаточно. Проблемы возникали в следующих кейсах:

• Отсутствие livenessProbe. Не все pod’ы имеют livenessProbe, поэтому при сбоях контейнер не перезапускается, хотя сервис недоступен. При этом pod визуально продолжает числиться в статусе Running.

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

• Сервис поднят в Kubernetes, но недоступен через ingress.

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

Цель — перед запуском любого автотеста выполнять HTTP-запросы ко всем микросервисам, задействованным в этом тесте, и на основе ответа убедиться, что сервис действительно готов принимать и обрабатывать входящие запросы.

При этом мы стремились, чтобы эти запросы были:

• Стандартизированными (меняется только имя сервиса)

• Минимально нагружающими сеть

• Легко обрабатываемыми самим сервисом

• Осуществлялись через ingress

В большинстве микросервисов уже существовал метод /health (его название могло варьироваться в зависимости от внутренних практик), возвращающий статус «UP» при готовности и «DOWN» в противном случае.

Были выполнены следующие шаги:

• Проверили наличие health‑эндпоинтов у всех микросервисов, задействованных в E2E‑тестах

• Для отсутствующих — создали задачи в Jira на доработку

• Обновили модели и адаптеры более чем в 250 модулях

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

Результаты внедрения:

• Анализ ночных прогонов упростился: если сервис не готов, тест пропускается, а не падает с ошибкой

• Получение полного отчета о тестировании происходит быстрее

• В течение первого месяца эксплуатации были зарегистрированы артефакты в Jira по недоступным сервисам — и оперативно устранены

Эмуляция почтового сервера во время автотестирования

Для снижения нагрузки на основной почтовый сервер мы развернули мок-версию SMTP-сервера MailHog внутри тестового кластера Kubernetes. Теперь все приложения, запущенные в тестовом окружении, отправляют почтовые уведомления через MailHog.

Инструмент обладает удобным веб-интерфейсом для просмотра содержимого почтового ящика и предоставляет API для работы с письмами (получение списка, удаление, получение содержимого по ID).

Как обычно, был разработан Python-модуль для работы с API MailHog — это позволяет удобно использовать его в автотестах, проверяя нужные атрибуты писем: заголовок, тело и прочее.

Ограничения инструмента

MailHog не поддерживает SMTP-авторизацию и TLS/SSL — шифрование. Однако в нашем случае это не является проблемой, поскольку сервер развернут внутри тестового кластера и доступен только изнутри.

Мокирование сервисов

Зачем нужны моки в E2E-тестах?
В тестовом контуре не всегда возможно оперативно развернуть новую систему или ее компоненты: настройка CI/CD может занять значительное время. Если тест — аналитику нужно начать работу с системой, которая еще отсутствует на стенде, мы действуем по следующему сценарию:

1. Создаем задачу в Jira для DevOps

2. Параллельно разворачиваеммок — систему, настраиваем маппинг ответов

   • Проверяем сценарии на UAT — полигоне, где работают реальные интеграции

   • Переносим настройки на тестовый полигон и готовим окружение к автоматизации

Почему был выбран Wiremock?

• Open Source и бесплатен

• Поддерживает управление через UI и REST API

• Легко запускается: достаточно передать аргументы в jar-файл

Что было реализовано:

• Helm‑чарт для деплоя WireMock в Kubernetes

• Библиотека для работы с API WireMock, позволяющая:

  • Получать/удалять запросы

  • Создавать/обновлять/удалять маппинги

  • Получать список всех маппингов

  • Полностью очищать мок‑сервер от данных

Разработка веб-приложения для тестирования новых инструментов фондового рынка

В предыдущей статье были описаны веб-сервисы, разработанные для автотестирования. Эти наработки и технические решения легли в основу проекта для Операционного департамента фондового рынка (ОД ФР).

Задача
Автоматизировать тестирование новых инструментов фондового рынка (ценные бумаги — акции, облигации), готовящихся к торгам на следующий день.

Текущий процесс (до автоматизации)

• Подготовка тестового контура (за нее отвечает команда сопровождения ФР)

• Ручное тестирование, выполняемое маклерами ОД ФР:

• Анализ параметров бумаг в таблице

• Подача заявок и заключение сделок через торговый терминал

• Проверка позитивных и негативных сценариев

• В случае выявления ошибок — корректировка описания и повторное тестирование

Решение

Команда E2E-автотестирования разработала веб-сервис FondTest, автоматизирующий второй этап — тестирование инструментов.

Преимущества решения

• Сокращение времени тестирования с ~20 минутдо 7 — 10 минут на бумагу

• Снижение операционного риска, связанного с ручным вводом

Алгоритм работы FondTest:

• Копия базы выкладывается на тестовый сервер

• Торговая система запускается в режиме «следующий торговый день»

• Маклер проходит аутентификацию в сервисе FondTest

• Выбирает необходимые инструменты для тестирования (см. Рисунок 3. «Список инструментов, готовых к описанию „на завтра“»).

• При необходимости редактирует шаблон по режиму, если изменились данные (см. Рисунок 4. «Список шаблонов» и Рисунок 5. «Форма шаблона»), а также может:

  • создавать новый шаблон с помощью формы‑генератора

  • изменять/удалять шаблоны

  • импортировать/экспортировать шаблоны

• Запускает автотесты по выбранному списку инструментов (см. Рисунок 6. «Список тест‑кейсов» и Рисунок 7. «Запуск автотестов из сервиса»)

• Получает результаты прямо в интерфейсе сервиса (см. Рисунок 8. «Отчет о тестировании»)

• Принимает решение об утверждении описания для боевой базы

Технологическая реализация

Frontend:

• Bootstrap UI (фреймворк с готовыми компонентами на JavaScript и CSS)

Backend:

• Python 3.11

• Flask (веб‑фреймворк)

• Blueprint (организация API‑маршрутов)

• Gunicorn (WSGI‑сервер)

• MongoDB (для хранения шаблонов)

• PostgreSQL (для хранения данных пользователей)

• Alembic (система миграций для PostgreSQL)

• Memcached (система кеширования)

• Биржевой модуль на Python для взаимодействия с торговой системой

Схема работы

Результаты
Разработка FondTest завершена. Решение используется ОД ФР уже несколько месяцев.

Преимущества для маклеров

• Прогон всех тестов по заранее заданным режимам занимает до 10 минут (экономия ~100 минут в день на 10 инструментах)

• Удобство: достаточно нажать кнопку и переключиться на другие задачи

• Надежность: сервис устойчив к нагрузкам и показывает эффективность

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

Итоги

За два года мы выросли с внепроектной инициативы до полноценного проекта с командой из 18 человек. Немного цифр:

Руководство позитивно оценивает наше направление и результаты.

Что хотим улучшить:

• Привлечь искусственный интеллект (ИИ) для разбора ночных прогонов

• Использовать ИИ в проверке merge request’ов

• Расширить покрытие тестов в PROD

• Принимать активное участие в разработке сервисов/скриптов автоматизации для тестирования

Спасибо за внимание! Если остались вопросы или идеи для продолжения — пишите в комментариях.