Как правильно настроить авторизацию в тест-Плане Jmeter?

Собственно сабж. Надо с помощью Jmeter v.2.3 "зайти" по Username и Login, с тем, чтобы дальше тестировать страницы веб приложения.
Из докумнтации не совсем понятно, как это делать.

Для ответа на этот вопрос надо знать, как у вас построена авторизация: это экранная форма с двумя полями, или это basic authentication? Если форма, то все тривиально: создаем HTTPSampler с урлом страницы логина, тип запроса для него устанавливаем в сэмплере тип запроса формы (в сорсе страницы будет указано, как отправлять параметры- с помощью GET или с помощью POST, подозреваю, что будет POST), прописываем пары "переменная-значение", где "переменная" - имя переменной, соответствующей полю ввода на форме, значение - собственно логин или пароль. В моем случае это делается двумя сэмплерами: первым вызывается собственно страница логина (GET-запрос), потом отсылается информация формы логина - POST запрос. Все, что в ${} - переменные, вы их можете пока не использовать.

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

Вот это ж совсем другое дело!
Скачал-поставил BadBoy. Сыграл-записал скрипт. Экспортировал в JMeter, допилил кое-что и запустил. Вау! С этого и надо было начинать!
Скрипт получился полноценный с тремя контроллерами - логин (Once Only Controller), хождение по нескольким формам (Loop Controller) и логаут (Simple Controller). Использовал также User Defined Variable. Соотношение Users/Rump-up поднимал постепенно: 1/1, 5/1, 10/3, 20/5, 50/10, 100/20. В двух последних случаях диспетчер задач рисовал для процессора вначале резкий пик до 70-90%, а потом трапецию с вершиной на уровне 40-60%. И всё это на удаленном сервере через cisco VPN - просто песня! Это уже похоже на тестирование.
Надо еще посмотреть, как работает Remote Start в JMeter.

Следующий шаг – записать "совсем живой" длинный сценарий и настроить его получше в JMeter: таймеры, графики, … Теперь и документация по JMeter читается легче, зря я грешил на неё. Только он-лайн документация выложена к старой версии и кое-чего в ней всё-таки не хватает. (Может у кого есть доки и tutorial по JMeter v.2.3?). Хорошо, что примеры есть, их можно скачать и посмотреть изнутри как они устроены.
Теперь пора и за профайлеры браться.

Если я правильно понял, то в бесплатной связке BadBoy-JMeter первый используется только для генерации Сценария для JMeter. Потому что бесплатная версия BedBoy ограничена только 5-ю юзерами. Хотя, как я посмотрел, у BedBoy совсем неплохие репорты.

А ещё мне сказали, что есть у Apache тест-тул AB. Кто-нибудь знает?

В общем и целом, с сегодняшнего дня у меня изменилось обманчивое впечатление к бесплатным тест-тулам, как к чему то несовершенному.
Ещё раз спасибо форуму и altermath!

Соотношение Users/Rump-up поднимал постепенно: 1/1, 5/1, 10/3, 20/5, 50/10, 100/20. В двух последних случаях диспетчер задач рисовал для процессора вначале резкий пик до 70-90%, а потом трапецию с вершиной на уровне 40-60%. И всё это на удаленном сервере через cisco VPN - просто песня! Это уже похоже на тестирование.
Надо еще посмотреть, как работает Remote Start в JMeter.

Хорошо, что получилось. Рекомендую все-таки погуглить на тему того, что именно и как измеряется в performance тестировании: возможно, вам потребуется провести анализ логов. Все просто: определяемся с целью (доказать, что отклик на 100 пользователях хороший, что на 1000 пользователей приложение еще не падает, что оно работает неделю под нагрузкой в 50 пользователей, каково максимальное количество пользователей, при которм время отклика любой страницы не больше 5 секунд и т.п.) и отсюда составляем сценарии. Обратите внимание, что реально тестирование начинается не после первого прогона всех пользователей (запустили, скрипт отработал один раз) а после ряда прогонов (Loop count в свойствах Thread group). количество повторов определяется исходя из целей теста. Собранные данные (например, из записанных логов или копипастнутые из Summary report) обрабатываются (опять-таки в соответствии с целью)

(Может у кого есть доки и tutorial по JMeter v.2.3?). Хорошо, что примеры есть, их можно скачать и посмотреть изнутри как они устроены.
Теперь пора и за профайлеры браться.

А что отсутствует в документации? ИМХО для начала там все есть :-)

А ещё мне сказали, что есть у Apache тест-тул AB. Кто-нибудь знает?

