Всем привет! На связи команда тестирования производительности структурного подразделения «Тестирование». Сегодня расскажем, как нам удалось автоматизировать рутинный процесс запуска регрессионных нагрузочных тестов и обработки результатов и передать эту активность продуктовым командам с помощью Telegram-бота.

Описание решаемой проблемы

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

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

Изначально процесс запуска регрессионного НТ был полностью ручным и выглядел так:

• Инженер по производительности вручную запускал скрипты в JMeter
• Собирал результаты
• Вручную формировал сравнительный отчет
• Передавал результаты в продуктовую команду

При росте количества продуктов небольшая команда инженеров стала узким местом. Возникла потребность автоматизировать этот процесс, чтобы:

• Освободить инженеров от рутины
• Ускорить получение обратной связи о производительности
• Децентрализовать процесс, позволив продуктовым командам запускать тесты самостоятельно

Выбор решения

Мы рассмотрели классический вариант интеграции запуска нагрузочных тестов в пайплайн CI/CD в GitLab. Однако он не подошел по двум причинам:

1. Отсутствие динамически разворачиваемого окружения, по мощности сопоставимого с продакшеном.
2. Необходимость согласования времени запуска тестов на UAT-контуре, где у нас запускаются нагрузочные тесты.

Было принято решение реализовать решение с «кнопочным» запуском. В качестве интерфейса для запусков выбран Telegram — так как это основное средство коммуникации продуктовых команд, что обеспечивало прозрачность и простоту использования.

Архитектура решения

Решение было разбито на два ключевых модуля, взаимодействующих через REST API:

1. Интерфейс (Frontend): Telegram-бот, реализованный на Python с использованием библиотеки Telebot и набора прикладных библиотек, отвечает за:

• Обработку команд от пользователей
• Доступность сценариев в зависимости от чата продукта
• Ограничение на параллельный запуск одного сценария
• Журналирование запусков

2. Серверная часть (Backend): REST API сервис на Java использующий библиотеку mockserver и набор прикладных библиотек, отвечающий за:

• Запуск тестовых сценариев
• Сбор и сравнение результатов с эталонными значениями из БД PostgreSQL
• Формирование отчетов, полных csv файлов с результатами, создание тикетов в Jira с результирующей информацией

На уровне самих нагрузочных скриптов в сценарии были добавлены SetUp и TearDown Thread Groups, которые через REST API уведомляют бэкенд о начале и окончании теста и вызывают технические методы серверной части решения.

Процесс использования

Мы сознательно отказались от полноценной интеграции в CI/CD на данном этапе. Наше решение предлагает несколько преимуществ для конкретной задачи:

• Скорость внедрения: Решение было реализовано силами небольшой команды на знакомом стэке технологий
• Прозрачность и доступность: Запуск тестов происходит в том же чате, где общается команда, что повышает осведомленность всех участников
• Гибкость: Позволяет легко управлять доступными сценариями и конфигурациями через БД и настройки бота

Заключение и результаты внедрения

Внедрение «бота-нагрузочника» позволило нам успешно решить первоначальную задачу:

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

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

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