Создание сценария jmeter

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

Введение

Как-то я начал осваивать новый инструмент — JМeter — и не смог найти какого-то полноценного руководства как руководства к действию. Постепенно, разобравшись по некоторым довольно полезным статьям и блогам, пользовательской документации, я начал что-то понимать. И решил, что, возможно, я не один ищу то, с чего можно начать работать. Освоить некоторые принципы построения и логику самого инструмента. Так что вот — статья о том, как начать.
Так что в этой статье мы рассмотрим пример создания скрипта для 3 пользователей, которые хотят:
1. залогиниться;
2. добавить в какой-нибудь альбом новую фотографию;
3. поменять аватарку.
Как таковой — это обычный бизнес процесс для какой-нибудь социальной сети.

И для этих целей будут использованы такие встроенные компоненты:

HTTP Proxy Server
Recording Controller x3
User Define Variables
CSV Data Set Config x3
Constant Timer
Uniform Random Timer
HTTP Autorization Manager
HTTP Request x6
Debug Sampler х3
HTTP Cookie Manager
Once Only Controller
Возможно, некоторые другие.

Статья большая, потому что подробная. В итоге должно получиться что-то вроде такого:

Автоматическая запись скрипта

Суть в том, что когда мы создаем скрипт для сайта, который мы тестируем методом черного ящика, мы не знаем всех тонкостей и особенностей его работы. Так, например, тот сайт, на базе которого в итоге получится мой скрипт, написан при помощи некоторого пакета Symphony2. Из-за неё отправка данных логин-пароль идет не прямо с формы на странице /login, а с некоторой несуществующей страницы /login_check. И ко всему этому отправляется еще одно пустое поле, которое для пользователя скрыто.
Обнаружить подобные подводные камни поможет HTTP Proxy Server (это, как и всё прочие, встроенный элемент). Эмулируя работу прокси сервера, он будет записывать все полученныеотправляемые запросы.

Подготовительные действия

Мы пока не будем добавлять HTTP Proxy Server в дерево теста. Обсудим, куда мы будем записывать полученные «шаги». Позже, когда мы добавим элемент в дерево, мы увидим, что есть несколько возможностей, куда именно записывать результаты. Их можно записать прямо в «катушку» (Thread), на «верстак» (Workbanch), либо в элемент «Recording Controller». Я советую воспользоваться последним способом. Во-первых, это позволит при необходимости отключить (ctrl+t) весь лог разом; во-вторых, так лучше отслеживается и формируется структура теста.
Все действия по добавлению и редактировнию происходят по нажатию правой кнопки мыши в контекстном меню. Созданные элементы можно просто перетаскивать (drag and drop).
Итак: Test Plan -> Add -> Threads ->Thread Group; Thread Group -> Add -> Logic Controller -> Recording Controller.
Настоятельно рекомендую дать сразу всем элементам понятные имена. В моём случае это будут «Картинки» и «Залогинимся», соответственно.

Записываем скрипт при помощи HTTP Proxy Server

Когда подготовительные действия завершены, добавим на «верстак» необходимый элемент: WorkBench -> Add -> Non-Test Elements -> HTTP Proxy Server.
В нем много настроек, но нас интересует пока только порт. Если порт 8080 занят, можно выставить, например, 8089. Я на своей машине использую именно этот (8089). Так же мы видим, что по умолчанию в поле Target Controller стоит «use recording controller». Т.е. записываться лог будет именно туда.
Остальные поля трогать не будем, но некоторые из них нам понадобятся, когда мы получим чуть больше информации о нашем сайте.

После того, как выставили порт, идем в настройки браузера. Я банально использую IE. Сервис — Свойства обозревателя — Подключения — кнопка Настройка сети. Ставим галки «Использовать прокси-сервер …», вторую галку снимаем. Рекомендую заглянуть в «Дополнительно» и посмотреть, что написано в «Исключения». В моей практике в процессе тестирования сайт перенесли на новый домен, который оказался в исключениях. Ушло около получаса, чтобы разобраться, почему действия моего виртуального пользователя на тестируемом сайте не записываются, а всякие ссылки на яндекс, твиттер и фэйсбук прекрасно логируются. В общем, если там неожиданно оказался домен вашего сайта, сотрите.
В поле Адрес пишем «Localhost», а порт указываем как из JMetеr’а: «8089». Без кавычек всё, разумеется.

Теперь все готово для записи. Возвращаемся в JMeter на прокси и внизу можем нажать кнопку Start. После нажатия все действия пользователя в браузере начнут записываться в созданный нами Recording Controller «Залогинимся». Записывать действия будем в несколько шагов, т.к. скрипт может оказаться чрезмерно большим и его будет сложно редактировать. Так что первое, что мы сделаем, а после отладим, это авторизация пользователя на сайте.
Итак, нажимаем Start и проходим процедуру авторизации на сервере (у вас может её не быть, а у меня есть) и процедуру авторизации на сайте. Возвращаемся в JMeter и жмем Stop. Смотрим на Recording Controller: у него куча дочерних элементов. Это то, что мы послали на сервер, а сервер ответил. Изучаем и чистим.

Отладка скрипта

Отладка скрипта представляет собой удаление различных .jpg, .png и ссылок на сторонние ресурсы. У меня в скрипте больше половины таких сторонних ресурсов — это связи с различными социалками и яндекс картой. Всё это можно вычищать (клавишей delete). В целом, также можно вычистить .js. Главное найти запрос, который передает в своем теле учетные данные вашего пользователя. Ну и для красоты найти запрос, который ведет вас на страницу, на которой пользователь логинится. Таким образом, вместе они моделируют связку в действиях пользователя «зашел на страницу — залогинился».
Предположим, что нам повезло вычленить необходимые запросы. Ну, или нам кажется, что мы их вычленили. Дадим им читаемые имена! Чтобы проверить то ли мы вычленили, скрипт надо запустить. В моем случае, если запустить скрипт, то он выполнится с ошибками. Дело в том, что мне для тестирования нужно авторизоваться на сервере. Для этого добавим в верхушку дерева HTTP Autorization Manager (Thread Group – Add – Config Elements – HTTP Autorization Manager). Он интуитивно понятен. Записываем туда адрес нашего ресурса обязательно с http://, имя пользователя и пароль.

Если Менеджер Авторизации нужен для авторизации на сервере, то абсолютно точно при авторизации на сайте используются куки. Добавляем Cookie Manager после Менеджера Авторизации (TestPlan – Add – Config Elements — HTTP Cookie Manager). Этот элемент необходимо добавлять, пожалуй, всегда, если речь идет о том, что пользователю нужно залогиниться.
Прежде чем запустить и проверить скрипт добавим элемент View Results Tree (Катушка – Add – Listener – View Results Tree), в котором можно будет наблюдать выполнение. Этот элемент удобно располагать всегда внизу. Ах да, еще нужно в настройках браузера убрать галку «использовать прокси» — он пока нам не понадобится.

