Сервис выдаёт правильные результаты при малом числе пользователей, но время отклика резко растёт при ожидаемом увеличении нагрузки. Какой вид тестирования выявит эту проблему?
Это нагрузочное тестирование — разновидность нефункционального тестирования производительности. Оно проверяет, сохраняет ли система приемлемое время отклика и пропускную способность при ожидаемом количестве одновременных пользователей или запросов.
Проблема не в функциональной корректности результата, а в характеристиках работы системы под нагрузкой.
Функциональные проверки показывают, правильно ли система обрабатывает отдельный сценарий. Однако по мере роста числа пользователей системы начали сталкиваться с ограничениями процессора, памяти, базы данных, сети и внешних сервисов.
Поэтому проверки производительности выделились как отдельное направление: корректный результат сам по себе не гарантирует, что пользователь получит его за приемлемое время или что система выдержит требуемое количество запросов.
При малой нагрузке дефицит ресурсов может быть незаметен: запросы быстро обслуживаются, очереди почти отсутствуют, а соединений с базой данных достаточно. При росте параллелизма ресурсы начинают конкурировать, увеличиваются очереди, задержки и вероятность тайм-аутов.
Если такую проверку не выполнить, система может пройти весь функциональный набор тестов, но стать непригодной для эксплуатации в часы пик. Последствиями могут быть медленный интерфейс, ошибки из-за тайм-аутов, повторные запросы клиентов и каскадное увеличение нагрузки.
Нужно сформировать реалистичный профиль нагрузки: количество виртуальных пользователей, частоту запросов, распределение операций и продолжительность теста. Затем измеряют не только успешность ответов, но и время отклика, пропускную способность, долю ошибок, использование ресурсов и поведение зависимостей.
Для описанного сценария применяют именно нагрузочное тестирование: нагрузка соответствует ожидаемым рабочим условиям или постепенно приближается к ним. Если же систему намеренно выводят за пределы ожидаемой нагрузки, чтобы найти точку отказа и проверить восстановление, это уже стресс-тестирование.
Важны критерии приемки, заданные заранее: например, допустимый процент ошибок, максимальное время отклика для критичных операций и минимальная пропускная способность. Без таких критериев тест превращается в сбор показателей без однозначного вывода.
Среднее время отклика недостаточно: небольшая доля очень медленных запросов может оставаться незаметной для среднего значения. Поэтому анализируют распределение задержек, включая высокие процентили, например девяносто пятый или девяносто девятый, если они определены требованиями.
Результат теста нужно интерпретировать вместе с телеметрией. Рост задержки при исчерпании пула соединений с базой данных указывает на один класс ограничений, а насыщение процессора или внешнего сервиса — на другой. Само по себе ухудшение показателя ещё не доказывает, какой компонент является причиной.
Интернет-магазин корректно оформляет заказ при десяти одновременных пользователях, но во время рекламной кампании ожидается несколько сотен. Команда рассматривает три варианта: ограничиться функциональными тестами, сразу выполнить стресс-тест или провести нагрузочное тестирование по прогнозируемому профилю.
Функциональные тесты не показывают поведение системы при конкуренции за ресурсы. Стресс-тест способен найти предел отказа, но не отвечает напрямую на вопрос, выдерживает ли система штатную пиковую нагрузку, и может создать риск для общей тестовой среды.
Выбирают нагрузочное тестирование с постепенным увеличением числа пользователей до ожидаемого пика и контролем времени отклика, ошибок, базы данных и внешних зависимостей. После обнаружения задержек на операциях оформления выясняется, что узким местом стал ограниченный пул соединений с базой данных. Его настройка и повторная проверка позволяют подтвердить достижение целевых показателей; отдельный стресс-тест затем используется для поиска предельной ёмкости.
Нагрузочное тестирование проверяет работу системы в ожидаемом или целевом диапазоне нагрузки. Стресс-тестирование намеренно превышает этот диапазон, чтобы определить поведение при перегрузке, точку деградации, способ отказа и возможность восстановления.
Эти виды нельзя полностью заменить друг другом: успешный стресс-тест не доказывает выполнение требований к штатному времени отклика, а успешный нагрузочный тест не показывает, как система ведёт себя за пределами расчётной ёмкости.
Среднее значение скрывает неравномерность распределения. Например, большинство запросов может завершаться быстро, тогда как небольшая доля запросов будет зависать из-за блокировок, очередей или медленных зависимостей.
Поэтому анализируют процентили и долю ошибок, связывая их с пользовательскими требованиями. Высокий девяносто девятый процентиль показывает, насколько медленными могут быть самые проблемные запросы, но выбор конкретного порога должен определяться требованиями системы, а не универсальным правилом.
Нужно сопоставить ухудшение пользовательских показателей с метриками компонентов: загрузкой процессора, памятью, сборками мусора, длиной очередей, пулом соединений, временем выполнения запросов к базе данных, сетевыми задержками и ответами внешних сервисов.
Одного совпадения по времени недостаточно: несколько компонентов могут перегружаться вследствие одной первичной причины. Надёжнее повторить тест с контролируемым изменением одного фактора, проверить трассировки и убедиться, что измерительная среда сама не стала ограничением.