Виды тестирования производительности: Load, Stress, Spike, Soak, Chaos и их отличия

Вступление

Когда говорят про тестирование производительности, чаще всего имеют в виду одно — нагрузочное тестирование. Иногда этим же словом называют вообще всё подряд: стресс, хаос, масштабирование — всё смешивается в одну категорию.

В результате появляются типичные ситуации: запустили «нагрузку», получили какие-то графики — и вроде бы всё. Но на самом деле проверили совсем не то, что хотели.

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

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

1. Load Testing (нагрузочное тестирование)

Это тот самый тип тестирования, который чаще всего имеют в виду, когда говорят «давайте прогоним нагрузку».

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

Представьте, у вас есть сервис, и вы знаете, что в пике у вас будет, например, 300–500 одновременных пользователей. Вопрос — выдержит ли система эту нагрузку стабильно? Не начнёт ли расти время отклика? Не появятся ли ошибки? Именно на этот вопрос отвечает load testing.

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

По сути, вы пытаетесь воспроизвести продакшен до того, как туда попадут реальные пользователи.

В процессе такого теста обычно смотрят на базовые метрики: время отклика (response time), пропускную способность (RPS / throughput), количество ошибок и утилизацию ресурсов — CPU, память, сеть.

И вот здесь важный момент: load testing — это не про «сломать систему». Это про то, чтобы убедиться, что она работает нормально в штатных условиях.

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

Если при ожидаемых 300 пользователях у вас:

• растёт P95,
• появляются ошибки,
• CPU уходит в 100%,

это сигнал, что в продакшене будут проблемы.

Типичная ошибка

Очень часто load testing путают со стресс-тестированием. Добавляют «побольше пользователей», система начинает падать — и делают вывод: «она не выдерживает нагрузку».

Хотя на самом деле проверяли уже совсем другой сценарий — за пределами нормы.

Load testing — это всегда про реалистичную нагрузку и стабильную работу, а не про поиск точки отказа.

2. Stress Testing (стресс-тестирование)

Если load testing отвечает на вопрос «выдержит ли система нормальную нагрузку», то stress testing — это уже про другое: а что будет, если нагрузка станет ненормальной?

Представьте, вы уже знаете, что система стабильно держит 300 пользователей. Дальше возникает логичный вопрос: а где её предел? 500? 1000? 5000? И главное — что произойдёт, когда мы этот предел перейдём. Именно это и проверяет stress testing.

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

Дальше начинается самое интересное.

• растёт latency
• увеличивается error rate
• начинают «сыпаться» отдельные компоненты

И ваша задача — не просто зафиксировать факт деградации, а понять: где именно система ломается и как она себя ведёт после этого

Например:

• сначала упирается база данных
• потом забивается connection pool / очереди
• затем начинают падать сервисы

Или наоборот — система деградирует плавно, но не падает полностью.

Отдельно важно смотреть, восстанавливается ли система после перегрузки. Если после пика она сама возвращается в нормальное состояние — это один сценарий. Если остаётся «в поломанном виде» — уже совсем другой.

Когда это нужно

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

Например:

• перед крупной распродажей или маркетинговой кампанией
• при оценке масштабируемости
• когда нужно понять, сколько трафика система выдержит «в теории»

Это не про стабильную работу — это про поведение системы на грани и за её пределами.

Важный нюанс

Такой тест почти всегда приводит к деградации или сбоям. Поэтому его не проводят в продакшене (или делают это очень аккуратно). И очень важно в процессе отслеживать, какой компонент ломается первым — именно там чаще всего находится узкое место.

Типичная ошибка

Самая частая ошибка — выдать stress testing за load testing. Добавляют нагрузку выше нормы, система начинает падать — и делают вывод: «система не выдерживает нагрузку». Хотя на самом деле она не выдерживает неожиданно высокую нагрузку, а не ту, для которой была спроектирована.

Это разные выводы — и разные инженерные решения.

3. Soak Testing / Endurance Testing (тестирование выносливости)

Иногда система отлично проходит обычный load testing: время отклика в норме, ошибок почти нет, ресурсы не упираются в потолок. Кажется, всё хорошо. А потом проходит 6–8 часов — и начинается совсем другая история: память медленно ползёт вверх, соединения не возвращаются в пул, latency становится хуже, а ночью сервис внезапно «плывёт».

