а что в методике? стресс/вольюм/скалабилити?

Думаю тоже, что и в этой

Есть раздел "4.1.2 План тестирования производительности" в документе
Программа подготовки ISTQB Базовый уровень - Тестирование Производительности (Русский) (1.1 МиБ)
https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CTFL_PT_Syllabus_2018_Russian.pdf

Это методика

Стресс тестирование никогда не приходилось проводить.
И расхожусь во мнениях, что такое стресс-тестирование, с разными источниками.
Слово, кажется, что привычное. Но его трактовки крайне спорные. В том же ISTQB есть своя трактовка

Например, отказоустойчивость применительно к редкому событию: все менеджеры по всей стране «одновременно» перешли по нотификации (7500 в секунду), при типичной нагрузке <3000 ОПЧ. Гриндей сбера, всякое такое.

Гриндей длится в течение дня. Пусть 3-4 часа. А подавать нагрузку 7500 в сек в течение 3-4 часов, это вполне себе нагрузочный тест. Который удобно сделать так:
1 час подавать 2000 в сек, 1 час 4000 в сек, 1 час 6000 в сек, 1 час 8000 в сек. Просто, чтобы знать как оно отказывает

То что команда знает, что такое будет только 1 день и потом железо можно будет вернуть, а аггрессивное кеширование отключить. Не меняет того, что это тест как все тесты

С филосовской точки зрения тест такой же. Технически подать 7000 в сек можно только через local pipe или используя очень много машин

Мне кажется, они «стресс» в том смысле, что такая интенсивность нагрузки выстроена на теоретических предположениях (в реальности у нас 11 часовых зон и такой нагрузки не будет), существенно превышает пик-час в горизонте «навсегда». По сути, это ближе к восстановлению под нагрузкой. Требования онолитегов примерно такие: 2000 в день, 3000 в пик-час, до 7500 «пользователей одновременно).

Работаю с ДБО для юридических лиц, давно уже. Если перейду в ДБО для физических лиц, и там каждый раз будет х10 от привычных нагрузок. То тогда почувствую разницу. А пока пороху не нюхал

Это объёмный вопрос. Например у меня ошибка авторизации иногда выпадает 403, и это ошибка чисто смежной системы -  шлюза. Второй момент - бывает конфликт в авторизациях в части жизни Кук/сессий. На одном узле сессия или Кука живет дольше чем на следующем узле. Надо смотреть как в это в скриптах обрабатываете.

Соответственно я бы в ручную в каждый запрос в хедер впихнул сначала куки по нарастающей

Ещё момент, тест гоняете пробный в vugen используя пул пользователей или на одном, это тоже важно

Декомпозируцие задачку на под задачи. Начните с первого запроса, прогоните его сотню раз с разными пользователями, получите 200 ок, разные куки

Потом ко второму, потом к третему, потом всю цепочку на одном пользователе известном вам, потом на нескольких

Так же параллельно можно использовать апи тестеры аля Insomnia и прочее.

А дальше только в глубь, бывает это из за балансировки, что часто кстати

Так же проверить сервера statless или нет. Это значит есть ли разница на какой сервер попадет пользак с его сессией и куками. Но я думаю проблема в скриптах. Так же запрос может падать во vugen если не полный боди приходит. А боди может и не влезть в параметр, если вы созраняете. Надо или не сохранять или увеличить max size

Во написал, извиняюсь

Ого, прям какой-то ботнет сработал в воскресенье по утру