Size: a a a

QA — Load & Performance

2021 September 27

VK

Valeriy Khudasov in QA — Load & Performance
Всем привет. Растолкуйте, пожалуйста, как правильно вести сценарии в проектах JMeter? Также сгодятся ссылки на форум/документацию по указанным вопросам, если такое уже обсуждалось.
Собственно, что именно интересует:
1) Нужно ли использовать Transaction Controller (далее TC) или достаточно держать запросы в Simple Controller (далее SC)? Единственную плюшку для себя выявил, что с помощью TC можно в отчетах выводить не все запросы, а только сам контроллер и общие метрики по его содержимому, но чаще приходится смотреть метрики именно по определенным запросам, и тут уже лучше юзать SC. Или я что-то неправильно понимаю?
2) Какие правильно задавать имена для Samplers? Чаще всего в примерах видел, что имя сэмплера это path запроса, по типу /api/account/login. Но тут у меня тоже делема: в самом проекте JMeter мне достаточно держать группу запросов в контроллере, обозвать этот контроллер именем раздела, а сами запросы оставить с именем path запроса. Но когда я читаю результаты, это неудобно, запросов много и не всегда понятно к какому разделу относится тот или иной запрос, особенно сложно, когда есть одинаковые запросы, но в разных разделах. Чаще это актуально для авто-тестов. Яж надеюсь это нормальная практика делать авто-тесты rest-api в Jmeter?)))

Просто на данный момент у меня все запросы хранятся в Transaction Controller, а запросы в контроллере именуются в формате Авторизация-0, Авторизация-1 и т.д. (через Apply Naming Policy). А когда мне в отчетах надо вывести и path запроса, то подключаю JSR223 Listener и вывожу имя сэмплеров в формате <Имя контроллера> + <path запроса>. И меня терзают сомнения о том, что я делаю что-то неправильно, а возможно и плохо))
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
1) С Transaction Controller (далее TC) можно посчитать суммарную длительность группы запросов и сохранить ее в результаты. Это важно.
2) /api/account/login (POST), /api/account/login (GET), /api/account/login (PUT)
Login (TC) - для промежуточных транзакций
Создание документа (TC) - для основных транзакций (имя с кириллицы уже, с прописной)

Так можно в результатах фильтровать запросы, если заканчиваются (TC), а начинаются на А-Я - главная транзакция
Если просто заканчиваются на (TC) - просто транзакция
Если не заканчиваются на (TC) - запрос

Generate Parent Transaction использовать не стоит. Это приведет к исчерпанию ОЗУ в JMeter. Эту галочку надо точно снять.
Галочку - Include timers обычно ставят.

Промежуточные транзакции, в которых нужно включать таймер обычно такие, так-то:
WAIT document sign complete (TC)
а внутри цикл ожидания подписания документа или другой цикл
тут каждый конкретный web-запрос будет быстрым, а вот делать их с паузой в 1 сек в течение 42-х секунд и знать, что это заняло именно 42 сек важно
Ради этого цикл оборачивают в TC
источник

KY

Kirill Yurkov in QA — Load & Performance
у тебя несхождение в виде подхода:
1. rps-based - тот который основан на запросах в секунду, там отсутствуют TC и отсюда интерпретация идет напрямую в запросах в секунду без прослойки.
2. tps-based тут более бизнесовый слой, с послдующей интерпретацией. стоит сначала выбрать слой а потом появится интерпретация.
делать автотесты в jmeter ну наверное норм именно для рест апи)
источник

A

Alex in QA — Load & Performance
>делать автотесты в jmeter ну наверное норм именно для рест апи)

и страдать с гитом, кодогеном и тп)
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Автотесты rest-api в JMeter можно сделать, но простые только
Ведь JMeter сложно отлаживать, тут просто писать, но сложно отлаживать
если не делать сложных конструкций, которые придется отлаживать, то JMeter - ок
А лучше на языке программирования делать тесты с JUnit и все такое

Классы JUnit4 можно переиспользовать (с ограничениями) в JMeter для запуска тестов нагрузки. Ограничения: все кроме секций SetUp, TearDown теста запустится.
источник

