Комментарии 1
Сядьте с ручкой и листком и напишите, какие действия чаще всего производит ваш пользователь, какие сущности просматривает, а может, создает. После этого добавьте свой опыт: подумайте, где проект может максимально буксовать.
Я наверное не открою Америки, но для стресс тестов вебприложения, мы берем access логи за 1..2 месяца и на их базе формируем список ресурсов для тулзы, которая обеспечивает нагрузку при стресс тестировании. 2 основных кейса обычно:
1) as is , то есть все дневные логи объединяются в один и все это запускается неким кол-вом потоков в сторону тестового стенда
2) согласно целям теста, логи отфильтровываются по каким-либо правилам, исключаются какие то разделы или например оставляем только те запросы, которые в логах имеют код ответа не равный 200 и т.д.
Варьируя кол-во потоков и случайность задержки между ними, можно имитировать нарастающую нагрузку, постоянную нагрузку, пиковую нагрузку и так далее
Минус - нельзя автоматизировать воспроизведение POST запросов для создания нагрузки максимально приближенной к реальной. Это да. Но это зависит от вебприложения уже.
Хорошие практики нагрузочного тестирования: гайд для тех, кто успел до «пожара»