Что такое нагрузочное тестирование и когда оно обязательно

Нагрузочное тестирование — это проверка того, как система ведёт себя под заданным потоком обращений: сколько пользователей она обслуживает без потери качества, где начинает деградировать и в какой точке падает. Обязательной проверка становится в четырёх случаях: перед вводом системы в эксплуатацию, перед известным пиком спроса, после миграции на другую СУБД или платформу и по требованию регулятора. Для банков это Положение Банка России № 850-П от 13.01.2025: организация обязана установить сигнальное и контрольное значения допустимой доли деградации технологического процесса, опираясь на статистику минимум за 12 календарных месяцев. Требования реализуются с 1 октября 2025 года.

Ключевые факты

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

Что такое нагрузочное тестирование простыми словами: что именно проверяют

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

Определение. Тестирование под нагрузкой — измерение производительности системы (время отклика, пропускная способность, доля ошибок, утилизация ресурсов) при воспроизведении заданного профиля нагрузки на контролируемом стенде.

Определение. Профиль нагрузки — описание того, что подаётся на систему: сколько виртуальных пользователей, какие операции и в каком соотношении, как быстро растёт интенсивность (ramp-up), сколько держится плато и как нагрузка снимается (ramp-down).

ГОСТ Р 56920-2016, идентичный ISO/IEC/IEEE 29119-1:2013, относит такие испытания к нефункциональным. Разница простая: функциональный тест отвечает, что система делает, нагрузочный — насколько хорошо она это делает, когда к ней приходят все сразу.

Чем нагрузочное тестирование отличается от функционального

Зачем это бизнесу: какие вопросы закрывает проверка производительности

Цель нагрузочного тестирования звучит не как «проверить систему». Она сводится к трём вопросам: какой у нас запас, где точка отказа и сколько стоит её отодвинуть.

Связка «задержка → выручка» измерена публично. Отчёт Deloitte, подготовленный по заказу Google, — «Milliseconds Make Millions», 2020 — показал: ускорение загрузки мобильного сайта на 0,1 секунды дало +8,4% к конверсии в ритейле и +9,2% к среднему чеку. В travel конверсия выросла на 10,1%, в lead generation отказы сократились на 8,3%. Оценки прошлого десятилетия того же порядка: Amazon в 2006 году оценил каждые 100 мс задержки в 1% продаж, Google тогда же зафиксировал падение трафика на 20% при добавлении 500 мс к генерации выдачи.

Оговорка обязательна. Проценты Deloitte получены на выборке мобильных сайтов ритейла, travel и lead generation — это порядок эффекта, а не обещание. Сопоставимого исследования по российскому рынку в открытом доступе нет, так что для защиты бюджета честнее опираться на собственный A/B-замер.

Метрики, на языке которых цели формулируются:

• RPS (requests per second) и throughput — запросов в секунду и успешно завершённых операций за интервал;

• latency p50 / p95 / p99 — перцентили времени отклика. «p95 = 500 мс» читается так: 95% запросов уложились в полсекунды, 5% были медленнее. Среднее прячет хвост, а инциденты живут именно в хвосте;

• error rate — доля запросов с ошибкой или таймаутом;

• утилизация ресурсов — CPU, память, ввод-вывод, пул соединений к базе;

• SLA (service level agreement) — попадание метрик в границы договора или внутреннего регламента.

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

Какие бывают виды нагрузочного тестирования и что каждый показывает

Под общим названием живут семь разных испытаний. Каждое закрывает свой вопрос и ловит свой класс дефектов.

Soak-тест ловит то, чего не видно за полчаса. Утечка в 20 МБ в час за сутки съедает гигабайты. Типовое окно прогона — 8–72 часа, и это отраслевая привычка, а не норматив: ни ГОСТ Р 56920-2016, ни Положение № 850-П длительность не устанавливают. Именно soak режут первым, когда сроки горят. Потом получают инцидент на третьи сутки после релиза.

Spike отличается от стрессового формой подачи. Стресс наращивает нагрузку плавно, spike даёт кратный скачок за секунды и бьёт по всему, что имеет инерцию: автоскейлинг, прогрев кэша, установление соединений. Система, спокойно держащая 5 000 RPS в плато, может лечь на скачке до 3 000.

Конфигурационное тестирование стало обязательным пунктом после волны импортозамещения. На другой СУБД приложению нужны другие размеры пулов и другие таймауты, а переносят их обычно как есть — потому что «раньше работало».

