>данные из стрелялки проходят полный цикл как и данные реальных клиентов
Нет, это бред. Данные запросов, которые она шлет в сервис - вероятно.

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

Если он отслеживает бизнес-кейсы клиентской нагрузки - то когда мы подаём на систему нагрузку во время тестов, данные автоматом в datadog попадают тоже, так как для системы нагрузочные тесты должны быть идентичны обычным клиентским операциям

Я верно понимаю?
(См.предыдущий коммент)

Про датадог ты спрашиваешь не того человека :) я про него что-то слышал, но на уровне "еще одна система для мониторинга". Данные о том как нагрузка проходила через систему в нем должны быть, а вот данные из самого генератора нагрузки скорее нет и не появятся если каким-то образом туда не загрузить. Ну и дальше вопрос как они решают вопрос с провязкой таких данные между собой (например, чтобы сравнить что метрики соответствуют и генератор нагрузки видит те же результаты, что система мониторинга)

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

по твоему вопросу стало интересно, я полез смотреть, что там у k6 есть/нет на этот счет и нашел такое - https://github.com/k6io/xk6-distributed-tracing
выглядит неплохо, идет как плагин. но он на стадии proof of concept

У вас разрабы в тестируемый объект трассировку добавили?

Если да - любой фреймворк с трассировкой работает. Если нет - не поможет никакой, ни ваш, ни любой другой.

this

Ну, в тех местах где оно гуляет по сети можно воспользоваться подходом istio - умные прокси между приложениями, которые умеют снимать метрики сами. Правда какая-то кооперация от сервиса для сопоставления запроса на входе и порождаемых им все равно нужна.

Но вообще я говорил не про сквозные трассировки (хотя это интересно - увидеть сразу и где генератор нагрузки тормозил), а про именно данные, которые он сам считает - распределение по типам, тайминги, ошибки и т.п.

Всем привет!
Есть тут кто-нибудь, кто использует вот такое: https://github.com/nickboucart/realbrowserlocusts ?

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

тоже самое и Selenium плагин для Jmeter...

Есть концепция через такую штуку параллельно с нагрузочным тестом запускать смоук функциональный и смотреть что отваливается. А то бывают любители отдавать 200 с ошибкой в теле, а ассертами все обкладывать сложно. Вживую никогда не видел, но идея звучит интересно.

По крайней мере звучит интересненько, прогонять e2e сценарий во время нагрузки на бекенд) А так использовать его как основной инструмент для нагрузки бекенда будет дороговато с точки зрения ресурсов) А до 10 параллельных пользователей нужно будет попробовать...
А для гатлинга нет таких плагинов)?

Добрый вечер господа. Подскажите по jmeter пожалуйста, гуглил но не нашел к сожалению. В тесте есть Save response to a file и есть после него jsr233 Assertion который проверяет что файл загрузился. А вопрос в том что асерт проверяет быстрее чем успеет загрузится файл, не могу понять как приостановить проверку пока файл не загрузится. Кто то может подсказать

Есть какие-то лучше практики по проведению dev lt с встраиванием трубу devops?
Интересуют не инструменты, а методология

А что там встраивать если "ещё идёт разработка"? )
Из советов - иметь всегда возможность раскатать приклад / конфиги из эталонной ветки прода, ибо разрабы в порыве страсти любят накидать 100 изменений в секунду и разломать стенд. Ну и конечно не бросать контрольный регресс либо на этом же стенде либо на следующем (stage обычно).
Ну и + лучше сделать "кнопку" запускающую макс нагрузку на тестируемый компонент,  хай играются
И ++ стендапы на 15мин каждое утро чтобы хоть немного определять план тюнинга для команды на день

Приветствую. Подскажите по такому вопросу:

JMeter сценарий выполняет три группы операций под разными ролями пользователей
- 1 Группа юзеров создает документы и передает на подпись Группе 2
- Группа 2 отправляет документы на согласование Группе 3
- Группа 3 подписывает полученные документы
- Действия должны идти последовательно: Юзер1 создал -> Юзер2 согласовал -> Юзер3 подписал

Исходя из этого все действия были помещены в один тред с логином под новым юзером после каждого действия:
- Логин Юзер 1
 - создание документов
- Логин Юзер 2
 - согласование документов
- Логин Юзер 3
 - подпись документов
 
 
Проблема в том, что на эти логины тратится много времени и это приводит к нестабильному поведению приложения. Разделить на 3 треда нельзя, так как действия не будут последовательными. Была идея авторизовать сразу всех юзеров, но непонятно как подкладыать куки нужного юзера для конкретной операции, если куки менеджер хранит только одну последнюю куки

Кажется, что есть простой способ, а его не могу найти

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