Итак, можно запустить. Запускаем (ctrl + r)!
В View Results Tree видим следующее:

Кажется, нам повезло. И даже если мы не залогинились, то, по крайней мере, запросы дошли до сервера. Чтобы убедиться, что пользователь был успешно залогинен, посмотрим в дереве на ответ. Нажимаем на Response Data. В ответе сервера ищем информацию, которая свидетельствует об успешной авторизации пользователя. В моем случае это будут имя пользователя, т.к. после авторизации оно высвечивается на странице.

Скрипт по-прежнему может нуждаться в чистке. Я, например, удалил из него HTTP Header Manager’ы. И без них всё работает отлично. Чтобы убедиться в нужности каждого элемента, его не обязательно сразу удалять, достаточно этот элемент отключить (ctrl + t).
Далее мы хотим привлечь к этому делу 3 пользователей. Для этого прежде выполним небольшой учебный пример по параметризации запросов. Параметризируем одного конкретного пользователя.

Параметризация

Для параметризации запросов добавим в самый верх User Define Variables. Thread -> Config Controllers -> User Define Variables. Внизу есть кнопка Add. Нажимаем ее, вбиваем две переменные, т.к. меняться у нас будут только два параметра: логин и пароль. Дадим им хорошие имена: userName и password. А в качестве значений впишем пока конкретные значения текущего пользователя.

Чтобы их использовать переходим в запрос Логин, и вместо конкретных значений пишем имена переменных в формате ${имя переменной}. В нашем случае записываем в поля Value для логина — ${userName}, для пароля — ${password}.

Для отладки передачи параметров добавим еще один элемент – Debug Sampler. Thread –> Add -> Samplers –> Debug Sampler. Его поставим после запроса Логин. В настройках элемента оставим только JMeter variables, остальные поставим в false. Это делам для того, чтобы отловить только наши переменные. Да и всё равно других нет.

Запускаем и смотрим в View Results Tree результаты. Должны видеть, что в качестве переменных передались именно наши значения, и запросы в целом вернули то, что нужно (см. выше).

Теперь можно передать данные 3 пользователей. Для этого воспользуемся CSV Data Set Config.

CSV Data Set Config

Я предлагаю создавать .csv файл в блокноте. Для пользователей файл должен представлять собой набор из 3х строчек вида «UserName;Password». Мой файл представлен на скрине ниже:

Далее добавим в дерево элемент CSV Data Set Config (Add – Config Elements – CSV Data Set Config). Добавим его не в катушку, а в тест-план, ниже пользовательских переменных. В качестве filename для файла нужно указать полностью путь к файлу и его имя. Ниже указать кодировку (на ваш выбор). Если все данные на английском, то поле можно оставить пустым. Ниже написать переменные, которые считаются из файла. Для нас это будут UserName и Password. В качестве разделителя нужно указать точку с запятой, так как в файле используется она. Ниже, для того, кто хоть немного владеет английским, не сложно перевести имена логических переменных. Нужно поставить в false повтор файла по достижении конца, а также остановку катушки.

Далее удалим подобные переменные из User Define Variables. То, что он останется пустым, это не страшно. После этого в самой катушке количество потоков (Number of Threrads) установим на 3.
Теперь можно запустить скрипт и наблюдать в Debug Sampler и View Results Tree результаты. Не забудьте проверить, те ли данные вернул сервер, есть ли в них имена ваших пользователей.

Добавляем фотографию в альбом

Теперь, когда наши пользователи научились логиниться, приступим к следующей части нашего скрипта. Научим их заливать в какой-нибудь определенный альбом нашего сайта фотографии. Для этого опять добавим в катушку Recording Controller, назвав его «Фотографии».
Чтобы сократить полученный скрипт, заранее авторизуемся пользователем на сайте и перейдем на страницу, на которой начнется непосредственно загрузка фотографии. После этого снова включим в настройках браузера прокси и воспользуемся элементом Proxy Server на верстаке (указав другой Recording Controller). Так же в URL Patterns to Exclude укажем расширения, которые нам не нужны в формате «*..ххх».

Start, заливаем в альбом фотографии, End. Приступаем к чистке скрипта. Точно также можно для красоты оставить лишь те запросы, которые образуют связку «зашел в альбом — добавил фотографию». У меня получилось так:

На самом деле, запрос «зашел в альбом» записан был вручную. Он не представляет собой ничего сложного: это GET запрос с указанием адреса страницы.
Обратим внимание на тело запроса, который отправляет на сервер файл. Единственное, что в нем представляет для нас ценность, — это путь и имя файла. Вот их мы и параметризируем, чтобы каждый пользователь заливал какую-то свою фотографию. Начнем с пути к файлу. Как таковой для тестирования он не представляет интереса. Вполне вероятно, что все фотографии будут у вас лежать в одной папке. Но в тесте он может встречаться много раз. Так что по правилам хорошего тона запишем его в переменную. Возвратимся к User Define Variables и добавим туда переменную filePath со значением пути до папки, в которой лежат фотографии, например, «** D:jakarta-jmeter-2.5.1images**». Именно со слэшем в конце, позже ясно будет для чего.
Как всегда, протестируем сначала скрипт на одном файле. Поэтому создадим еще одну переменную fileName, в качестве значения которой будет конкретное имя файла, например, «img.jpg«.

Возвратимся в тело запроса. В разделе Send Files With the Request пишем путь уже таким образом: ${filePath}${fileName}. Если подставить в переменные указанные значения (value из user define variables), легко убедиться, что получается корректный путь. Посмотрим на параметры, которые передает запрос. Там тоже есть имя файла. Впишем вместо него ${fileName}.

Теперь, когда имитация пользователя в этой части закончена, добавим новый Debug Sampler. Подумаем на шаг вперед: если мы заставим катушку крутиться forever (пока не ставить!), то каждый пользователь будет логиниться по много-много раз, верно? Чтобы этого избежать, добавим в катушку логический элемент Only Once (Thread -> Add -> Logic Controllers -> Only Once Controller). Поместите его в соответствующее место над Recording Controller’ом, отвечающий за авторизацию пользователя на сайте, а сам контроллер перетащите в него как дочерний.

Отключите в браузере прокси. Запустите срипт. Если всё сделано правильно, то в выбранный альбом добавится новая фотография. Если что-то не так, посмотрите Debug Sampler в View Results Tree.

Параметризируем