Когда нагрузочное тестирование обязательно

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

Когда обязанность возникает по нормативным требованиям

Кредитные организации и НФО. Первое, что стоит проверить в чужой статье или презентации: Положение Банка России № 787-П от 12.01.2022 утратило силу 03.05.2025. Ссылки на него до сих пор кочуют по выдаче. Действует Положение Банка России № 850-П от 13.01.2025 «Об обязательных для кредитных организаций, иностранных банков… требованиях к операционной надёжности…», требования реализуются с 1 октября 2025 года.

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

Государственные информационные системы. Постановление Правительства РФ № 676 от 06.07.2015 (ред. от 18.03.2025) задаёт порядок создания, развития и ввода ГИС в эксплуатацию: предварительные испытания, опытная эксплуатация, приёмочные испытания. Программа и методика испытаний почти всегда включает проверку на заявленном числе одновременных пользователей и целевых объёмах данных.

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

Когда обязанность возникает по инженерной логике

1. Релиз новой системы или крупного модуля. Ни одного замера на реальном трафике ещё не было. Предел лучше узнать самим, чем от пользователей в первый же день.

2. Миграция. Переход на отечественную СУБД, переезд в облако, смена сервера приложений меняют планы выполнения запросов и поведение пулов. Функционально всё работает, по скорости проседает в разы — классика 2023–2025 годов.

3. Плановый пик. Распродажа, приём заявок в ограниченное окно, отчётный период. Нагрузка известна заранее и кратно отличается от обычной, значит, воспроизводима на стенде.

4. Рост трафика в 1,5–2 раза. Линейного запаса у распределённых систем не бывает. Удвоение упирается в блокировки базы раньше, чем в процессор.

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

6. Разбор инцидента. Воспроизвели сценарий отказа, починили узкое место, повторили прогон. Без повторного прогона причина остаётся гипотезой.

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

Методика и этапы: как проверка устроена изнутри

Методика нагрузочного тестирования — документ, а не набор привычек команды. В нём фиксируются цели, критерии успеха, профиль нагрузки, конфигурация стенда, состав метрик и границы прогона. Без документа результат не воспроизвести через полгода и не защитить в споре с заказчиком или проверяющим.

Этапы нагрузочного тестирования укладываются в шесть шагов:

• Сбор нефункциональных требований. Критерий приёмки — число: «p95 ≤ 500 мс при 2 000 RPS, доля ошибок ≤ 0,1%, утилизация CPU ≤ 70%». Формулировка «система работает быстро» к приёмке не принимается.

• Проектирование профиля и сценариев. Операции и их доли, длительность, форма кривой: ramp-up, плато, ramp-down.

• Подготовка стенда и данных. Конфигурация, сопоставимая с промышленной. Генератор нагрузки — на отдельных машинах, иначе меряем сами себя. Объём базы близкий к боевому, мониторинг на всех слоях.

• Baseline-прогон. Замер исходного состояния, с которым сравнивают всё дальнейшее.

• Прогоны и анализ. Поиск узкого места по метрикам приложения, базы, инфраструктуры и APM.

• Отчёт. Метрики, графики, честно зафиксированные ограничения стенда, вывод по критериям приёмки, рекомендации по мощностям.

Как выглядит рабочий сценарий нагрузки

Сценарий нагрузочного тестирования воспроизводит поведение живого пользователя — последовательность шагов с паузами и разными данными. Не долбит один метод API в сто потоков.

Типовое распределение для интернет-магазина:

Между шагами закладывают think time — паузы по 3–10 секунд. Без пауз сотня виртуальных пользователей создаёт нагрузку, которой в реальности соответствуют тысячи человек, и оценка мощностей уезжает в крайность. Данные тоже должны различаться между потоками: один товар на всех потоках даст стопроцентное попадание в кэш и отчёт, которому нельзя верить.

Обобщённый пример — цифры типовые, к конкретному проекту не относятся. Система приёма заявок, цель 1 500 RPS. Baseline: p95 = 1,9 с и 2,3% ошибок уже на 900 RPS. Метрики указали на исчерпание пула соединений к базе и отсутствие индекса по полю фильтрации в самом частом запросе. После правки размера пула и добавления индекса — p95 около 420 мс на целевых 1 500 RPS. Железо здесь не было ни при чём.

Чем тестируют: инструменты и когда какой уместен

