отличный вопрос, а ответ зависит от необходимости вдаваться в объяснения.
1. ну совсем простой вариант такой. мы имитируем поведение определенного часа или временного промежутка т.к берем оттуда пик. можем посмотреть какой каунтер был по количеству сессий в тот момент или другую метрику юзеров, обратная интерпретация тут может быть в виде диапазон. в тот период присутствовало в системе 1000-1200 юзеров, мы полностью имитировали их действия. система держит 3х нагрузки от продового пика -> значит ТАКИХ или ПОДОБНЫХ юзеров может быть 3000-3600. 5 мин и ты дал ясность человеку который жаждет получить юзеров. но при этом не потерял в точности и реализме для конечных результатов.
2. вариант действительно дать человеку понимание по тому в чем измеряется нагрузка и почему.
3. лично но мы измеряем систему в множителях. держит 2х от пика прода, тебе вообще ни юзеры ни рпсы не нужны для того чтобы это сказать бизнесу и всё он сразу поймет, запас у нас еще столько же, сколько не было и в чем бы он не мерил.

можно так сделать, но это ограничение и допущений о которм я писал раньше и именно это и проблема

Есть  один метод превращения рпсс в пользователей :  надо чётко задать границу автоматизации .. Чем раньше до бизнеса дойдёт, что  прогнозируется с некоторой вероятностью действия пользователя и сценарии НТ пишутся  с оглядкой на это поведение

а тесты в другом подходе пророчат будущее?
если ты подашь ту же нагрузку в два раза быстрее ты проверишь 2х держит ли твоя система в данный момент. когда ты проверяешь её через треды - ты отвечаешь на вопрос а какая твоя система в данный момент. ни о каком будущем речи не идет

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

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

а что такое граница автоматизации?

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

в целом да верно, чем быстрее донести о том что есть эти ограничения тем лучше, но еще лучше от них уходить

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

Вообще не понял при чем тут нагрузка и автоматизация если честно

Подача нагрузки по определенному сценарию - автоматизация  некоторого процесса

Ладно, понятнее не стало первое сообщение.)

тут ты не прав

ну там не важно, ты кладёшь переменную в session и можешь достать её в любом методе этого пользователя

да это я знаю, само собой)

и зачем его задавать в нагрузочном чате, не проще ли задать его в питонячьем чате?

ох ну наконец то какоето нормальное обсуждение вкинули

у меня нет питонячьего чата, по этому обращаюсь туда, где мне смогут помочь. Вот, собственно и помогли

во истину, качественно поупражнялись