Теперь можно сделать так, чтобы пользователи добавляли разные фотографии. Для этого создадим csv файл, в кототором будут содержаться только имена фотографий:
Img.jpg
Img1.jpg
Img2.jpg
…
Создадим CSV Data Set Config, перетащив его под другой CSV Data Set Config, укажем путь к этому файлу. В качестве переменной (variable Names) укажем fileName, а из пользовательских переменных (User Defined Variables) её удалим. Поле для разделителя оставим пустым. В этот раз повторять файл при достижении конца (Recycle on EOF) оставим на True, а останавливать катушку при достижении конца (Stop thread on EOF) — на False. Для красивой логики нашего теста перенесем фотографии в отдельную папку: » D:jakarta-jmeter-2.5.1imagesPhoto » и соответствующим образом изменим значение переменной filePath на filePath_Photo. Сделаем это и в тех местах, где переменная используется.
Запускаем тест! После чего смотрим, добавилось ли в альбом 3 фотографии (да, все пользователи должны иметь достаточно прав, на добавление фотографий в альбом). Если всё ОК, продолжаем дальше. Если нет — читаем Debug Sampler и ответы сервера.

Изменяем аватарку

На деле это ничем не отличается от предыдущего параграфа. Точно также нужно залить на сервер фотографию. Поэтому делаем все также:

создаем очередной recording controller
настраиваем прокси
делаем действия на сайте (записываем скрипт)
чистим скрипт
параметризуем для одной аватарки
отлаживаем
параметризуем для множества аватарок

В качестве имен аватарок я использовал тот же csv файл, но залил картинки в другую папку и создал новую переменную для нее: filePath_Avatars.
Если всё работает, то это хорошо. Если нет, смотрим в Debug Sampler.
Чтобы скрипт был больше похож на живого человека, нужно добавить задержки. Например, после загрузки фото на сервер, можно поставить Constant Timer на 3 секунды (3000ms), будто пользователь ждет, пока картинка загрузится на сервер. А для смены аватарки Gaussian Random Timer от 2 до 6 секунд, будко пользователь ищет и выбирает аватарку. Так же для большего правдоподобия в каждом HTTP Request можно поставить галку Retrieve All Embedded Resourced From HTML Files, означающую что со страницы будет загружаться всё возможное, как в обычном браузере.
Итак, предположим, что всё работает и всё отлично. Всё. Задача полностью выполнена. Теперь осталось нагрузить наш сайт на всю ночь. Вернемся в Thread и установим галку forever. Это значит, что скрипт будет выполняться, пока не случится событие «stop thread». В CSV Data Set Config’ах мы выставили возможность такого события в False. Значит, тест будет выполняться, пока его не остановит тестировщик руками (меню Run -> Stop). Итоговый скрин выложен в начале статьи.
Тест моделирует банальный бизнес-процесс для какой-нибудь социалки: пользователь зашел в сеть, залил в альбом фотографию, которая ему ну уж очень понравилась, со вчерашней вечерины и поменял свою аватарку на это (либо другое) фото. Поставив такой процесс на forever, мы получили 3 пользователей, которые заливают фотки и меняют на них аватарки. Процесс можно изменить, добавляя различные другие элементы. Например, заливать фотографии можно только одну, поставив Only Once, а вот менять аватарки бесконечно. Если пополнить базу до 1000 пользователей, запустить скрипт непосредственно с сервера, а также с локальных машин в офисе — это будет достаточно серьезная нагрузка на сервер приложения.
Возможно, следующая статья будет посвящена тестированию поиска и регулярным выражениям, либо оценке и интерпретации собранных данных.
Будем рады любому обмену опыта.

Источник

Просмотров: 13818
Дата последнего изменения: 23.09.2021

Сложность урока:

3 уровень — средняя сложность. Необходимо внимание и немного подумать.

Тестовый пакет Jmeter представляет собой модульную систему, он очень удобен и функционален. Документацию по работе с программой можно прочитать на сайте разработчика. Рассмотрим наиболее часто используемые элементы тест-плана Jmeter

Глобальные переменные

Использование глобальных переменных очень удобно — это позволяет управлять настройками всех цепочек централизованно.

Настройка числа нагрузочных потоков

Число потоков при создании цепочки как раз задается глобальной переменной CHAIN1_USERS, а общее время теста TOTAL_TIME.

Структура запроса в цепочке

Настройка запроса в цепочке проста — задается название цепочки, путь для запроса, метод GETPOST, редиректы, KeepALive и другие необходимые данные.

Случайная пауза

Для эмуляции реальной работы пользователя используется время паузы между хитами Constant Delay Offset и время случайной паузы (небольшое отклонение от постоянной паузы) Random Delay Maximum.

Случайная страница

Случайные страницы вносятся в цепочку для того, чтобы немного отклониться от предполагаемого пути следования посетителя по сайту. Для этого устнавливается в цепочке контрол Random Controller и в нем уже создаются варианты случайных запросов.

Очистка cookies в конце цепочки

Cookies играют важную роль, практически, на любом сайте. Они участвуют в авторизации и их использование необходимо включать в тест. Также желательно активировать опцию Clear cookies each iteration, что позволит после прохождения потока цепочки сбрасывать авторизацию.

Переменные данные из внешних файлов

Очень удобно хранить логины/пароли, поисковые фразы, ID элементов каталога в CSV-файлах, которые создаются заранее и подключаются в настройках цепочки выбором соответствующего пункта меню.

Далее задается имя файла с данными и название переменной.

Которая потом указываются при создании запроса цепочки.

Важной момент: желательно выставить опцию Recycle on EOF в значение True для того, чтобы при окончании значений переменных в файле начиналось чтение его заново и т.д.

Авторизация

Например, для задания авторизации при тестировании проектов на Bitrix Framework нужно использовать переменные:

USER_LOGIN = $(login);
USER_PASSWORD = $(password);
AUTH_FORM = Y.

и метод POST. А используя cookies-менеджер с очисткой cookies в конце цепочки, система будет проходить весь цикл: авторизация — работа пользователя в системе — выход из системы.

Таким образом, с помощью Jmeter можно создавать как простые, так и сложные сценарии нагрузочного тестирования систем.

Источник

Вступление

Запись тестовых сценариев — один из наиболее удобных способов создания тестовых сценариев. Это связано с тем, что тестовые записи позволяют воспроизводить реалистичные рабочие процессы пользователей, вместо того, чтобы вручную создавать тестовый скрипт. Записи захватывают все запросы браузера к веб-приложению, а затем автоматически создают файл jmx, который можно запускать в тестах производительности. Используя функции записи / воспроизведения JMeter или сторонние инструменты, такие как BlazeMeter и BadBoy, тестеры могут сделать свою работу в 3 раза быстрее.

