Е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.     Тестовый полигон

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

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

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

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

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

o   базы ЭДО

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

●       Zabbix – мониторинг QA ‑ ресурсов с уведомлениями в мессенджер

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

●       Nginx ‑ кластер – SSL для тестовых сервисов

●       pg_ctlcluster – управление кластерами PostgreSQL

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

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

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

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

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

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

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

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

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

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

o   Судя по бенчмаркам улучшение в быстродействии может достигать до 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

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

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