Apache AB предназначен для тестирования производительности HTTP-сервера Апачи. Отвечает на вопрос: сколько запросов в секунду может обработать сервер (под запросом понимается любой запрос к серверу - на отдачу картинки, скрипта и т.п., а не страница целиком). Немного не то, насколько я могу видеть. + сомнительно удобство использования для ваших целей.

В догонку темы:
После экспорта Тест-Плана из BadBoy в Jmeter есть вопросы:
1. В HTTP Cookie Manager параметр Cookie Policy="compatibility" почему? Там ещё 5 значений:
rfc2965
default
ignorecookies
netscape
rfc2109

2. User Parameters имеет всего 2 параметра: VIEWSTATE и jsessionid. Причем значение поля User_1 пустое.
Зачем BadBoy сгенерировал User Parameters, почему два таких параметра без значений?

3. Мой тест работает с одним юзером – user1.
А можно ли, например, с помощью User Defined Variables или User Parameters сделать так, чтобы используя всего одну Thread Group, запускать 100 разных юзеров, скажем таких:
user1, user2, …, user100.
Или это невозможно и мне придется Thread Group копировать 100 раз и задавать в каждой копии новых юзеров.

4. Если решение вопроса 3 возможно, то можно ли в одной Thtread Group разным юзерам заполнять одни и те же поля разными значениями через переменные, например так:
fld1_val1, fld1_val2, …, fld1_val100
fld2_val1, fld2_val2, …, fld2_val100
…
Задаю вопросы 3 и 4 потому что надо, чтобы юзеры были разные и чтобы они по одному сценарию вводили разную информацию в одни и те же поля.
Эти два вопроса самые актуальные!

5. Изучая запросы в Login контроллере и в Loop Controller (там, где работают Threads), обнаружил несколько групп последовательных запросов (по 2 и по 3 запроса в группе), которые относятся к одной web-странице, но отличаются по значениям некоторых параметров. Какой в этом смысл?

В догонку темы:
После экспорта Тест-Плана из BadBoy в Jmeter есть вопросы:
1. В HTTP Cookie Manager параметр Cookie Policy="compatibility" почему? Там ещё 5 значений:
rfc2965
default
ignorecookies
netscape
rfc2109

Compatibility обеспечивает 100% работу куки-менеджера

2. User Parameters имеет всего 2 параметра: VIEWSTATE и jsessionid. Причем значение поля User_1 пустое.
Зачем BadBoy сгенерировал User Parameters, почему два таких параметра без значений?

Вопросы к разработчикам BadBoy, этот вопрос я просто не исследовал. Я этот конфигуратор просто удаляю.

3. Мой тест работает с одним юзером – user1.
А можно ли, например, с помощью User Defined Variables или User Parameters сделать так, чтобы используя всего одну Thread Group, запускать 100 разных юзеров, скажем таких:
user1, user2, …, user100.
Или это невозможно и мне придется Thread Group копировать 100 раз и задавать в каждой копии новых юзеров.

4. Если решение вопроса 3 возможно, то можно ли в одной Thtread Group разным юзерам заполнять одни и те же поля разными значениями через переменные, например так:
fld1_val1, fld1_val2, …, fld1_val100
fld2_val1, fld2_val2, …, fld2_val100
…
Задаю вопросы 3 и 4 потому что надо, чтобы юзеры были разные и чтобы они по одному сценарию вводили разную информацию в одни и те же поля.
Эти два вопроса самые актуальные!

Путаница в терминологии. что значит - запускать разных юзеров? если имеется в виду, что в рамках одной Thread Group будут использованы разные данные для каждого виртуального юзверя - то да, можно. Смотрите в сторону CSV Data Set Config и User defined Variables.
Настоятельно рекомендую прочесть референс по компонентам JMeter
Для подлинных тестов, замешанных на данных, придется учить еще регулярные выражения (RegEx, regular expressions)

5. Изучая запросы в Login контроллере и в Loop Controller (там, где работают Threads), обнаружил несколько групп последовательных запросов (по 2 и по 3 запроса в группе), которые относятся к одной web-странице, но отличаются по значениям некоторых параметров. Какой в этом смысл?