Именно для таких случаев существует soak testing, или endurance testing. Его задача — проверить, как система ведёт себя не просто под нагрузкой, а под нагрузкой долго.

Важна не пиковая интенсивность, а продолжительность. Часто нагрузка здесь может быть вполне обычной, на уровне классического load testing. Но тест идёт не 10–15 минут, а часы, а иногда и сутки. И вот именно на длинной дистанции начинают проявляться проблемы, которые короткий тест просто не успевает показать.

Типичные примеры:

• медленная утечка памяти
• утечка соединений
• накопление объектов / лага в очередях
• деградация кешей
• ухудшение времени отклика из-за работы сборщика мусора или фоновых процессов

То есть система не «падает сразу». Она постепенно теряет форму.

И в этом главный смысл soak testing: поймать накопительный эффект, который не виден на коротких прогонах.

Когда это особенно полезно

Такой тип тестирования особенно важен для систем, которые работают долго и без перезапуска: банкинг, телеком, backend-сервисы, очереди, интеграционные платформы. Там недостаточно знать, что система держит нагрузку 15 минут. Нужно понимать, выдержит ли она тот же профиль 12 часов, сутки или дольше.

Отдельно soak testing очень полезен после изменений, которые могут повлиять на долгоживущие процессы: кеширование, connection pool, сборка мусора, фоновые джобы, работа с файловыми дескрипторами.

Типичная ошибка

Очень частая ошибка — ограничиться коротким load testing и решить, что этого достаточно. Но короткий тест отвечает на вопрос: «система работает сейчас?»

А soak testing отвечает на другой, не менее важный: «система не развалится через несколько часов такой же работы?»

И во многих реальных системах именно второй вопрос оказывается важнее первого.

4. Spike Testing (тестирование всплесков)

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

Например, о вас внезапно написал крупный канал. Или стартовала распродажа / черная пятница. Или мобильное приложение после обновления начало бесконтрольно слать запросы. Или в систему влетело сразу несколько тысяч пользователей почти одновременно.

Вот такие сценарии и проверяет spike testing. Его задача — понять, как система реагирует не на просто большую нагрузку, а на резкий кратковременный всплеск.

В этом и есть главное отличие от stress testing. В stress testing нагрузку обычно наращивают постепенно или хотя бы управляемо: система шаг за шагом приближается к пределу. В spike testing всё происходит резко. Условно: секунду назад было 200 RPS, а в следующую — уже 3000.

И вопрос здесь не только в том, выдержит ли система сам пик. Не менее важно, что будет сразу после него.

• успеет ли сработать автоскейлинг
• спасёт ли кеш
• начнут ли отваливаться зависимости
• вернётся ли система в норму после всплеска
• не будет ли копиться лаг на очередях

То есть spike testing — это всегда про две вещи: как система переживает удар и как быстро после него приходит в себя.

Где это реально нужно

Такой тест полезен в сценариях, где нагрузка может расти не плавно, а скачком. Классические примеры:

• распродажи и маркетинговые кампании
• флешмобы и вирусный трафик
• баги в клиентском ПО, когда приложение внезапно начинает слать слишком много запросов
• проверка реакции на DDoS-подобное поведение
• валидация автоскейлинга, прогрева кешей и устойчивости балансировщиков

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

На что обычно смотрят

В spike testing важно смотреть не только на latency и error rate в момент пика, но и на поведение системы после него.

Например:

• сколько времени занимает восстановление
• остаются ли сервисы в деградированном состоянии
• не продолжают ли копиться ошибки даже после снижения трафика
• не ломается ли автоскейлинг из-за слишком резкого роста

Пик может длиться всего минуту. А последствия — тянуться ещё полчаса.

Типичная ошибка

Очень частая ошибка — считать spike testing разновидностью обычного stress testing. Но вопрос тут другой.

Stress testing отвечает: «где предел системы?»
Spike testing отвечает: «что будет, если по системе ударят резко и внезапно?»

И в распределённых системах это часто два совершенно разных сценария.

5. Scalability Testing (тестирование масштабируемости)

Рано или поздно в любой системе возникает вопрос: а что делать, когда текущих ресурсов перестанет хватать? Добавить ещё CPU? Поднять память? Или просто накинуть ещё один инстанс? И главное — даст ли это вообще эффект?

