Ответ.

Исторически производительность ПО проверялась после основной функциональной части — разработчики либо запускали скрипты вручную, либо собирали показатели инструментариями наподобие JMeter. При массовом переходе к DevOps и CI/CD возникла потребность автоматизировать эти процессы и получать метрики на каждом этапе поставки.

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

Современное решение — внедрение специализированных инструментов (например, Gatling, Locust, k6), создание сценариев с параметризацией профиля пользователей, интеграция тестирования производительности в пайплайны CI, автоматизация накопления и анализа метрик, алерты при ухудшении производительности.

Ключевые особенности:

Корректная настройка сценариев нагрузки (повторяемость и ближе к реальности).
Анализ метрик (разделение бенчмаркинга, стресс-, лонг-интервалов) и автоматизация их сбора.
Оценка влияния результатов тестирования на общее качество поставки и соблюдение SLA.

Вопросы с подвохом.

Верно ли, что автоматизация "нагрузочников" допустима только на продакшене?

Нет. Производительные и стрессовые автотесты можно выполнять на dedicated stage-приложении/стенде, чтобы не нарушать SLA. Автоматизация их, наоборот, предпочтительнее до выхода в прод.

Если автотесты нагрузки проходят, можно ли быть уверенным в реальном user experience?

Нет — автотесты дают лишь усреднённую картину. Поведение реальных пользователей может отличаться из-за сетевых условий, используемых платформ и других факторов, которые сложно эмулировать один-в-один.

Стоит ли ориентироваться только на средние значения времени отклика (response time)?

Нет. Крайне важно учитывать перцентиль (например, 95-й, 99-й), так как средние могут быть смещены выбросами, а именно хвостовые значения чаще всего влияют на UX.

Типовые ошибки и анти-паттерны

Фокус только на простых сценариях "логин/логаут", без эмуляции бизнес-операций.
Игнорирование анализа худших сценариев (tail latency).
Недостаточный анализ зависимостей (например, неотключённые сторонние сервисы и rate limits).

Пример из жизни

Негативный кейс

Компания внедрила автотесты производительности только на вход в систему: скрипты прогоняли 1000 логинов, анализировали средний отклик, посчитали, что проблема решена. При первом реальном запуске были массовые тайм-ауты — выяснилось, что параллельные "тяжёлые" бизнес-операции не учитывались, API падал под нагрузкой.

Плюсы:

Быстрое подтверждение работоспособности банальных сценариев.

Минусы:

Игнорирование важнейших пользовательских цепочек привело к инциденту.
Фальшивое ощущение стабильности.

Позитивный кейс

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