polarnik Nov 20 2016 at 03:26

Однажды встретились JMeter и незнакомка…

12 min

23K

High performance*IT systems testing*Web services testing*

+17

Comments 5

xdenser Nov 20 2016 at 10:58

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

polarnik Nov 20 2016 at 11:49

Пока ни разу не пользовался рекордером в JMeter. Для записи трафика применял Fiddler и переносил запросы в тест руками. Fiddler и Regular Expression Extractor справляются с динамическими контролами.

Самым сложным сайтом был Oracle Enterprise Manager. Портал от Oracle, который отображает данные по мониторингу серверов. Параметры _afrLoop, window.name, _adf.ctrl-state, javax.faces.ViewState, нужно постоянно парсить и прокидывать в следующий запрос. А наиболее сложным сайтом в проектах коллег, был, думаю, портал системы 1С, где нужно было парсить сотни параметров из JSON. Там красивым решением было использовать JSR223 Post Processor с библиотекой gson для разбора ответов, а быстрым решением было использование регулярок.

Коллеги сделали конвертор трейса из Fiddler (*.saz) в скрипт на JMeter, с автокорреляцией параметров. И конвертор HAR-файлов, получаемых из браузера, в скрипт на JMeter. И активно этим пользуются. Тоже, чтобы уменьшить количество ручной работы.

xdenser Nov 20 2016 at 14:03

Запись прямо в JMeter удобенее тем, что там все в одном и все хранится в одном файле. Делал для коллег, которым нет времени вникать в тонкости протоколов. И все равно он у них особо не прижился. Видимо не так критично пока нагрузочное тестирование. Надеюсь до следующего обострения протоколы не сильно поменяются и мои плагины еще будут работать.

polarnik Nov 20 2016 at 15:22

Видел пару раз, что сначала писали прототип, а уже потом думали о производительности. Если изначально не предусмотрена масштабируемость, то потом проект переписывают почти полностью. Двойная работа получается. Нагрузочное тестирование надо проводить. Можно без дорогих инструментов и детальных отчётов, используя самодельные утилиты, бесплатный JMeter или даже модульные тесты в несколько потоков. А банальные ошибки в настройке сервера, можно с помощью https://www.webpagetest.org/ выявить, вообще без запуска тестов.

polarnik Nov 20 2016 at 12:11

Важное замечание на счёт использования консольного приложения, если нужно выполнять аутентификацию по ключу. Этот способ удобен, если выполняется нагрузочное тестирование веб-сервиса. Когда можно легко сгенерировать прокси-класс к веб-сервису и обернуть его в консольное приложение.

А когда аутентификация по ключу выполняется для веб-сайта (госуслуги, операторы электронного документооборота), то проще для такой однотипной операции использовать библиотечку или сделать плагин.

Коллега как-то умеет запускать внутри Firefox код на JavaScript так, что браузер Firefox становится сервером, может принимать команды от JMeter и отвечать на запросы. И если в проекте надо сотню раз последовательно получить токен пользователя, выполнив аутентификацию по ключу. То он просто запускает браузер, настраивает в нём плагин для аутентификации, родной плагин для тестируемого сайта, и использует один экземпляр браузера для подключения всех виртуальных пользователей JMeter. Как он это делает не знаю. Для меня это загадка пока. Думаю, nodejs тут помогает.

Show the best of all time