A

Alex in QA — Load & Performance
Вопрос только зачем, можно и на генераторах трафика делать, если оочень постараться)
источник

VK

Valeriy Khudasov in QA — Load & Performance
Промежуточные транзакции, в которых нужно включать таймер обычно такие, так-то:
WAIT document sign complete (TC)
а внутри цикл ожидания подписания документа или другой цикл
тут каждый конкретный web-запрос будет быстрым, а вот делать их с паузой в 1 сек в течение 42-х секунд и знать, что это заняло именно 42 сек важно -
делать их с паузой в 1 сек в течение 42-х секунд и знать, что это заняло именно 42 сек важно -  а вот тут можно чуть подробнее? Ожидание разве не просто таймером выставляется? Или я не то/не так понял?) Что за цикл ожидания и почему это важно?
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Я не сразу понял, что вопрос про автотесты. В автотестах может быть и нет разницы как долго шел ответ. А в тестах производительности очень важно
источник

VK

Valeriy Khudasov in QA — Load & Performance
У меня вопрос два в одном) Если вкратце, то изначально пока пишу авто-тесты по сценариям, а потом нужно будет эти наработки использовать в тестах производительности, поэтому приходится делать универсальный проект, чтоб и тесты rest-api гонять можно было, и, в случае чего, сразу за производительность взяться с этими наработками. Либо я сейчас мартышкиным трудом занимаюсь... но задача на данный момент такая :D
источник

A

Alex in QA — Load & Performance
У апи тестов и нагрузочных разные цели, не то что бы там было что то рокетсайнс что бы переиспользовать. Если у вас протоколы не кастомные\редкие
источник

VK

Vitaliy Kudryashov in QA — Load & Performance
мне видится вариант такой:
1. общие методы описывающие ресты
2. автотесты с логикой и проверками
3. нагрузка с профилем
jmeter - тут не лучший кандидат на мой взгляд. лучше что-то code-base
источник

A

Alex in QA — Load & Performance
Можно конечно обложится абстракциями и получить FizzBuzzEnterpriseEdition, но лучше не надо)
источник

VK

Valeriy Khudasov in QA — Load & Performance
Тааааак, у меня начинает прорисовываться картина правильной работы)
1) Лучше не продолжать писать недотесты в JMeter и вкуривать JUnit, а для тестов UI еще и Selenium
2) Под нагрузочное тестирование нужно делать отдельные проекты не по сценариям тестирования и именно по поведению пользователей, и собрать нормальные требования что и как будет тестироваться.
Мысль правильно понял?)
источник

A

Alex in QA — Load & Performance
ага, не обязательно JUnit, можно любой удобный фреймворк, хоть в постмане
источник

KY

Kirill Yurkov in QA — Load & Performance
да, примерно так
источник

OC

Oleg Chaplashkin in QA — Load & Performance
Могу посоветовать на начальных этапах нагрузочного(или любого другого перфоманс тестирования) не сильно бежать к результатам и анализу, так как в этом важно заложить "базу/фундамент", а именно: корректно проанализировать поведения пользователей, свойства системы, инфраструктуру, все это задокументировать, аккуратно снять первичные метрики и выполнить анализ.

По моему опыту, если быстро бежать без этих этапов - результаты будут с последующими вопросами "так, хорошо, а из-за чего? а это релевантно? а почему тут балансировщика нет, а у нас он есть?" и так далее
источник

VK

Valeriy Khudasov in QA — Load & Performance
без этих этапов - результаты будут с последующими вопросами "так, хорошо, а из-за чего? а это релевантно? а почему тут балансировщика нет, а у нас он есть?" - жиза то какая))
источник

VK

Valeriy Khudasov in QA — Load & Performance
Всем большое спасибо) Буду теперь перепланировать свой рабочий процесс)
источник

S7

Sam 7 in QA — Load & Performance
Всем привет. Есть проблема с консьюмером для Кафки. Failed to load ssl keystone of type jks. IO Exception invalid keystore format
источник

I

I-1 in QA — Load & Performance
Что говорит первая строчка
Caused by:
В стектрейсе в логе?
источник