Отлавливание нужных запросов с помощью таких средств как FireBug или Fiddler требует определенной сноровки. Да и в любом случае переносить их вручную в тест-план достаточно утомительно, особенно если запросов много и присутствуют POST-запросы для которых каждый параметр приходится переносить индивидуально.
К счастью JMeter предоставляет компонент HTTP(S) Test Script Recorder при помощи которого можно записать запросы, выполняемые в браузере. Этот компонент расположен в группе Non-Test Elements и добавить его можно только в WorkBench.
Script Recorder представляет из себя proxy-server, умеющий сохранять все проходящие через него запросы в указанный узел тест-плана.
В настройках Script Recorder нужно указать порт, на котором будет работать прокси (по умолчанию предлагается 8080) и выбрать узел тест-плана, в который будет сохраняться скрипт.
После этого можно запускать браузер. Его следует настроить на работу через прокси localhost на соответствующем порту.
Далее запускаем в Script Recorder запись кнопкой Start и выполняем в браузере желаемые действия. Ву-а-ля – записанные запросы появляются в JMeter.
Но в таком виде результат вряд ли Вас порадует, потому что большинство запросов браузера касаются картинок, js и css файлов и включать их в нагрузочный тест обычно нет никакой необходимости. В нашем примере я просмотрел всего две страницы на jmeter.apache.org, но получил «в нагрузку» десятки дополнительных запросов. Чтобы избавиться от нежелательных запросов, следует задать в поле URL Patterns to Exсlude Script Recorder-а фильтр(ы) для отсева нежелательных запросов в виде регулярных выражений. Хорошей стартовой точкой является фильтр предлагаемый по умолчанию, добавить его можно кнопкой Add suggested Excludes.
В некоторых случаях предлагаемый фильтр не срабатывает, например если в URL запросов присутствуют параметры (а ля https://issues.apache.org/bugzilla/skins/standard/global.css?1369299041). В этом случае дефолтный RegEx придется подкорректировать, добавив в конец (\?.*)? Кстати RegEx ожидаются python-style и должны соответствовать полному URL (включающему протокол, хост и параметры).
Но даже после этого остаются несколько ненужных запросов к доменам, посторонним для тестируемого сайта (в нашем примере это twitter). Чтобы их отсеять, нужно дополнительно добавить соответствующий RegEx фильтр и в поле URL Patterns to Include.
Теперь при следующей записи остаются только нужные запросы (последние два похожи, потому что это редирект).
Последний записанный запрос (серый) кстати использует протокол https – с ним Script Recorder также работает (в отличие от более старых версий JMeter), правда в браузере Вам придется согласиться на использование недоверенного сертификата, который автоматически создает JMeter. Чтобы заставить браузер доверять этому сертификату, а также в случаях когда JMeter не смог создать сертификат, придется обратиться к документации.
Наш записанный тест-план уже работоспособен и его можно запустить и посмотреть на результаты в View Results Tree.
Но успокаиваться ещё рановато, записанный тест-план практически всегда требует дополнительной доводки вручную. Первое что стоит сделать - удалить лишние HTTP Header Manager, которые создались для каждого запроса. Они необходимы только для Ajax запросов, которых в нашем случае нет. Можно конечно отключить запись HTTP-заголовков сняв опцию Capture HTTP Headers в рекордере но тогда для некоторых запросов возможно придется добавлять их вручную.
Также не помешает изменить имена записанных запросов на более понятные.
Кроме того рекордер помещает в поле Server Name or IP каждого записанного запроса имя хоста (сервера), что делает невозможным запуск записанного тест-плана на других серверах. Чтобы не заменять его везде вручную на имя пользовательской переменной, следует озаботиться, чтобы в перед началом записи в User Defined Variables была задана переменная со значением имени соответствующего хоста. В этом случае JMeter сам заменит при записи имя хоста на подстановку переменной.
У данной особенности есть и неприятных побочный эффект: на переменные заменяется всё что совпадает с их значениями. Например если у Вас есть переменная USER_COUNT со значением 1 то в сгенерированных самим же JMeter именах элементов все цифры 1 заменяться на ${USER_COUNT}. Так что на время записи возможно придется задизейблить основной User Defined Variables и вместо него временно создать упрощенный, чтобы избежать нежелательных эффектов.
Возможны и более сложные проблемы, требующие ручного вмешательства в записанный тест-план, например когда некоторые из записанных значений параметров запросов оказываются "одноразовыми" и при попытке воспроизведения запрос не проходит. Обычно такое случается с параметрами, обеспечивающими безопасность (security tokens), но это уже тема для отдельного разговора.
Результирующий тест-план к данной статье можно скачать здесь.
Существуют конечно же и альтернативные методы записи. Наиболее упоминаемым является BadBoy, который умеет сохранять захваченные запросы в формат JMeter.
К счастью JMeter предоставляет компонент HTTP(S) Test Script Recorder при помощи которого можно записать запросы, выполняемые в браузере. Этот компонент расположен в группе Non-Test Elements и добавить его можно только в WorkBench.
В настройках Script Recorder нужно указать порт, на котором будет работать прокси (по умолчанию предлагается 8080) и выбрать узел тест-плана, в который будет сохраняться скрипт.
Далее запускаем в Script Recorder запись кнопкой Start и выполняем в браузере желаемые действия. Ву-а-ля – записанные запросы появляются в JMeter.
В некоторых случаях предлагаемый фильтр не срабатывает, например если в URL запросов присутствуют параметры (а ля https://issues.apache.org/bugzilla/skins/standard/global.css?1369299041). В этом случае дефолтный RegEx придется подкорректировать, добавив в конец (\?.*)? Кстати RegEx ожидаются python-style и должны соответствовать полному URL (включающему протокол, хост и параметры).
Но даже после этого остаются несколько ненужных запросов к доменам, посторонним для тестируемого сайта (в нашем примере это twitter). Чтобы их отсеять, нужно дополнительно добавить соответствующий RegEx фильтр и в поле URL Patterns to Include.
Теперь при следующей записи остаются только нужные запросы (последние два похожи, потому что это редирект).
Наш записанный тест-план уже работоспособен и его можно запустить и посмотреть на результаты в View Results Tree.
Также не помешает изменить имена записанных запросов на более понятные.
Кроме того рекордер помещает в поле Server Name or IP каждого записанного запроса имя хоста (сервера), что делает невозможным запуск записанного тест-плана на других серверах. Чтобы не заменять его везде вручную на имя пользовательской переменной, следует озаботиться, чтобы в перед началом записи в User Defined Variables была задана переменная со значением имени соответствующего хоста. В этом случае JMeter сам заменит при записи имя хоста на подстановку переменной.
У данной особенности есть и неприятных побочный эффект: на переменные заменяется всё что совпадает с их значениями. Например если у Вас есть переменная USER_COUNT со значением 1 то в сгенерированных самим же JMeter именах элементов все цифры 1 заменяться на ${USER_COUNT}. Так что на время записи возможно придется задизейблить основной User Defined Variables и вместо него временно создать упрощенный, чтобы избежать нежелательных эффектов.
Возможны и более сложные проблемы, требующие ручного вмешательства в записанный тест-план, например когда некоторые из записанных значений параметров запросов оказываются "одноразовыми" и при попытке воспроизведения запрос не проходит. Обычно такое случается с параметрами, обеспечивающими безопасность (security tokens), но это уже тема для отдельного разговора.
Результирующий тест-план к данной статье можно скачать здесь.
Существуют конечно же и альтернативные методы записи. Наиболее упоминаемым является BadBoy, который умеет сохранять захваченные запросы в формат JMeter.
