Нагрузочное тестирование системы: сценарии, метрики и отчет

Нагрузочное тестирование проверяет, выдерживает ли система ожидаемый поток пользователей, запросов, задач или интеграционных обменов. Оно должно отвечать не на вопрос «сколько выдержит сервер вообще», а на конкретный рабочий сценарий: какие операции выполняются, с какой частотой, при каких данных и какие метрики считаются приемлемыми.

Хороший тест заканчивается не графиками ради графиков, а отчетом: где запас, где узкое место, что надо исправить до запуска и какие ограничения остаются.

• перед публичным запуском, рекламной кампанией или подключением новых пользователей;
• после изменений архитектуры, базы данных, API, очередей или интеграций;
• когда система уже тормозит, но причина неясна;
• для проверки SLA, времени отклика, пропускной способности и устойчивости;
• перед миграцией на новую инфраструктуру или масштабированием.

• функциональные сценарии еще не работают стабильно;
• нет тестового контура, похожего на production;
• непонятно, какие операции и объемы нужно имитировать;
• результаты теста никто не готов анализировать и превращать в исправления;
• тест хотят провести только ради формального отчета без критериев приемки.

• ключевые пользовательские и интеграционные сценарии;
• профиль нагрузки: пользователи, запросы, пиковые периоды, длительность теста;
• объем и качество тестовых данных;
• метрики: время отклика, ошибки, throughput, CPU, память, база данных, очереди, сеть;
• тестовый контур и ограничения его отличий от production;
• пороговые значения, при которых тест считается успешным или проваленным.

• начать с baseline-теста, чтобы понять нормальное поведение системы;
• проверить рабочий профиль нагрузки, а не только один синтетический endpoint;
• отдельно провести стресс-тест, если нужно понять предел и деградацию;
• собирать метрики приложения, инфраструктуры, базы данных и внешних зависимостей;
• фиксировать не только среднее время, но и процентили, ошибки, таймауты и восстановление после пика.

• тестировать не те сценарии, которые создают реальную нагрузку;
• использовать пустую или слишком маленькую базу данных;
• смотреть только на CPU и забывать про базу, блокировки, очереди и внешние API;
• считать успешным тест с приемлемым средним временем, но плохими p95/p99;
• не отделить дефекты тестового контура от реальных ограничений системы.

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