Scalability testing как раз про это. Его задача — проверить, как система ведёт себя при увеличении ресурсов и нагрузки, и насколько эффективно она умеет масштабироваться.

Представим простой сценарий. У вас есть сервис, который держит 100 RPS. Вы добавляете ещё один инстанс — логично ожидать, что станет 200 RPS. Но на практике может получиться так:

• стало 160 RPS → значит, есть накладные расходы
• осталось 110 RPS → значит, узкое место не там
• стало 250 RPS → значит, система масштабируется хорошо

И вот это поведение и есть предмет scalability testing. Здесь важно не просто «нагрузить систему», а сравнить, как она ведёт себя при разных конфигурациях:

• больше CPU
• больше памяти
• больше инстансов
• больше данных

И посмотреть, как меняются ключевые метрики: RPS, latency, error rate.

Отдельный момент — тип масштабирования.

Иногда проще «вертикально» увеличить ресурсы одного сервера: добавить CPU или память.
Иногда — «горизонтально»: поднять ещё несколько инстансов и распределить нагрузку.

Scalability testing помогает понять, какой подход эффективнее именно для вашей системы. Потому что очень часто бывает так: ресурсы добавили — а система почти не ускорилась. И это прямой сигнал, что узкое место в архитектуре: база данных, синхронные вызовы, блокировки, внешние зависимости.

Где это особенно важно

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

Например:

• микросервисная архитектура
• Kubernetes / автоскейлинг
• системы с переменным трафиком

Именно здесь важно понимать не просто «выдерживает ли система нагрузку», а
как она будет вести себя при росте этой нагрузки.

Типичная ошибка

Самая частая ошибка — думать, что масштабирование всегда даёт линейный эффект. Добавили в 2 раза больше ресурсов → ожидают в 2 раза больше производительности. На практике это почти никогда не так. Если система масштабируется сублинейно — это нормально. Если не масштабируется вообще — это уже проблема.

И задача scalability testing — как раз это выявить до того, как вы начнёте «заливать проблему железом».

6. Failover / Resilience Testing (тестирование отказоустойчивости)

Рано или поздно в любой системе что-то ломается. Падает база или даже целый дата-центр / регион. Отваливается сервис. Пропадает сеть. Или просто зависает внешний API. И вот главный вопрос — не «сломается ли система», а что будет дальше?

Failover / resilience testing как раз про это. Его задача — проверить, как система переживает сбои и умеет ли восстанавливаться.

Представьте ситуацию. У вас есть сервис, который зависит от базы данных. В какой-то момент база становится недоступной.

Что происходит дальше?

• всё падает с ошибками
• часть функционала продолжает работать
• система деградирует, но остаётся доступной
• через время всё автоматически восстанавливается

Именно это и проверяется в таких тестах. Здесь важно не просто «выключить что-то», а имитировать реальные сценарии сбоев:

• отключение узла
• падение базы данных
• network partition
• проблемы с диском
• недоступность внешнего API

И дальше смотреть, как система себя ведёт:

• переключается ли на резерв или другой регион
• срабатывает ли репликация
• корректно ли работает retry
• не возникает ли каскадных сбоев

То есть мы проверяем не производительность, а устойчивость системы к поломкам.

Где это критично

Такие тесты нужны везде, где система должна работать даже при частичных отказах:

• микросервисные архитектуры
• распределённые системы
• банковские и платёжные системы
• любые high-load системы с зависимостями

Если у вас есть внешние сервисы, базы, очереди — у вас уже есть точки отказа. И вопрос не в том, «будет ли сбой», а в том, насколько болезненным он окажется.

Circuit Breaker — простой пример на практике

Один из ключевых механизмов устойчивости — это circuit breaker.

Представьте, у вас есть сервис A, который ходит в сервис B. И сервис B начинает отвечать с ошибками или сильно тормозить.

Без защиты произойдёт следующее:

• A продолжает слать запросы
• B не справляется
• очередь растёт
• ресурсы заканчиваются
• начинает деградировать уже A

И дальше это может «потянуть» всю систему.

Circuit breaker решает эту проблему довольно просто. Если система видит, что зависимость работает нестабильно, она перестаёт слать в неё запросы на какое-то время.

