Load, stress, spike, endurance и volume testing помогают исследовать разные причины ухудшения производительности. Во всех случаях можно использовать похожие пользовательские сценарии, но меняется вопрос эксперимента: нормальная нагрузка, повышенная интенсивность, резкий переход, длительное выполнение или большой объём данных.
Названия и границы терминов различаются между инструментами и командами. Поэтому в плане важно записывать конкретный профиль, длительность, данные и критерии. Формулировка «провели стресс-тест» без этих условий почти ничего не говорит о готовности системы.
Load testing: ожидаемые условия работы
Нагрузочное тестирование проверяет качество при согласованном обычном или пиковом профиле. Например, поиск получает 100 запросов в секунду, а оформление заказа — 10. Команда ожидает, что каждый маршрут сохраняет своё время ответа и корректность.
Нужно реалистичное сочетание чтения и записи, популярные и редкие объекты, разные размеры ответов. Изолированный быстрый endpoint не заменяет маршрут покупки. Успешный исход — соблюдение критериев в стабильном окне при фактически достигнутой нагрузке; число виртуальных пользователей само по себе этим критерием не является.
Stress testing: повышенная нагрузка и границы
Stress testing исследует поведение при нагрузке выше обычной и помогает увидеть деградацию. Например, после проверки 100 RPS команда повышает интенсивность ступенями до 150, 200 и 250 RPS. На каждой ступени наблюдают полезную пропускную способность, ошибки, очереди и восстановление.
Не любой stress-тест обязан доводить систему до полного отказа. Если задача — найти точку нарушения SLO или предел ёмкости, это нужно явно указать вместе с условиями остановки. В инструментах поиск предела может выделяться отдельно как breakpoint testing. Важен конкретный результат эксперимента, а не универсальная трактовка названия.
Spike testing: резкий скачок
Spike testing проверяет резкое изменение нагрузки: например, переход с 20 до 300 запросов в секунду за несколько секунд. Такой профиль помогает оценить поведение при начале продажи билетов или массовом переходе из уведомления.
Наблюдай не только максимум ошибок. Измеряй время реакции масштабирования, размер накопившейся очереди, долю отвергнутых запросов и время восстановления. После всплеска система может продолжать обрабатывать старые задания и оставаться медленной при уже нормальном потоке. Нужна также проверка целостности: подтверждённая бронь не должна исчезнуть, а повтор не должен создавать вторую оплату.
Endurance и soak testing: накопление во времени
Endurance, часто называемый soak testing, проверяет продолжительную работу под выбранной нагрузкой. Цель — увидеть эффекты, которых нет в коротком прогоне: утечки ресурсов, рост очередей, накопление временных файлов и влияние периодических задач.
Длительность выбирай по предполагаемому механизму отказа. Двухчасовой тест может не пересечь ночную очистку, суточное обновление токена или ротацию логов. Сравнивай не только начало и конец: важны тренды и моменты скачков. Рост памяти сам по себе не доказывает утечку; проверь поведение сборки мусора, кэша и возврат ресурса после завершения нагрузки.
Volume testing: масштаб данных
Volume testing исследует влияние количества и структуры данных. База с миллионом заказов может изменить план запроса, время построения отчёта и размер индекса даже при прежних 20 RPS. Объём может относиться также к файлам, истории сообщений или содержимому очереди.
Подготовь данные с реалистичной связностью и распределением. Миллион одинаковых строк не отражает десять лет истории с крупными клиентами и разной селективностью фильтров. Проверяй правильность пагинации, итоговые суммы, таймауты и отсутствие усечения результата. Большой объём и высокая интенсивность — отдельные переменные, которые полезно исследовать сначала раздельно.
Как выбрать нужный тип
Привяжи эксперимент к риску изменения. Новый кэш требует проверки прогрева, инвалидирования и длительного использования. Изменение индекса — исследования на реалистичном объёме. Новая рекламная кампания — ожидаемого профиля и резкого входящего потока. Изменение ограничителей — поведения под перегрузкой и восстановления.
Необязательно каждый релиз запускать все виды. Сначала докажи корректность сценария при минимальной нагрузке и проверь ожидаемые условия. Если ошибки появляются уже там, сложный многочасовой эксперимент редко поможет быстрее локализовать причину.
Практический пример: сервис бронирования
Допустим, согласованный пик — 50 начатых поисков в секунду, а ожидаемый объём базы — два миллиона активных и архивных записей. Команда выбирает четыре независимых исследования с одной версией сценария.
- →Load: 50 поисков в секунду в течение 30 минут; p95 меньше 700 мс, ошибок меньше 1%, результаты корректны.
- →Spike: резкий рост до 200 поисков в секунду и возврат к 50; согласованный критерий восстановления — не дольше двух минут после снижения.
- →Endurance: шесть часов при 50 поисках в секунду; очередь не растёт без ограничения, критерии сохраняются по временным окнам.
- →Volume: одинаковый профиль на двух наборах данных, включая реалистичные два миллиона записей; отдельно сравниваются планы запросов, полнота результатов и latency.
Это учебные параметры, а не готовый норматив. Для stress-исследования команда отдельно задаёт ступени, допустимый ущерб стенду и стоп-условия. Все операции выполняются на согласованном окружении с тестовыми бронированиями.
Что делает сравнение честным
Тип теста не определяет автоматически модель поступления запросов. Для каждого профиля выбирай открытую или закрытую модель осознанно, сохраняй состав сценариев и измеряй фактическую интенсивность. Если генератор не успевает создавать задания, это отдельное ограничение эксперимента.
Разделяй прогрев, рабочее окно, снижение нагрузки и восстановление. До следующего прогона проверь остаточные очереди и состояние данных. Иначе второй тест начнётся с накопленных эффектов первого, а результаты окажутся несопоставимыми.
Что должен вынести QA из этой темы
Разные типы performance testing исследуют разные оси риска: интенсивность, скорость изменения, длительность и объём данных. Выбирай тип через гипотезу, а профиль описывай числами и условиями. Полезный отчёт показывает корректную работу, границы деградации и восстановление системы, включая то, что осталось за пределами проверки.