В первой части Попов Андрей, Middle QA Engineer Auto-test (Утконос онлайн), рассказывал, как разработчики применяют Apache JMeter для решения стандартных задач, про его возможности из коробки. Сегодня речь пойдет о необычном применении Apache JMeter. Возможно, вы почерпнете какие-то идеи для себя.
Нестандартные задачи
Регистрация пользователей
Например, нам нужно зарегистрировать тысячу пользователей, но не просто добавить записи в БД, а пройти весь путь регистрации через API. Путем несложных манипуляций можно получить сценарий, который читает из табличного документа связку имени, почты, пароля и телефона, имитируя действия по регистрации наших пользователей:
Можно было бы написать скрипт на любом языке. Но с помощью JMeter это делается без знания языков и запускается в 100 потоков, что значительно ускоряет процесс.
Оформление заказов
Другой пример — протестировать создание заказов. Мы брали пользователей из первой таблицы, логинились ими и проверяли, есть ли у них добавленный в профиль адрес. Если его не было, то добавляли его из второй таблицы. Из третьей таблицы добавляли все возможные товары. С помощью JMeter это также можно делать в несколько потоков. Дополнительно еще записывали созданные заказы в отдельный файл для дальнейшего анализа:
При этом это можно реализовать и без таблиц, просто добавив все данные в сам тест-план JMeter. Это всего лишь один файлик, который можно передать другому тестировщику для запуска.
API-тесты
JMeter имеет достаточно гибкую настройку asserts, переменные, регулярные выражения, парсинг JSON. Поэтому вы можете писать полноценные API-тесты на нем. Покажу пример такого простого API-теста.
Для удобства переменная добавлена в корень тест-плана. Меняя ее значение, можно прогонять наш тест на тестовом контуре или на проде. Для этого создаем GET запрос по пути /posts:
Имя сервера указано в виде нашей переменной, которую объявили ранее.
К этому же запросу прикручиваем JSON Extractor:
Используя JSON Path, получаем значение ключа USER_ID и создаем переменную с соответствующим именем. В следующем запросе нашу новую переменную мы просто подставляем в путь:
Ко второму запросу тоже добавим assert, где укажем путь, используя JSON Path и ожидаемое значение:
И видим результат проверки:
JMeter показал нам не только завалившийся assert, но и дал информацию о том, что пришло на самом деле.
Таким образом, мы достаточно быстро написали простой API-тест, причем нам не нужно было прикручивать никакие репортеры, так как JMeter умеет строить дашборд. Никаких языков программирования здесь тоже знать не нужно, поэтому это может написать практически любой тестировщик.
Тем не менее в этой бочке меда есть и ложка дегтя. Расскажу, с какой проблемой мы столкнулись.
Применять нагрузочные тесты после каждого релиза, конечно, хорошо, но это влияет на работу многих внешних и внутренних сервисов, и всего продукта в целом — изменения конфигурации, обновления и даже незначительные правки в микросервисах, с которыми общается наше приложение. Чтобы идентифицировать проблемы как можно раньше и прогонять тесты как можно чаще, мы решили запускать нагрузочные тесты ежедневно в CI.
Вся CI-инфраструктура у нас поддерживается DevOps-инженерами, поэтому от нас нужны лишь Docker-образ с установленной Java, JMeter и написанный тест-план. И после настройки запуска по расписанию и публикации отчетов всё готово.
Для тех, кто использует Jenkins, есть performance плагин, который позволяет точно также легко настроить Jenkins на работу с JMeter. Так как Jenkins сам умеет строить графики и, плюс еще сравнивает результаты предыдущего прогона с текущим, вам не придется настраивать публикацию отчета. Также есть сводная таблица, в которой отображены все прогоны всех билдов в текущем проекте:
Ошибки Out of Memory
Конечно, при использовании сложных сценариев и asserts потребляется достаточно много памяти, и мы столкнулись с достаточно распространенной проблемой JMeter — это ошибка в memory (нехватка памяти). Изучив официальную (и не только) документацию, мы все-таки нашли этому решение:
- Первое, что нужно сделать — это запустить JMeter с параметрами для увеличения размера кучи.
- Затем уменьшаем количество собираемых метрик за счет отключения ненужных. В принципе, это легко: в большинстве случаев мы знаем, какие данные нам нужны, а на какие мы смотреть не будем.
- Дальше изменяем опции корреляции. Есть много способов передавать значения внутри теста, и можно попробовать разные, выбрав для себя менее требовательные и оптимальные.
- Asserts добавляем только там, где они действительно необходимы. Чем их меньше, тем проще нашему JMeter.
- Также можно запускать JVM в режиме сервера с аргументом server, переключая его в серверный режим, где он оптимизирует параметры времени выполнения. JMeter будет стартовать немного медленнее, но общая производительность будет выше.
- И наконец, экспериментируем с настройками сборщика мусора.
Так нам удалось добиться стабильной работы сценария без ошибок. Но если все-таки ничего не помогает и мы все равно упираемся в мощности железа, то в этом случае у JMeter есть распределенный запуск.
Можно запускать сценарии, как видно на схеме, с одной машины, а производить обстрел будут уже подключенные хосты. Это позволяет использовать ресурсы удаленных машин для достаточно сложных и тяжелых сценариев.
На этом всё. Надеюсь, полученная информация была интересна и полезна.
27-28 июня в Москве впервые пройдет TestDriven Conf 2022 — профессиональная конференция для senior тестировщиков и QA-инженеров. Она будет посвящена всем вопросам автоматизации в тестировании и рядом. Расписание, тезисы докладов и билеты уже на сайте.