В версии 2.10 JMeter представил механизм, который экономит ваше время при создании скриптов — шаблонов JMeter. Эти шаблоны являются скелетами, которые можно использовать повторно в качестве базы для новых сценариев.

JMeter уже имеет несколько доступных шаблонов с подробными описаниями, и вы также можете добавить свой собственный. Шаблоны имеют всю необходимую конфигурацию и элементы для записи сценариев производительности с нуля.

Вот как использовать шаблон шаблона JMeter:

Настроить JMeter

Открыть JMeter
Выберите шаблон для записи сценария:
Файл -> Шаблоны … -> Выбрать шаблон -> Запись -> Создать JMeter добавит соответствующие элементы в тестовое дерево.

Настройте свой прокси-сервер

Чтобы использовать JMeter Recorder, вам необходимо настроить браузер для отправки всех запросов через прокси. Любой браузер может быть использован для этих нужд, хотя могут быть различия между местоположениями конфигураций браузеров, которые зависят от браузера и могут варьироваться в зависимости от ОС.

Чтобы настроить браузер:

Chrome : кнопка меню -> Настройки -> Показать дополнительные настройки … -> Сеть -> Изменить настройки прокси-сервера

Safari : Настройки -> Дополнительно -> Прокси -> Изменить настройки …

Firefox : Кнопка меню -> Настройки -> Дополнительно -> Сеть -> Соединение -> Настройки ..
Например, вы можете использовать localhost 127.0.0.1. Измените порт на порт в HTTP (S) Script Recorder.

Если у вас возникли проблемы при завершении этого этапа, убедитесь, что у вас нет сторонних плагинов, которые могут управлять настройками прокси-сервера вашего браузера. Если вы это сделаете, например, Hola VPN, настройки прокси-сервера будут недоступны в меню вашего браузера.

Нажмите кнопку «Пуск», которая находится внизу страницы «Тестер сценариев тестирования HTTP (S)», и просмотрите рабочий процесс веб-приложения, который вы хотите протестировать. Когда вы вернетесь в JMeter, вы увидите все захваченные запросы из своего браузера.

Запись сценария с помощью прокси-рекордера JMeter

JMeter также позволяет вам вручную настраивать рабочее пространство. Это сложнее, но вы можете сделать скрипты подходящими для ваших конкретных потребностей.

Настройте свой прокси-сервер

Настройте свой браузер, как описано в главе 1.

Настроить JMeter

Развертка «WorkBench» может использоваться как временное рабочее пространство для создания сценариев. Имейте в виду, что записи, добавленные в этот раздел, не будут сохранены в плане тестирования. Поэтому, если вы хотите повторно использовать одну и ту же конфигурацию записи в будущем, вам нужно будет скопировать и вставить ее в раздел «План тестирования».

Добавьте «Recording Controller» в «WorkBench»: щелкните правой кнопкой мыши на «WorkBench» -> «Добавить» -> «Logic Controller» -> «Recording Controller» —

Добавьте «тестовый скрипт сценария HTTP (S)» в тот же «WorkBench»: щелкните правой кнопкой мыши на «WorkBench» -> «Добавить» -> «Не тестируемые элементы» -> «HTTP (S) Test Script Recorder»

На странице конфигурации «HTTP (S) Test Script Recorder» в «Global Settings: Port» вам нужно поместить тот же порт, который указан в настройке прокси-сервера вашего браузера, например 8080.
Если вы хотите исключить запросы к определенным ресурсам, вы можете использовать раздел «Шаблоны URL для исключения». Это может быть полезно, если вы хотите включить только те типы контента, которые хотите запросить (например, * .html, * .php и т. Д.) Или исключить типы контента, который вы не хотите запрашивать (например, * .jpg, * .png, * .js и т. д.).

Когда мы будем использовать это? Например, при записи сценария, вызывающего стороннее приложение или при тестировании сценария на стороне сервера, вы можете не захотеть загружать активы, поскольку они могут загромождать ваши тесты и потреблять полосу пропускания, или вы можете записать определенные запросы от определенный путь.

Наиболее распространенные шаблоны исключений: «. .png «,». .jpg «,». .gif «,». .css «,». .js». Вы также можете комбинировать разные модели вместе. Этот комбинированный шаблон должен избавиться от всех избыточных запросов, которые могут отвлечь вас от важных: «. . (ВМР | CSS | JS | GIF | ICO | JPE г |? PNG | SWF | Уофф)»

С другой стороны, вы можете подражать полному поведению браузера и включать загрузку всех ресурсов. В этом случае нет необходимости исключать шаблоны URL. Имейте в виду, что браузер загружает все внедренные ресурсы с запрашиваемой страницы и имеет механизм кэширования, который может повлиять на производительность результатов.

В этом случае рекомендуется загрузить все встроенные ресурсы в скрипт: Щелкните правой кнопкой мыши «План тестирования» -> «Добавить» -> «Элемент конфигурации» -> «Настройки HTTP-запроса» -> «Дополнительно» -> выберите Установите флажок «Получить все встроенные ресурсы».

Чтобы сделать JMeter более похожим на реальный браузер, рекомендуется добавить «HTTP Cache Manager», который позволяет имитировать функциональность кеширования браузера в ваших тестах производительности. Щелкните правой кнопкой мыши «План тестирования» -> «Добавить» -> «Элемент конфигурации» -> «HTTP Cache Manager».
Теперь нажмите кнопку «Пуск», которая находится в нижней части страницы «Протокол сценариев тестирования HTTP (S)», и просмотрите рабочий процесс веб-приложения, который вы хотите протестировать. Когда вы вернетесь в JMeter, вы должны увидеть все захваченные запросы из своего браузера под «Recording Controller».

Запись сценариев производительности для мобильных устройств

JMeter также может использоваться для регистрации тестирования производительности мобильных устройств. Запись мобильных сценариев очень похожа на запись сценариев веб-приложений.

Настроить JMeter

Настройте «Шаблоны JMeter», как указано в главе 1.

Настройте свой мобильный телефон

После того, как будет подготовлена конфигурация JMeter, в том числе элемент записи JMeter «HTTP (S) Test Script Recording» на указанном порту, вы можете настроить свой мобильный телефон на отправку запроса на веб-приложение, которое вы тестируете через прокси-сервер JMeter.

IOS :

Настройка -> Wi-Fi
Нажмите на подключенную сеть
Перейдите в раздел конфигурации HTTP PROXY
Перейдите на вкладку «Руководство»
Задайте IP-адрес компьютера. Приложение JMeter запущено в разделе «Сервер».
Установите порт, указанный в «Запись тестового сценария HTTP (S)» в разделе «Порт»