Смотрите внимательнее: один запрос - запрос страницы типа GET (в нем могут быть перечислены все параметры, окторые передаются через адресную строку - после символа "?", напр: http://example.com?u...d=10&post-id=15 внесет две переменные в сэмплер - user-id и post-id). Второй запрос- запрос на пересылку данных формы - POST.

Спасибо за ответы!

По вопросам 3 и 4 поясняю.
В созданном в JMeter Тест-Плане ипользуется только одна Thread Group.
В этой Thread Group юзер с username = user1 логинится на сайте и гуляет по страницам.
Если во Thread Properties задать Number of Threads (users) = 100, то это будет означать, что 100 юзеров с одинаковым username = user1, будут в рамках отведёного им времени (Rump-Up Period) логиниться в систему. Т.е. все 100 user1 регистрируются почти одновременно.
Вот я и задался вопросом - а возможно ли залогиниться не сотней одинаковых юзеров user1, а сотней РАЗНЫХ юзеров (user1...user100) в рамках одной Thread Group и одного Rump-Up Period???

И еще вопрос. В приложении к этому сообщению графический файл - результат одного из тестов.
CPU usage для 2-х процессорного сервера.
Замер сделан дистанционно прямо на сервере с помощью Диспетчера задач Windows 2000 Server
Условия теста такие:
Threads (Users): 100
Rump-Up Period (sec): 20
Loop Count: 1
Эти 100 юзеров открывали последовательно два десятка страниц, заполняли поля разных типов и делали сабмиты страниц.
Как нужно правильно интерпретировать этот результат?
Может быть и неправильно, но я резюмировал так:
1. Вначале пик до 90-100% из-за массового залогинивания на сайте. Не хватает Threads установленных в системе (JBoss?)
2. Отдельные пики до 60-70% результат неоптимизированного кода обрабатывающего соответствующие пикам страницы.
3. То, что пики и их время отличаются у двух процессоров говорит о несбаллансированных в коде Threads.
4. В идеале стремиться надо к тому, чтобы получилась трапеция с ровной вершиной.
Верно?

Спасибо за ответы!

По вопросам 3 и 4 поясняю.
В созданном в JMeter Тест-Плане ипользуется только одна Thread Group.
В этой Thread Group юзер с username = user1 логинится на сайте и гуляет по страницам.
Если во Thread Properties задать Number of Threads (users) = 100, то это будет означать, что 100 юзеров с одинаковым username = user1, будут в рамках отведёного им времени (Rump-Up Period) логиниться в систему. Т.е. все 100 user1 регистрируются почти одновременно.
Вот я и задался вопросом - а возможно ли залогиниться не сотней одинаковых юзеров user1, а сотней РАЗНЫХ юзеров (user1...user100) в рамках одной Thread Group и одного Rump-Up Period???

Можно: http://jakarta.apach...ameter_Modifier и погуглить на эту тему.

И еще вопрос. В приложении к этому сообщению графический файл - результат одного из тестов.
CPU usage для 2-х процессорного сервера.
Замер сделан дистанционно прямо на сервере с помощью Диспетчера задач Windows 2000 Server
Условия теста такие:
Threads (Users): 100
Rump-Up Period (sec): 20
Loop Count: 1
Эти 100 юзеров открывали последовательно два десятка страниц, заполняли поля разных типов и делали сабмиты страниц.
Как нужно правильно интерпретировать этот результат?
Может быть и неправильно, но я резюмировал так:
1. Вначале пик до 90-100% из-за массового залогинивания на сайте. Не хватает Threads установленных в системе (JBoss?)
2. Отдельные пики до 60-70% результат неоптимизированного кода обрабатывающего соответствующие пикам страницы.
3. То, что пики и их время отличаются у двух процессоров говорит о несбаллансированных в коде Threads.
4. В идеале стремиться надо к тому, чтобы получилась трапеция с ровной вершиной.
Верно?

1. Каждую секунду на сайт ломились по 5 пользователей - это несколько разнится с тем, что мы хотели тестировать, см. пункт 2.
2. Неверно, что вы провели только один цикл нагрузки (loop count): потому что сервер еще даже не вышел на свою загрузку. Я бы прогнал раз 5 и посмотрел на реакцию сервера (числа условны, надо соображать на месте). Для выхода на желаемую загрузку в 100 пользователей хотя бы два цикла должно пройти. Все пункты ниже особой ценности не имеют в свете того, что был прогнан один цикл, и являются просто размышлениями на тему.
3. Пик до 100%: можете поэкспериментировать с настройками сервера, если это необходимо: но ведь цель теста определить возможности текущей конфигурации, не так ли?. К тому же - был ли "разогрет" сервер к моменту нагрузки, были ли скомпилированы все JSP (или на чем там у вас приложение) к моменту нагрузки? Что творится с кешем? В общем, вопросов больше чем ответов. Лично мой опыт: я никогда не делаю выводы на основе только показателей диспетчера задач (кстати, память он показывает неправильно и заниженно :-) )
4. Отдельные пики - м.б. проблема в коде, а м.б. - в тесте. (см. п. 2)
5. То, что диаграмма на двух процессорах должна быть одинаковая - это миф. Не должна она быть, потому что у вас помимо вашего сервера еще куча процессов в всистеме крутится, и на каком процессоре ни выполняются - это загадка. вот если бы у вас весь код только на одном ядре выполнялся, а второе было бы в нулях - это уже повод задуматься (ситуация чисто умозрительная, лично я на деле с таким не встречался)
6. Идеала нет. Трапеция - хорошое приближенеи, но опять - таки миф. Что вы хотите показать трапецией? Что приложение работает стабильно? У стабильности другие показатели: что приложение не отказывает в течение недели, двух под нагрузкой без рестарта, и т.п.

