Всем привет! Меня зовут Ольга Султанова, я главный инженер по тестированию в QA-отделе REG.RU. В статье я расскажу о том, как силами отдела мы сделали свой мониторинг страниц на основе Jmeter.
Зачем и как
Однажды нашему отделу понадобился (или мы просто захотели) инструмент для постоянного измерения скорости загрузки страниц, с помощью которого можно узнавать о проблемах на сайте в режиме реального времени. Мониторить нужно было не весь сайт, а только отдельные страницы из списка критично важных для бизнеса. Попросили менеджеров собрать такой список и дополнительно достали перечень самых посещаемых страниц ― получилось примерно 50 урлов.
В поисках инструмента мониторинга мы рассматривали варианты, которые уже используются в других командах, но ни один из них не подошёл. По крайней мере, нам так показалось. Причин много, но главная заключалась в том, что большинство инструментов собирают статистику, но не оповещают о проблемах в реальном времени. Плюс хотелось меньше зависеть от других команд, знать, что находится под капотом используемой системы, и доверять ей. Поэтому мы решили сделать свой сервис на базе Jmeter.
Почему Jmeter? Да только потому, что было больше опыта использования. Я проходила курс нагрузочного тестирования на нем и перенесла полученные знания в курс во внутренней Wiki, чтобы любой желающий мог на проверенных материалах быстро научиться пользоваться инструментом.
Над задачей работали в техническом чаптере (группа специалистов одного направления работы со сходными хард скиллами) отдела тестирования. Работу разделили на две части:
Запуск мониторинга, которым занимались в рабочее время и закончили довольно быстро.
Написание сервиса для сбора и отображения статистики, которым мы занимались во внерабочее время. Нас набралось всего двое: коллега занимался фронтовой частью, а я ― бэком и получением данных из джиметра. На этом этапе мы неплохо прокачали скиллы, не особо связанные с тестированием.
Реализация
Мы добавили в сервис синхронизацию с MySQL. Для подключения к базе использовали JDBC Connection Configuration, а для отправки данных JDBC PostProcessor с запросом INSERT. В базу передавали текущее время, урл страницы, время загрузки и код ответа.
Нам было нужно не время ответа, а полное время загрузки страницы вместе со всеми элементами. Поэтому запросы в сценарий мы добавляли через плагин Webdriver Sampler, где обозначили элемент, который будет показывать, что страница полностью загрузилась:
Для запуска сценария использовали Chromedriver Config. Чтобы не влиять на реальную скорость работы сайта, сценарий сделали без нагрузки. Для этого запросы отправляет только 1 юзер. Данные, полученные в результате запуска сценария, отправляются в БД. Вся сборка проходит примерно за 4 минуты, а запускаются каждые 10 минут по расписанию. Итого каждый запрос отправляется 6 раз в час, 144 раза в сутки. Для запуска используется GitLab CI Schedules.
Чтобы сделать выборку из базы по последним результатам, написали js-скрипт. При появлении запросов, код ответа которых не 200 или время загрузки больше 10 секунд, отправляется алерт в дискорд-канал:
Так мы можем максимально оперативно реагировать на проблемы на сайте.
Чтобы понимать, какие страницы отвечают медленнее других и требуют доработки, алертов было недостаточно и нам нужна была статистика. Для этого мы сделали веб-интерфейс (flask + vue), который рисует графики на основе данных из БД.
На основе данных из БД формируются 3 основные таблицы:
топ медленных запросов:
среднее время ответа за неделю:
таблица с ошибками:
В таблице есть данные за последнюю неделю и сортировка по столбцам. По ссылкам можно найти детальные отчёты по странице в виде графика, где можно выбрать промежуток времени:
Так как в мониторинг включены только избранные страницы, мы добавили возможность добавления новых. На отдельной странице можно оставить заявку на добавление урла в мониторинг и увидеть список всех отслеживаемых страниц:
Заявки на добавление отправляются в дискорд QA-отдела.
Вывод
Сервису уже два года. Время от времени мы актуализируем страницы, выпиливаем старые, добавляем новые. Статистику почти не смотрим, но оповещения о проблемах в дискорде очень выручают. Теперь мы отправляем их в общий канал для всей компании, а не только на отдел тестирования. При любых проблемах с доступностью сайта или определенных его страниц мы сразу в курсе и можем оперативно отреагировать, не дожидаясь пока проблему обнаружат клиенты.
Если честно, мы ожидали большего внимания к нашему сервису от других отделов. За время его жизни было всего два запроса на добавление урлов: от админов (большой список в основном технических урлов) и мастеров (нужно было поставить на мониторинг страницу подбора доменов).
Помимо своей полезности по функциональности, проект оказался еще и развивающим за счет работы с кучей различных инструментов: Jmeter, SQL, GitLab CI, Docker, Flask, Vue. Работа над таким Pet-проектом позволила тестировщикам немножко погрузиться в работу фронтендеров, бэкендеров, девопсов и в целом подтянуть свои скиллы. За время разработки мы пару раз обращались за консультацией к DevOPS-инженерам, но в целом хватило своих сил и помощи Гугла.
А еще мы на практике убедились, что тестировать свой функционал ― совсем не то же самое, что тестировать код, написанный кем-то другим. Когда сам пишешь код, кажется, что удалось предусмотреть абсолютно всё. Но это ощущение проходит, когда коллега тестировщик возвращается с немалым количеством багов.