> For the complete documentation index, see [llms.txt](https://kaze.gitbook.io/qa-theory/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kaze.gitbook.io/qa-theory/teoriya-ruchnogo-testirovaniya/kogda-sleduet-delat-stress-testirovanie-na-proektakh-ot-chego-ottalkivatsya-kogda-stroite-scenarii.md).

# Когда следует делать стресс-тестирование на проектах? От чего отталкиваться, когда строите сценарий

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

**Когда следует делать:**

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

**При построении сценария:**

* Определите нормальные показатели нагрузки (baseline).
* Постепенно увеличивайте нагрузку до выхода за пределы проектных значений.
* Фиксируйте: момент деградации (резкое увеличение задержек), ошибки (HTTP 5xx, timeouts), полное падение.
* Тестируйте и фазу восстановления — как система возвращается после снятия нагрузки.

**Что учесть при выборе инструмента:**

* Протоколы: поддержка нужного (HTTP, WebSocket, gRPC и т. д.).
* Масштабируемость: возможность эмулировать тысячи/миллионы пользователей.
* Метрики: интеграция с мониторингом (CPU, RAM, latency, throughput).
* Простота сценариев: скриптование (Python/JS/Java) или декларативные тесты.
* Распределённый запуск (например, JMeter + master/slave, Locust + workers, k6 в Kubernetes).