«Бот — нагрузочник»: как мы используем ассистента тестирования производительности при регрессионных тестах
Привет, Хабр! На связи Денис Киров, руководитель отдела тестирования компании «ДОМ.РФ Технологии». В этой статье я расскажу про то, как мы используем телеграмм-бота как ассистента тестирования производительности при запуске регрессионных нагрузочных тестов.
Мы проводим различные виды тестирования производительности, такие как:
· нагрузочное тестирование;
· стресс-тестирование;
· тестирование стабильности;
· тестирование на отказ и восстановление.
Наиболее частые задачи, с которыми к нам приходят — это задачи нагрузочного тестирования (НТ) с разным уровнем декомпозиции и проработки. В общем виде flow нагрузочного тестирования в разрезе продукта у нас выглядит так:
В случае, если полученные результаты удовлетворяют требованиям и оптимизации производительности не планируются, они становятся «эталонными». Так формируется регрессионная модель запуска нагрузочных тестов, а инициация и процесс проведения регрессионного НТ выглядит следующим образом:
В случае, если что-то пошло не так и выявлена деградация производительности, каждую следующую итерацию проверки процесс идёт по данному циклу. Это значит, что инженер нагрузочного тестирования может взять на себя эту задачу и повторять одни и те же рутинные операции. Команда инженеров тестирования производительности у нас небольшая, а продуктов, которые необходимо тестировать на производительность, становилось всё больше, поэтому было принято решение оптимизировать процесс регрессионного нагрузочного тестирования.
Поиск решения по оптимизации процесса проведения регрессионного НТ
Первым делом мы стали думать, каким должен быть целевой процесс проведения НТ. Получился такой путь.
Сразу отмечу, что мы не рассматривали внедрение процесса НТ в pipeline CI/CD продукта в Gitlab, так как сейчас нет возможности динамически создавать окружение, аналогичное по мощностям промышленному контуру, на котором можно запустить нагрузочные тесты. Прогон производится на препрод-контуре UAT, на котором функционирует стабильная версия приложения с обезличенной базой данных, эквивалентной по объему продакшн-версии. Старт нагрузочных тестов необходимо согласовывать, поэтому на текущий момент наш путь — запуск руками по кнопке. Автоматизацию запусков мы отложили до следующего этапа оптимизации и начали искать наиболее удобное и простое решение для пользователей.
Мы рассмотрели варианты с запуском через gitlab или jenkins, но склонились в сторону интерфейса мессенджера телеграмм, так как там находятся продуктовые чаты, где есть все члены команды, в том числе менеджер проекта, и посчитали, что было бы удобно сделать процесс запуска и получения результатов максимально прозрачным. Далее мы приступили к реализации идеи.
Проектирование и реализация
Задача, которую нам необходимо было решить, — научить кнопочного телеграмм-бота запускать нужные сценарии нагрузочных тестов, а также выполнить ряд вытекающих задач, например, сделать так, чтобы из продуктового чата можно было запустить только сценарии, относящиеся к продукту, как формировать сравнительный отчёт и отдавать его пользователям и т.д.
Мы разбили решение на два модуля:
1) Интерфейс (телеграмм-бот), который по сути является фронтовой частью решения;
2) REST API для запуска нужных сценариев, формирования отчетов, что является бэковой частью решения.
Получился следующий пользовательский путь:
Весь процесс пользователь проходит в рамках взаимодействия с ботом в чате. А «под капотом» получилась следующая схема решения:
1) Пользовательский интерфейс (телеграмм-бот) реализован на стандартном стэке на Python:
· Взаимодействие с ботом реализовано через библиотеку «Telebot»;
· Для отправки REST API запросов в бэковую часть решения используется библиотека «Requests»;
· Получение данных из СУБД PostgreSQL реализовано через библиотеку «Psycorg2»
· Сохранение сформированного отчета в «Jira» происходит через библиотеку «JiraClient».
2) REST API реализован на Java с использованием библиотек:
· Mockserver — для обработки API запросов (использовать Spring Boot в рамках данной задачи было бы излишне)
· JDBC — для взаимодействия с СУБД PostgreSQL
· influxdb-java — для взаимодействия с influxdb
· OkHttp — для отправки REST API запросов.
3) Jmeter использует стандартный backend listener для отправки результатов в influxdb, а «технические» вызовы API (из пункта 2) происходят в setUp и TearDown группах.
Пример использования
Первое, что необходимо было сделать, — подготовить сам нагрузочный скрипт и добавить в SetUP Thread Group и TearDown Thread Group необходимые вызовы нашего API, которые будут выполняться до запуска основного сценария и после, соответственно.
Далее в БД Postgres заносим зафиксированное значение эталонов на том профиле нагрузки, который будет запускаться для сравнения с полученными значениями в отчёте.
На уровне бота конфигурируем, в каком чате запуск каких сценариев будет доступен.
Всё готово к запускам, нажимаем команду /start, далее выбираем /startPerfTest, после чего выбираем доступный для запуска сценарий. Далее приходит отбивка, что нагрузочный тест запущен, дата/время запуска.
После завершения выполнения тестов приходит сообщение со сравнительным отчётом, где отражены улучшения и деградации производительности каждого из тестируемых методов.
При вызове /createReportJira — результаты сохраняются в тикет.
В Jira в тикете сохраняется вся информация.
Также в отчёте формируются ссылки на нужные дашборды в Grafana с детальными результатами проведённых тестов (Результаты запуска) и метрики (Утилизация ресурсов на уровне k8s) с автоматически подставляемым временным диапазоном.
Заключение
Получился необычный и удобный инструмент для запуска регрессионных нагрузочных тестов и получения сравнительного отчёта, наши продуктовые команды начали им пользоваться. Проблема дополнительной нагрузки на инженеров тестирования производительности была решена, и процесс регрессионного нагрузочного тестирование ушёл в продуктовые команды. Также повысился уровень понимания того, как работают нагрузочные тесты у функциональных тестировщиков, они стали изучать, что такое они запускают и как это работает, в ближайшем будущем в планах научить этих специалистов самих актуализировать регрессионные НТ. Спасибо за прочтение, надеюсь, было интересно)
