M
Та мне как раз нужно два числа сравнить
Size: a a a
2020 March 21
VG
Тогда попробуй конвертнуть в инты
M
Тогда попробуй конвертнуть в инты
Спасибо, ща попробую
VG
Пробовать работает ли условие можно прямо в хелпере функций сверху, выбрав «__groovy»
VG
Без запуска теста
M
Спасибо
ВС
А теперь вопрос почему выражение ${__groovy(vars.get("num").toInteger() > 35 )}; не работает ?
Параметр должен быть строкой кода:
${__groovy('vars.get("num").toInteger() > 35 ')};
${__groovy('vars.get("num").toInteger() > 35 ')};
ВС
И в логе JMeter пишется, что не так
M
А у вас здесь стоят кавычки одинарные?
ВС
А у вас здесь стоят кавычки одинарные?
Да
M
Спасибо
ВС
Был не прав. В примерах из документации нет кавычек
https://jmeter.apache.org/usermanual/functions.html#__groovy
https://jmeter.apache.org/usermanual/functions.html#__groovy
DB
привет. а можешь развернуть мысль? я часто использую weighted switch и подобные элементы для ветвлений в сценарном тесст плане. не первый раз слышу мысль, что это антипаттерн.
@smirnovqa ты, кажется, в одном из видео говорил, что использование ветвлений в тест плане является антипатерном. можешь пояснить?
M
Был не прав. В примерах из документации нет кавычек
https://jmeter.apache.org/usermanual/functions.html#__groovy
https://jmeter.apache.org/usermanual/functions.html#__groovy
Да, так не работает)
DB
Слава имеет в виду, что если у тебя пользователь входит в систему и в половине случаев делает платёж, а в половине платёж и выписку - делай два скрипта:
Один «вход и платёж», другой «вход + платёж + выписка»
Но имхо так не всегда получается.
Так что я делаю, как мне удобнее.
Проблема контроллеров ветвления в отладке, а значит в повышенной вероятности ошибиться.
Чем ещё они плохи - не знаю.
Один «вход и платёж», другой «вход + платёж + выписка»
Но имхо так не всегда получается.
Так что я делаю, как мне удобнее.
Проблема контроллеров ветвления в отладке, а значит в повышенной вероятности ошибиться.
Чем ещё они плохи - не знаю.
спасибо. я считаю, что два подхода взаимозаменяемы. можно делать одну группу с ветвлениями, а можно делать несполько групп с "прямым" флоу
ВС
Цель НТ, как правило - определенный профиль нагрузки.
Если этот профиль можно достичь с помощью Throughput controller, то его использую.
Пример:
20% запросов от больших компаний
80% от индивидуальных предпринимателей
Весь сценарий - 1 запрос. Но он либо первый, либо второй.
А иногда, в нагрузке, пробуют сделать тест с условиями. С длинным сценарием. Когда случайный клиент заходит, переходит в свой профиль, смотрит ИП он или Корпорация, и после этого делает либо 3 запроса либо 10. И все это с условиями.
Вот такие тесты имеют много недостатков.
Если этот профиль можно достичь с помощью Throughput controller, то его использую.
Пример:
20% запросов от больших компаний
80% от индивидуальных предпринимателей
Весь сценарий - 1 запрос. Но он либо первый, либо второй.
А иногда, в нагрузке, пробуют сделать тест с условиями. С длинным сценарием. Когда случайный клиент заходит, переходит в свой профиль, смотрит ИП он или Корпорация, и после этого делает либо 3 запроса либо 10. И все это с условиями.
Вот такие тесты имеют много недостатков.
M
А теперь вопрос почему выражение ${__groovy(vars.get("num").toInteger() > 35 )}; не работает ?
Заработало вот так : ${__groovy(vars.get("num") < "35" )}; может кому-то пригодится)
AR
Цель НТ, как правило - определенный профиль нагрузки.
Если этот профиль можно достичь с помощью Throughput controller, то его использую.
Пример:
20% запросов от больших компаний
80% от индивидуальных предпринимателей
Весь сценарий - 1 запрос. Но он либо первый, либо второй.
А иногда, в нагрузке, пробуют сделать тест с условиями. С длинным сценарием. Когда случайный клиент заходит, переходит в свой профиль, смотрит ИП он или Корпорация, и после этого делает либо 3 запроса либо 10. И все это с условиями.
Вот такие тесты имеют много недостатков.
Если этот профиль можно достичь с помощью Throughput controller, то его использую.
Пример:
20% запросов от больших компаний
80% от индивидуальных предпринимателей
Весь сценарий - 1 запрос. Но он либо первый, либо второй.
А иногда, в нагрузке, пробуют сделать тест с условиями. С длинным сценарием. Когда случайный клиент заходит, переходит в свой профиль, смотрит ИП он или Корпорация, и после этого делает либо 3 запроса либо 10. И все это с условиями.
Вот такие тесты имеют много недостатков.
А если это все в трухпут закинуть и проценты выставить(вероятность) и реализовать ветвления. Ведь в таком случае должно получиться без всяких if? Правда , с шагом тоже будет проблема.
ВС
Первый недостаток сценариев с условиями - нельзя узнать заранее, сколько запросов будет в сценарии, а значит, как долго они будут выполняться. Для JMeter/LoadRunner, с их закрытой моделью нагрузки, это означает, что нельзя выставить шаг нагрузки точно. И его выставляют по большей границе - для 10-ти запросов. И в результате тест требует 10 000 потоков. Люди запускают и говорят, что инструмент тормозит. Или вообще ставят настройки шага и потоков неверно.
Второе. В отчёте, нет информации какие же сценарии в результате выполнились.
Третье. Сделать IF-ы не так-то просто. Вот коллеги выше ломают копья. Тест получается часто некорректным, со скрытыми ошибками.
Второе. В отчёте, нет информации какие же сценарии в результате выполнились.
Третье. Сделать IF-ы не так-то просто. Вот коллеги выше ломают копья. Тест получается часто некорректным, со скрытыми ошибками.
M
Первый недостаток сценариев с условиями - нельзя узнать заранее, сколько запросов будет в сценарии, а значит, как долго они будут выполняться. Для JMeter/LoadRunner, с их закрытой моделью нагрузки, это означает, что нельзя выставить шаг нагрузки точно. И его выставляют по большей границе - для 10-ти запросов. И в результате тест требует 10 000 потоков. Люди запускают и говорят, что инструмент тормозит. Или вообще ставят настройки шага и потоков неверно.
Второе. В отчёте, нет информации какие же сценарии в результате выполнились.
Третье. Сделать IF-ы не так-то просто. Вот коллеги выше ломают копья. Тест получается часто некорректным, со скрытыми ошибками.
Второе. В отчёте, нет информации какие же сценарии в результате выполнились.
Третье. Сделать IF-ы не так-то просто. Вот коллеги выше ломают копья. Тест получается часто некорректным, со скрытыми ошибками.
Вячеслав, подскажите пожалуйста, где можно почитать, посмотреть, как правильно выбрать шаг нагрузки? Заранее благодарю.