Корпоративные задачи закрывают пять генераторов нагрузки. Выбор определяют набор протоколов и то, кто будет поддерживать сценарии — QA-инженеры или разработчики.

Данные приведены по официальной документации; состав протоколов и системные требования меняются от версии к версии, так что перед стартом проекта их перепроверяют.

Инструмент выбирают не первым. Сначала отвечают на два вопроса: какие протоколы и какая интенсивность нужны и кто будет жить с этими сценариями следующие два года. Команде без опыта программирования проще стартовать на JMeter. Если прогоны встраиваются в конвейер сборки — выигрывает k6. Для разовой проверки HTTP API под Linux хватит Яндекс.Танка. Метрики в любом случае выводят во внешний дашборд: связка InfluxDB и Grafana работает со всеми пятью.

Пять ошибок, из-за которых тест не показывает правду

1. Стенд не совпадает с промышленной средой. Половина ядер, другая версия СУБД, нет балансировщика — переносить результат на прод нельзя ни вверх, ни вниз. Полной копии часто не бывает; тогда различия выносят в отчёт отдельным разделом, а не умалчивают.

2. Синтетические данные вместо реального объёма. На таблице в 10 тысяч строк оптимизатор выбирает один план запроса, на 50 миллионах — другой. Пустая база не воспроизводит деградацию индексов, а именно она обычно и убивает систему на проде.

3. Мониторинга нет на стороне системы. Команда смотрит на графики генератора и видит, что стало медленно. Где именно — в приложении, пуле соединений, вводе-выводе или у внешнего сервиса — не видит. Симптом без диагноза.

4. Нагрузка без think time. Поток без пауз создаёт нереалистичную конкуренцию за ресурсы и смещает точку отказа. Причём непредсказуемо, в любую сторону.

5. Нет baseline. Без замера исходного состояния не доказать ни того, что оптимизация сработала, ни того, что новый релиз ничего не сломал.

Что заказчику нужно подготовить до старта

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

• Целевые метрики — число одновременных пользователей, целевой RPS, время отклика по перцентилям, предельная доля ошибок, требования SLA.

• Профиль реальной нагрузки — выгрузка из аналитики или логов: распределение операций, суточные и сезонные пики.

• Критичные бизнес-операции — что нельзя терять: оплата, приём заявки, авторизация.

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

• Доступ к мониторингу и логам — приложение, база данных, инфраструктура, APM.

• Тестовые данные — обезличенный набор, сопоставимый по объёму с промышленным, плюс учётные записи для сценариев.

• Согласованное окно прогона — критично для soak-тестов длительностью больше суток.

• Контакты по эскалации — кто отвечает за стенд, базу и интеграции.

Частые вопросы о нагрузочном тестировании

1. Чем нагрузочное тестирование отличается от стрессового?

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

2. Сколько времени занимает проведение испытаний под нагрузкой?

   Основное время съедает подготовка: сбор нефункциональных требований, стенд, тестовые данные, сценарии. Сами прогоны идут от нескольких часов до нескольких суток — soak-тест по отраслевой практике длится 8–72 часа. Итоговый срок зависит от числа сценариев, готовности среды и количества итераций после исправления узких мест.

3. Можно ли тестировать производительность на продакшене?

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

4. Обязательны ли испытания под нагрузкой по закону?

   Прямой нормы с формулировкой «проводить нагрузочное тестирование» в российском законодательстве нет. Есть требования, которые без таких испытаний не выполнить. Положение Банка России № 850-П от 13.01.2025 (пришло на смену Положению № 787-П, утратившему силу 03.05.2025; реализация требований с 01.10.2025) требует обоснованных значений допустимой доли деградации технологического процесса на основании статистики не менее чем за 12 календарных месяцев. Постановление Правительства РФ № 676 от 06.07.2015 (ред. от 18.03.2025) требует предварительных и приёмочных испытаний государственной информационной системы до ввода в эксплуатацию.

5. Как часто нужно повторять проверку производительности?

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

6. Сколько стоит и от чего зависит цена?

   Фиксированной цены у таких работ нет, публично подтверждённых рыночных диапазонов по РФ — тоже. Смета складывается из числа и сложности сценариев, количества протоколов, необходимости готовить стенд и данные, длительности прогонов и числа итераций. Отдельной строкой идёт анализ узких мест: поиск причины деградации обычно занимает больше времени, чем сам прогон.