Вместо этого:

• сразу отдаёт ошибку
• или использует fallback
• или возвращает кэш

По сути, это предохранитель. У него есть три состояния, но их проще понимать не как формальные термины, а как поведение:

• всё работает нормально → запросы идут как обычно
• слишком много ошибок → система «закрывает кран» и временно не ходит в зависимость
• проверка восстановления → время от времени пробует отправить несколько запросов

Если зависимость «ожила» — всё возвращается в норму. Если нет — снова закрываем.

Зачем это нужно:

• чтобы не перегружать уже падающий сервис
• чтобы не словить каскадный сбой
• чтобы система могла деградировать контролируемо, а не падать полностью

Типичная ошибка

Самая частая ошибка — думать, что отказоустойчивость «сама появится», если есть репликация или несколько инстансов.

Но без явной проверки система часто ведёт себя неожиданно:

• не переключается на резерв
• зацикливается в retry
• начинает «убивать» зависимость ещё сильнее
• или просто падает целиком

Failover testing как раз и нужен, чтобы такие вещи находить заранее.

7. Chaos Testing (хаос-тестирование)

До этого момента мы проверяли систему в контролируемых условиях:

• задавали нагрузку
• постепенно её увеличивали
• моделировали сбои

Но всегда оставались в рамках сценария.

Chaos testing идёт дальше. Его идея проста и немного пугающая: система должна быть готова к сбоям, о которых мы даже не подумали. И единственный способ это проверить — начать ломать её намеренно.

Представьте:

• случайный сервис внезапно падает
• часть сети становится недоступной
• один из узлов начинает отдавать некорректные данные
• зависимость отвечает с задержками

И всё это происходит не в тестовом стенде, а в живой системе. Звучит опасно — так и есть. Но именно так проверяется реальная устойчивость. Chaos testing — это не про один конкретный сценарий. Это про создание контролируемой неопределённости.

Вы намеренно вносите нестабильность и смотрите:

• деградирует ли система корректно
• сохраняется ли доступность
• не возникают ли каскадные сбои
• как быстро система восстанавливается

Где это действительно имеет смысл

Chaos testing — это уже не начальный уровень. Он нужен в системах, где:

• есть зрелая инфраструктура
• есть мониторинг и алерты
• есть автоматическое восстановление
• есть понимание, как система должна себя вести при сбоях

Это типичный инструмент для:

• крупных микросервисных систем
• high-load платформ
• критичных сервисов, где простой стоит дорого

Важный нюанс

Очень важно понимать: хаос-тестирование — это не «сломать всё и посмотреть, что будет». Это про контролируемый эксперимент.

Если у вас нет:

• мониторинга
• алертинга
• rollback / recovery механизмов

то chaos testing превращается просто в способ положить систему.

Типичная ошибка

Самая частая ошибка — пытаться внедрить chaos testing слишком рано. Когда ещё нет:

• стабильного load testing
• понимания метрик
• нормальной наблюдаемости

В этом случае хаос не даёт полезной информации, а только добавляет шума. Правильный порядок обычно такой: load → stress → resilience → chaos

Сводная таблица видов тестирования производительности

Вид теста	Что проверяет	Характер нагрузки	Длительность	На что смотрят
Load Testing	Работу системы при ожидаемой нагрузке	Нормальная / ожидаемая	Минуты — часы	Response Time, RPS, ошибки
Stress Testing	Пределы системы и поведение при сбое	Выше нормы	Кратковременная	Точка отказа, деградация, восстановление
Soak Testing	Стабильность во времени	Нормальная	Часы — сутки	Утечки памяти, рост latency
Spike Testing	Реакцию на резкие всплески	Резкие пики	Кратковременная	Пиковое поведение, время восстановления
Scalability Testing	Эффективность масштабирования	Растущая	Любая	RPS, latency при изменении ресурсов
Resilience Testing	Поведение при сбоях	Любая	По сценарию	Ошибки, failover, восстановление
Chaos Testing	Устойчивость к непредсказуемым сбоям	Нестабильная	Любая	Выживаемость, самовосстановление

Заключение

Ошибка в выборе типа тестирования — это не просто неточный результат, а неправильные инженерные выводы. Именно поэтому сначала выбирается цель, и только потом — тип теста.