Android:
Настройка -> Wi-Fi
Длинный клик по подключенной сети и нажмите кнопку «Изменить сеть»
Установите флажок «Дополнительные параметры»
Установите для параметра «Прокси» значение «Вручную»
Установите «Имя хоста прокси» в качестве IP-адреса вашего компьютера и «Прокси-порт», как указано в конфигурации «Проверка тестового сценария HTTP (S)» в разделе «Порт»,
Нажмите «Сохранить».

Теперь вы можете запустить приложение на своем мобильном устройстве. Запросы будут записаны на JMeter.

Запись трафика HTTPS

Если ваше веб-приложение использует SSL-шифрование, вам нужно захватить HTTPS-трафик вместо HTTP. Для записи трафика HTTPS с помощью JMeter вам необходимо настроить SSL-сертификаты.

Настройте свой SSL-прокси

Убедитесь, что прокси-сервер SSL настроен так же, как настроен HTTP-прокси:

Настроить JMeter

Запустите запись сценария, используя функцию «JMeter Recording Template», как описано в примере «Запись сценария с помощью функции шаблона JMeter».
После открытия веб-приложения вы увидите сообщение о незащищенном соединении. Чтобы продолжить, вам просто нужно принять сертификат Jummer dummy:

Нажмите «Дополнительно»
Нажмите «Добавить исключение …».
Снимите флажок «Постоянное сохранение этого исключения»
Нажмите «Подтвердить исключение безопасности».

Если вы видите «Этот сайт содержит действительную, подтвержденную идентификацию. Не нужно добавлять исключение. », Вы должны очистить историю браузера для своего приложения, включая файлы cookie, кеш, данные оффлайнового веб-сайта. Затем повторите те же шаги.

Этот подход также работает для записи мобильных сценариев, поскольку сертификат JMeter необходимо установить только на хост, который используется для запуска JMeter.

Запись скриптов с расширением Chrome BlazeMeter

До сих пор мы рассмотрели основные способы записи тестовых сценариев. Но одним из самых быстрых и простых способов записи сценариев производительности, который также является бесплатным, является использование расширения BlazeMeter Recorder Chrome . Эти записи можно запустить в JMeter или в BlazeMeter.

Причина, по которой расширение является настолько полезным, заключается в том, что он позволяет записывать сценарии производительности из вашего браузера без необходимости настройки прокси-сервера.

Чтобы создать новый скрипт производительности:

Откройте рекордер из Chrome
Введите тестовое имя в верхнем поле
Начните запись, нажав на кнопку записи, в форме круга, и выполните действия, которые вы хотите записать. Все ваши запросы будут сняты. Расширение Chrome Blazemeter также поддерживает запись трафика HTTPS.
После завершения записи нажмите кнопку остановки в форме квадрата. Вы также можете приостановить запись, а затем возобновить, а также отредактировать ее, в формате .jmx или JSON или в облаке.
Экспортируйте свою запись — для запуска теста в JMeter, экспортируйте в формат .jmx, нажав кнопку .jmx. Чтобы запустить тест в BlazeMeter, нажмите «play».

Для получения дополнительной информации см. Здесь .

Запись скриптов с помощью BadBoy

Еще один полезный инструмент для записи третьей стороны — BadBoy. Однако он работает только для ОС Windows.

Чтобы создать новый скрипт производительности:

Установите BadBoy здесь
Введите тестовый URL в адресной строке
Нажмите кнопку записи, сформированную как красный круг, и выполните действия, которые вы хотите захватить.
Экспорт сценария в JMeter — Файл -> Экспорт в JMeter

Для получения дополнительной информации см. Здесь .

Использование рекордера сценариев производительности — отличный способ избежать рутинных задач и по-прежнему получать лучшие тестовые сценарии. После записи настройте тест на количество виртуальных пользователей, которые вы хотите протестировать, а также дополнительные тестовые конфигурации, запустите свой тест и проанализируйте результаты, чтобы определить ошибки и узкие места и охарактеризовать тенденции, которые показывают вам здоровье вашей системы.

Источник

1. Обзор

В этой статье мы будем использовать

Apache JMeter

для настройки и запуска тестов производительности.

2. Настройка JMeter

Давайте

https://jmeter.apache.org/download

jmeter.cgi[downdown JMeter]распакуем его, перейдем в папку

bin

и запустим исполняемый файл (

. Bat

для Windows и

. Sh__ для Linux/Unix).

Далее нам просто нужно добавить эту папку в переменную окружения path, чтобы она была доступна из командной строки.

Самая стабильная версия на момент написания этой статьи — 3.3. Мы можем проверить новейшую версию

here

3. Создание сценариев JMeter

Теперь давайте напишем наш первый скрипт JMeter (файл, содержащий техническое описание наших тестов). **

Этот API представляет собой простую ссылку:/spring-boot-start[SpringBoot]приложение, представляющее REST API.

Давайте обновим

Test plan

one и сначала изменим его имя, затем добавим

Thread Group

.

Thread Group

позволяет нам узнать пользовательский поток и моделировать, как они взаимодействуют с приложением, щелкнуть правой кнопкой мыши на имени нашего скрипта в графическом интерфейсе и следовать выбранному меню:

ссылка:/uploads/thread-group-menu-blur-1-1.png%201110w[]

Теперь мы переходим к части конфигурации

Thread Group

, где мы указываем количество пользователей, параллельно выполняющих запросы к нашему приложению:

ссылка:/uploads/create-thread-group-blur-1024×567.png%201024w[]

Здесь мы указали такие параметры, как:

— **

Name:

имя, которое мы хотим дать группе потоков
- Количество потоков (пользователей)
  
  : количество параллельных пользователей
- Время разгона: время, необходимое для перехода от 0 до заявленного количества пользователей
- Loop count
  
  : количество повторений

Добавьте

HTTP-запрос

, поскольку он будет имитироваться каждым из 5 пользователей.

Давайте заполним информацию для адресации нашего API, описанного там, как на картинке ниже:

ссылка:/uploads/http-request-blur-1024×565.png%201024w[]

Мы просто заполняем адрес сайта, порт и конкретный путь.

Далее, давайте смоделируем запросы пользователей после добавления

View Results Tree

(используйте

View Results in Table

, если результаты представляют собой список записей), следуя меню «

Add> Listener»

.

Нажмите зеленую стрелку вправо вверху для запуска теста и просмотра данных ответа:

ссылка:/uploads/http-request-view-result-blur-1024×565.png%201024w[]

Мы можем увидеть более подробное представление ответа на вкладке

Sampler result

.

Давайте закончим, добавив подтверждение длительности в HTTP-запрос, поэтому каждый запрос, который длится более десяти миллисекунд, будет считаться неудачным тестом:

ссылка:/uploads/duration-assertion-blur-1024×567.png%201024w[]