Конечно, 1-го прогона мало.
Пожалуйста - в приложении 5-ти кратный прогон - процессор разогрет как надо
И, я думаю, количество юзеров работающих одновременно можно считать 90.
Этот тест из той же серии тестов с постепенным повышением нагрузки.
Ступенчато увеличивал кол-во юзеров: 10, 20, ... до 100.
И на каждой ступеньке плавно уменьшал время Rump-Up: 40, 28, ..., до 10.
Последний пятипрогонный тест (90 / 24 / 5) сделал в самом конце этой серии однопрогонных тестов.
Что об этом тесте можно сказать?

Что об этом тесте можно сказать?

Что я мог бы сказать: если в результате работы все пользователи были обслужены без ошибок, среднее время осблуживания пользователя было приемлемым в соответствие с вашими требованиями - то тест пройден успешно. Если у вас есть сомнения в качестве настройки сервера, то необходимо собрать числовые значения загруженности процессора в процессе выполнения теста с одними настройками сервера, потом поменять настройки, прогнать тесты повторно, опять собирая информацию о загрузке, и так несколько раз. После чего анализировать полученные выборки. Например, на значимость различия - ТТестом тем же самым.
Мне не очень понятно, из каких соображений строился нагрузочный тест и что им хотели показать. Для анализа качества кода и настройки сервера имхо недостаточно состояния памяти и процессора: нужен профайлер, нужно смотреть, какие задачи работают, какие классы грузятся, что происходит со сборщиком мусора и т.п.
Я не большой специалист в области нагрузочного тестирования, и бОльшего сказать вам не могу, к сожалению.

Может кто подробно подсказать как сделать в jmeter правильную авторизацию, я пробывал с помощью Badboy но то чт я получил в самом Badboy плохо работае (не логинить) онон просто пробует перейти на URL который там указан и все. Также пробывал с Selenium но тоже ничего не получилось. Поскажите пожалуста понимаю что где то туплю но не могу понять где!

Может кто подробно подсказать как сделать в jmeter правильную авторизацию, я пробывал с помощью Badboy но то чт я получил в самом Badboy плохо работае (не логинить) онон просто пробует перейти на URL который там указан и все. Также пробывал с Selenium но тоже ничего не получилось. Поскажите пожалуста понимаю что где то туплю но не могу понять где!

В Jmeter есть возможность записи действий через прокси. Не пробовал?
Он сам пишет данные передаваемые с запросом. Остается только погулять по нужным страницам и потом руками доработать скрипт (там таймеры, листнеры добавить и проч.)

Пара вопросов:

1. Очень прошу залить пример реализации авторизаций внутри потока, будет коротко и ясно.

2. Вопрос по функциям. Столкнулся с тем, что __random является константой везде, где вызываю переменную (генерится один раз для каждого отдельного потока). Почему/как побороть? О_о

Заранее благодарен, съем и линки (только по сабжу плз).

Всем доброго времени суток!
С JMeter возникла такая проблемка: в тестируемом приложении авторизация устроена так, что имена полей ввода состоят из постоянной и переменной части (например: user-password$f6507:$$31748$$31749$$31756$...). Кто-нибудь сталкивался с подобным? Как выполнить авторизацию в таком случае? (запись тест-планов BadBoy ессно, результатов не даёт :)

Всем доброго времени суток!
С JMeter возникла такая проблемка: в тестируемом приложении авторизация устроена так, что имена полей ввода состоят из постоянной и переменной части (например: user-password$f6507:$$31748$$31749$$31756$...). Кто-нибудь сталкивался с подобным? Как выполнить авторизацию в таком случае? (запись тест-планов BadBoy ессно, результатов не даёт :)

В вашем случае нужно вытягивать изменяющуюся часть вашей авторизации и потом сабмитить ее при логине. Для этого можно итспользовать регулярные выражения (regular expressions).Почитайте в родной документации jmeter об regular expressions - как их использовать.