1. Самый простой способо - это авторизация встроенный в JMeter HTTP Authorization Manager (Add ->
Config Elements ->
HTTP Autorization Manager), в котором все в принципе понятно: указываем url обязательно с http://, Username и Password.
2. Второй способ - это
HTTP Request (Add -> Sampler -> HTTP Request). Дабовляем в него два параметра Username и Password.
Если вы используете для авторизации HTTP Request, то самый надежный способ - это записать сценарий при помощи
HTTP Proxy Server, о котором я расскажу чуть позже.
3. Если мы эмулируем действия нескольких пользователей, имеющих свой собственный логин и пароль, то HTTP Autorization Manager или HTTP Request с явно заданными логином и паролем уже не подойдут.
Для начала в нашем HTTP Request'е авторизации вместо конктретных значений вписываем две переменные ${login} и ${pass}.
Где будут храниться значения этих переменных? Есть два варианта: при помощи
User Parameters или в CSV файле. Первый вариант предназначен для небольшого количества пользовательских параметров и в этом пункте речь пойдет именно о нем.
Добавляем User Parameters ( Add -> Pre Proccesors -> User Parameters). По умолчанию там один пользователь без параметров. Добавим еще два (Add User). Потом добавим два параметра login и pass. Указываем значения этих параметров для каждого пользователя.
Теперь если вы запуститите свой тест-план для одного пользовотеля, то он возьмет значения из user_1, если трех - то user_1, user_2 и user_3 по очереди, а если пользователей будет больше чем параметров, то значения будут браться по кругу.
4. Теперь рассмотрим следующий случай: мы имеем тестовый стенд с N-ым количеством пользователей вида login1, login2 ... loginN. Все эти пользователи имеют один и тот же пароль.
Как реализовать авторизацию в этом случае? При помощи метод
__counter. Берем тот же User Parametrs и оставляем одного пользователя. Указываем наш пароль, а вместо логина пишем login${__counter(FALSE,)}.
Теперь мы будем получать каждый раз нового пользователя с префиксом login и суффиксом, который стартует с 1 и при каждом обращении увеличивается на 1. Параметр FALSE в методе означает, что этот счетчик глобальный. Если мы поменяем его на TRUE, то этот счетчик будет независимым для каждого пользователя. Для авторизации нужен именно глобальный счетчик.
5. В предыдущем варианте есть пара минусов. Допустим, у нас в рамках тест-плана должен авторизоваться 101 пользователь, а в системе их только 100. Наш __counter этого не знает и после 100 пользователей на второй круг не пойдет, а попытается авторизоваться 101-ым пользоватлем. Или наши пользователи имеют формат login001, login 002 ... loginNNN
В этой ситуации нам может помочь элемент
Counter (Add -> Config Element -> Counter). Это уже не метод, а отдельный элемент.
Добавляем Counter и указываем в нем следующие параметры:
- стартовое значение (Start)
- шаг счетчика (Increment)
- максимальное значение (Maximum)
- формат (Number Format) (значение формата может состоять только из нулей, указывающих разрядность, или же с содержанием символов как перед нулями так и после)
- имя переменной, которое мы потом будет использовать в HTTP Request авторизации (Reference Name)
Параметр "
Track Counter Independently for each User" включет независимость счетчика аналагично методу __counter, параметр "Reset counter on each Thread Group Iteration"- сбрасывает счетчик каждую итерацию, что может быть полезно в Loop Controller.
И так мы имеем следующую картину:
Теперь мы правим наш HTTP Request авторизации. В поле Username вписываем префикс нашего логина и переменную, объявленную в счетчике, и получится login${Id}. В поле Password вписываем наш пароль, общий для всех пользователей.
В том случае, если вы используете все время один и тот же префикс, то можно вынести его Counter в параметр Number Format.