После повторного выполнения теста мы видим, что есть некоторые (здесь их 3) пользователи, которые не могут получить списки студентов менее чем за десять миллисекунд:

ссылка:/uploads/duration-assertion-failed-blur-1024×568.png%201024w[]

Теперь давайте сохраним тест с расширением

.jmx

в папке ресурсов API.

Для настройки нашего тестового файла доступно больше элементов:

http://jmeter.apache.org/usermanual/component

reference.html#JDBC

Request[JDBC

Издатель]: публиковать сообщения для определенной цели (темы/очереди) в соответствии со спецификацией J2EE для обмена сообщениями

Все доступные компоненты подробно описаны в руководстве

user

4. Запустите тесты JMeter

Существует два способа запуска тестов JMeter, один из которых состоит из использования доступного плагина Maven, а другой — автономного приложения JMeter в режиме без графического интерфейса пользователя.

В любом случае, оба должны знать, где найти сценарий JMeter, который мы настроили ранее.

4.1. Плагин JMeter Maven

http://jmeter.lazerycode.com/

— это плагин Maven, который позволяет запускать тесты JMeter как часть нашей сборки; его последняя версия прямо сейчас

is 2.6.0

, который совместим с Apache JMeter 3.3.

Давайте добавим его в

pom.xml

нашего проекта:

<plugin>
    <groupId>com.lazerycode.jmeter</groupId>
    <artifactId>jmeter-maven-plugin</artifactId>
    <version>2.6.0</version>
    <executions>
        <execution>
            <id>jmeter-tests</id>
            <goals>
                <goal>jmeter</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <testFilesDirectory>${project.basedir}/src/main/resources</testFilesDirectory>
        <resultsDirectory>${project.basedir}/src/main/resources</resultsDirectory>
    </configuration>
</plugin>

После этого мы можем запустить все наши тесты с помощью

mvn verify

или только JMeter с

mvn jmeter: jmeter

; Вот консольный вывод команды:

ссылка:/uploads/run-jmeter-log-1024×370.png%201024w[]

Примечание. Здесь мы указали каталог, в котором находятся наши тесты в проекте, либо будет выбран каталог по умолчанию (

$ {project.basedir}/src/test/jmeter

); аналогичным образом настраивается каталог результатов, иначе каталогом по умолчанию будет

$ {project.basedir}/target/jmeter/results

.

Полная документация по плагину доступна по адресу

here

4.2. Режим без графического интерфейса

Другой способ сделать это через исполняемый файл JMeter, предполагая, что он доступен через командную строку, мы можем сделать это:

jmeter -Jjmeter.save.saveservice.output

format = xml__

-n -t src/main/resources/JMeter.jmx -l src/main/resources/JMeter.jtl

Мы устанавливаем XML в качестве выходного формата, который заполняет точный тестовый файл и полученный файл.

Примечание: рекомендуется не использовать режим GUI для нагрузочного тестирования, только для создания теста и отладки теста

5. Заключение

В этом кратком руководстве мы настроили Apache JMeter для приложения SpringBoot, чтобы запускать тесты производительности с помощью подключаемого модуля Maven, в то же время рассматривая практически как разработать базовый тест производительности.

Как всегда, исходный код этой статьи можно найти

over на GitHub

Источник

Запись тестовых сценариев при помощи JMeter

20 февраля, 2016 12:01 пп
9 735 views
| Комментариев нет

Java

Данное руководство научит использовать рекордер тестовых скриптов Apache JMeter для записи HTTP-запросов. Это позволяет планировать тестирование и эмулировать поведение пользователей в сети.

Примечание: Данное руководство предполагает наличие базовых навыков работы с Apache JMeter. Об основных принципах работы данного инструмента можно прочесть здесь.

Требования

Предварительно установленный Apache JMeter (скачать бинарные файлы можно здесь).
Java 6+.
Mozilla Firefox (можно загрузить по этой ссылке).

При написании руководства использовались следующие версии программ:

Oracle Java 7
JMeter 2.11
Firefox 30.0

Создание теста

Для начала запустите JMeter.

Примечание: Если у вас уже есть готовый план тестирования, используйте его и пропустите данный раздел.

Создайте минимальную группу потоков, состоящую из компонентов Thread Group и HTTP Request Defaults.

Добавление группы потоков

Чтобы добавить Thread Group):

Щелкните правой кнопкой по Test Plan
Выберите Add >
Найдите и выберите Threads (Users) >
Выберите Thread Group

Установите следующие значения параметров Thread Group:

Number of Threads (users): Количество потоков (пользователей), которое будет эмулировать JMeter; установите значение 50.
Ramp-Up Period (in seconds): Продолжительность тестирования в секундах. Установите значение 10
Loop Count: Количество тестов. Установите 1.

Добавление настроек HTTP

Чтобы добавить HTTP Request Defaults для Thread Group:

Кликните правой кнопкой на Thread Group.
Нажмите Add.
Затем выберите Config Element >.
Кликните HTTP Request Defaults.

На экране появятся настройки для HTTP Request Defaults. В разделе Web Server найдите поле Server Name or IP и укажите в нём имя или IP-адрес веб-сервера, который нужно протестировать. Установленный здесь сервер становится сервером по умолчанию для остальных элементов этой группы потоков.

Добавление HTTP Cookie Manager

Если сервер использует cookie-файлы, можно настроить их поддержку при помощи элемента HTTP Cookie Manager. Чтобы добавить в Thread Group элемент HTTP Cookie Manager:

Кликните правой кнопкой на Thread Group.
Нажмите Add >.
Затем выберите Config Element >.
Кликните HTTP Cookie Manager.

Добавление компонента Recording Controller

Чтобы добавить компонент Recording Controller:

Кликните правой кнопкой на Thread Group.
Нажмите Add >.
Выберите Logic Controller >.
Кликните HTTP Recording Controller.

Компонент Recording Controller создаёт семплеры HTTP Request.

Добавление компонента HTTP(S) Test Script Recorder

Теперь нужно добавить компонент HTTP(S) Test Script Recorder в WorkBench:

Выберите WorkBench и кликните правой кнопкой мыши.
Нажмите Add >.
Выберите Non-Test Elements >.
Нажмите HTTP(S) Test Script Recorder.

Примечание: Компоненты, которые добавляются в WorkBench, не сохраняются вместе с остальными компонентами плана. Чтобы сохранить компоненты WorkBench, кликните на WorkBench правой кнопкой и выберите Save Selection As… Сохранив компоненты, можете добавить их в план тестирования; для этого откройте меню, нажмите Merge и выберите сохранённые компоненты WorkBench.

Настройка портов

Стандартный порт прокси HTTP(S) Test Script Recorder – 8080. Его можно изменить в глобальных настройках (Global Settings, параметр Port).

Шаблоны URL (опционально)

HTTP(S) Script Recorder позволяет добавлять шаблоны, URL Patterns, написанные как регулярные выражения. Они позволяют включить в запись и исключить из неё некоторые компоненты. Многие рекомендуют включать в запись только тип запрашиваемого контента (*.html, *.php, и т.п.) или исключать из записи типы контента, который запрашивать не нужно (к примеру, *.jpg, *.png, *.js).

Чтобы добавить шаблон:

Откройте раздел URL Patterns to Include или URL Patterns to Exclude;
Нажмите Add;
Введите шаблон.

Примечание: чтобы добавить больше шаблонов, просто повторите описанные выше действия.

Примеры:

URL Patterns дл веб-страниц:

.*.html .*.php .*.htm

URL Patterns для изображений:

.*.png .*.jpg .*.gif

Добавление компонентов в Script Recorder (опционально)

Чтобы записанные запросы наследовали какие-либо компоненты, нужно добавить эти компоненты в HTTP(S) Test Script Recorder. К примеру, если добавить в Script Recorder компонент Timer, то этот компонент будет добавлен в каждый запрос (HTTP Request). Этот компонент создаёт очередь потоков, ожидающих выполнения запроса.

Чтобы добавить Constant Timer в HTTP(S) Test Script Recorder:

Выберите HTTP(S) Test Script Recorder и кликните правой кнопкой мыши.
Нажмите Add >.
Выберите Timers >.
Нажмите Constant Timer.

Настроить ожидание потока можно по своему усмотрению.

Предположим, вы хотите эмулировать клики пользователей на разных страницах каждые 2 секунды; для этого нужно установить ожидание потока в 2000 миллисекунд.

Запись тестирования

Нажмите кнопку Start в окне Script Recorder, чтобы запустить прокси-сервер JMeter, который будет перехватывать и записывать запросы к браузеру.

При первом запуске Script Recorder вернёт ошибку, сообщив, что он не может запуститься, поскольку нет сертификата. Просто нажмите OK, после чего инструмент запустится во второй раз. На экране появится сообщение о том, что в каталоге bin инструмент JMeter создал временный сертификат ApacheJMeterTemporaryRootCA.crt. чтобы продолжить, нажмите OK.

Примечание: Если браузер уже использует прокси-сервер, то нужно настроить JMeter для использования этого сервера ещё до запуска. Для этого существуют параметры -H и –P.

Настройка браузера для использования прокси-сервера JMeter

В данном руководстве используется браузер Firefox. В отличие от Chrome и некоторых других браузеров, он позволяет ппрокси-серверам переопределять общесистемные настройки.

Настройте Firefox для использования локального хоста (127.0.0.1) на порте 8080 в качестве прокси-сервера для всего трафика:

Откройте Firefox;
Найдите меню Preferences;
Кликните в нём по вкладке Advanced;
Откройте вкладку Network;
В разделе Connection кликните «Settings…»;
Нажмите Manual proxy configuration;
В HTTP Proxy укажите localhost, а в Port – 8080;
Нажмите OK и закройте меню Preferences.

Примечание: Если браузер Firefox настроен для поддержки прокси-сервера JMeter для Script Recorder, он будет работать корректно только тогда, когда запущен Script Recorder.

Запись запросов HTTP

Теперь, когда HTTP(S) Test Script Recorder запущен, а Firefox настроен для поддержки его прокси-сервера, все HTTP-запросы браузера будут записаны.

Убедитесь, что всё работает должным образом.

В браузере Firefox откройте домашнюю страницу сервера, указанного в HTTP Request Defaults.

http://your_domain.com/

Рядом с Recording Controller должен появиться маленький символ треугольника. Чтобы получит расширенные сведения, кликните по нему. На экране появится список HTTP-запросов, составленный согласно установленному шаблону.

Этот список можно отредактировать вручную, просто удалив ненужные запросы.

Если Recording Controller не предоставил списка запросов, просмотрите шаблоны для HTTP(S) Test Script Recorder.

Примечание: Рекомендуется удалить все шаблоны.

Завершив запись запросов, нажмите Stop в окне HTTP(S) Test Script Recorder.

Имейте в виду: на данный момент браузер Firefox не имеет доступа к другим страницам, поскольку он настроен для использования порта 8080 в качестве прокси. Чтобы изменить это поведение, настройте браузер для использования «No proxy».

Запуск тестирования

Когда план тестирования будет готов, сохраните и запустите его. Он будет работать в точности как созданный вручную тест; вы можете настраивать, удалять, добавлять в него компоненты.

Заключение

HTTP(S) Test Script Recorder поможет быстро разработать план JMeter.

Инструмент JMeter позволяет оптимизировать и усовершенствовать сервер веб-приложения, устранить неполадки в настройках и увеличить его производительность.

Данное руководство охватывает только основы работы с Recording Controller. Изучите остальные функции этого инструмента самостоятельно.

Tags: Apache, Apache JMeter, Oracle Java 7

Источник

It is important to carefully choose your load testing tools. JMeter is the most popular open-source load and software performance testing tool.

This blog post will offer a basic JMeter tutorial, which will be simple to follow so teams can get started right away. We will create a few basic JMeter scripts and go over different JMeter features like assertions and dynamic data. In the end, we will briefly talk about analyzing your results in reports.

Table of Contents:

What is JMeter & How Is It Used?
JMeter Tutorial: Your First Steps
Analyzing Results From Your JMeter Tutorial

What is JMeter & How Is It Used?

Open-source and JAVA-based, JMeter simulates the results of browser behavior (though it’s not a browser!) by sending requests to web or application servers. JMeter can also parse the responses. On your local machine, you can increase the load by scaling up to approximately several hundreds of users.

Note that using BlazeMeter, you can scale your load up much, much further, testing thousands or even millions of virtual users in the cloud.

JMeter Tutorial: Your First Steps

1. Your First Script

To start off our JMeter tutorial, you first need to download JMeter.

This is the JMeter interface:

The Test Plan is your JMeter script. It determines the flow of your load test.

In this JMeter tutorial, we will load test the demo we always use at BlazeMeter, which simulates a mock travel agency named Simple. The Simple Travel Agency lets us search and choose flights, which we will simulate doing through JMeter. Our first script will simply search for available flights.

Thread Groups

To start building the test script, add a Thread Group to your test plan.

Thread groups determine the user flow and simulate how users behave on the app. Each thread represents a user.

Right click the Test Plan, select «Threads(Users)», then select «Thread Group».

Configure the Thread Group by setting:

Name: Provide a custom name or, if you prefer, simply leave it named the default “Thread Group”.
Number of Threads: The number of users (threads) you are testing. Let’s say 3.
Ramp-up Period: How quickly (in seconds) you want to add users. For example, if set to zero, all users will begin immediately. If set to 10, one user will be added at a time until the full amount is reached at the end of the ten seconds. Let’s say 5 seconds.
Loop Count: How many times the test should repeat. Let’s say 1 time (no repeats).

Samplers

We want to send an HTTP request to our demo site, so add an HTTP Request Sampler.

Right-click the thread group, select “Add”, select “Sampler”, then select “HTTP Request”.

Configure the Sampler by setting:

Name: Provide a custom name or simply leave it named the default “HTTP Request”.
Server Name or IP: The server’s DNS name or IP address. In this case — blazedemo.com.
Set the protocol to “https” as the websites which are accessible only via HTTP are marked as insecure by browsers and excluded from search engine results.

Timers

When users click on your website or app, they naturally have pauses and delays. These can be simulated with Timers.

Constant timers are the most common. They determine how many milliseconds to wait between requests.

Right-click your HTTP Request, select “Add”, select “Timer”, then select “Constant Timer”

In this case, we will wait for 300 milliseconds.

Listeners

After running our test, we want to see its results (obviously). This is done through Listeners, a recording mechanism that shows results, including logging and debugging information.

The View Results Tree is the most common Listener.

Right-click your thread group, select “Add”, select “Listener”, then select “View Results Tree”.

We’re done! This is the basic script we created for hitting the BlazeDemo page:

Now click ‘Save’. Your test will be saved as a .jmx file.

To run the test, click the green arrow on top. After the test completes running, you can view the results on the Listener.

In this example, you can see the tests were successful because the results show green icons. On the right, you can see more detailed results, like load time, connect time, errors, the request data, the response data, etc. You can also save the results if you want to.

2. Your Second Script

Congratulations! That was your first script. Now let’s continue this JMeter tutorial by creating a second one and adding parameters to it. Whereas the first script simply searched for flights, this script will search, then choose a flight.

How do you simulate that?

When you search for a flight in your web browser, and click the “Choose This Flight” button beside the flight of your choice, note that the next page adds a “/reserve.php” to the URL.

With this in mind, go back to JMeter and add another HTTP Sampler. This time, we’ll not only specify “blazedemo.com”, but we’ll add “reserve.php” to the “Path” field. Doing so tells the sampler to build a full URL of “blazedemo.com/reserve.php”.

Next, add the parameters required to make the selection. (If you don’t already know what parameters your webpage is designed to use for this scenario, you can use your web browser’s developer tools to review the page code and find it. That is a separate topic to cover another day). To complete the choice, this page requires we specify a “fromPort” and “toPort”, which we’ll designate “Boston” and “London”, respectively:

We’ll also add a “View Results in Table” Listener, just to spice things up.

This is the second test plan, which includes hitting the Home page, and then sending two parameters to the Reserve page.

Save and run the test.

In the results, you can see that each page is hit 3 times:

The View Results Table shows us additional data: start time, sent bytes, connect time, latency, etc.

3. Your Third Script

Congratulations! You can now create your own basic JMeter scripts. But as you might have understood, if you need to create a long user flow, it could take you a long time.

Therefore, a better way to create scripts is by recording them. To record, you can either use the JMeter recorder, or the BlazeMeter Chrome Extension. The BlazeMeter extension, free to use from the Chrome store, is more user friendly than the JMeter one, which requires you to set a proxy to redirect the traffic.

Through your Chrome, start recording and simulate the user scenario you want to test by clicking away. When you’re done, stop the recording, and edit as necessary.

Export your recording to JMX. Don’t forget to move the downloaded script to your preferred folder.

Open the .jmx file file in JMeter. You will be able to see your test plan, which was created from the recording and the .jmx file.

Note that this plan has new elements, like Cookie Manager and Cache Manager. They are here because browsers keep cookies and cache, and they were captured in the recording. You can clear them up if you need to. These entirely optional elements are present to simulate web browser behavior more closely.

Now add a listener and run the test.

Assertions

Assertions are elements that let you check for errors, or in other words — determine if your test passes or fails. JMeter automatically marks requests with HTTP status codes below 400 as successful, but it might be the case that server responded with HTTP status code 200 OK but the response is full of errors or simply absent.

Let’s say we want to make sure a webpage returns the information we’re looking for. In our example, we want to make sure users who purchase flights receive a message on the confirmation page saying — Thank you for your purchase today!

Go to JMeter.

Add a Response Assertion (you know how to do it).

Add the exact characters you want users to see.

Save and run the test.

If the response contains the string, the test will pass. If not, the test will fail, and it will also detail why.

Dynamic Data

What happens when you want to create a dynamic script, which chooses different parameters each time you test, like passwords, login information, or search criteria? This is what Dynamic Data through CSV files is for.

Create a CSV file on your computer, consisting of the different variables you are testing. Put the file in the JMeter folder. In our case, we created a basic one, with departure and destination cities.

Right-click your thread group, select Add, select Config Element, then select CSV Data Set Config.

Configure by adding the variable names. In our case, fromPort and toPort.

Go back to the HTTP Request (from our second script) and change the variable from the specific name (of the cities) to the general name.

The data tested will now come from the CSV file, and you will be able to see the dynamic results in the View Results Tree. In our example, it’s no longer Boston and London, but Philadelphia and Berlin, Portland and Rome, etc.

Scalability

After you build your test and check it for a low number of virtual users, it’s time to scale it up and check a large number of VUs. How many? That depends on your business goals.

In general, we recommend that in addition to your expected number of users, you bring your test to the limit. This lets you characterize your system’s strengths and weaknesses, enabling you to plan better and also react in real-time to unexpected bottlenecks and errors. Testing the website against anticipated number of users is known as “load testing” and finding the boundaries is a “stress testing” check.

The best way to scale is through BlazeMeter, which lets you run heavier loads than JMeter. BlazeMeter lets you upload your JMeter scripts, scale your number of users, choose your region, set ramp-up time and determine how long the test will run.

Analyzing Results of Your JMeter Tutorial

After running your test on BlazeMeter, you will get rich and in-depth reports, with KPIs like throughput, error rate, and connection time. Reports let you analyze trends and statistics, determine the health of your system, and decide how you want to keep developing your product.

In addition there is extra powerful Timeline Report which gives you ability to correlate any metrics you can think of. And it’s also possible to compare reports for different test executions.

Congratulations! You just finished your basic JMeter tutorial. Now, get started testing yourself in BlazeMeter.

START TESTING NOW

Related Resources

JMeter Command Line Overview: 5 Ways To Launch a Test
How to Increase Developer Productivity

Источник