Нагрузочное тестирование: что это такое, виды и инструменты

Статья посвящена нагрузочному тестированию программного обеспечения и веб-сервисов. Разберём: что такое НТ простыми словами, какие существуют виды, как выбрать инструмент — Apache JMeter, k6 или Locust, — по каким метрикам оценивать результаты, что требуют стандарты ГОСТ Р 51901 и ISO 25010 и как строится карьерный путь специалиста.

Что такое нагрузочное тестирование

Нагрузочное тестирование относится к классу нефункциональных тестов. Оно не проверяет, правильно ли работают функции, — оно измеряет, как система справляется с нагрузкой при реальных условиях эксплуатации.

Простыми словами: тысяча виртуальных ботов одновременно штурмует сайт — открывают страницы, добавляют товары в корзину, оформляют заказы. Что произойдёт? Страницы начнут тормозить? Сервер упадёт? Сколько запросов завершится ошибкой?

Ключевые понятия:

• Виртуальные пользователи (VU) — независимые симулированные сессии, каждая выполняет заданный сценарий действий. Это не синоним «одновременных реальных пользователей»: реальные делают паузы, читают текст, думают перед кликом.
• Нефункциональные требования — ограничения на время отклика, пропускную способность и допустимый процент ошибок. Фиксируются в SLA или техническом задании.

Нагрузочное тестирование вручную оправдано только до 10 одновременных пользователей — например, когда команда открывает сайт с нескольких устройств и засекает время. При нагрузке от 10+ VU уже нужен инструмент автоматизации: вручную воспроизвести поведение сотен пользователей физически невозможно.

Зачем нужно нагрузочное тестирование: примеры и бизнес-ценность

В Чёрную пятницу интернет-магазин получает в 10–20 раз больше трафика, чем в обычный день. Если нагрузочное тестирование перед пиком не проводилось, вероятен сценарий: серверы не справляются, сайт падает, пользователи уходят к конкурентам — бизнес теряет выручку и репутацию за несколько часов.

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

1. Финансовый риск. Простой крупного онлайн-сервиса стоит миллионы рублей в час.
2. Репутация. Сбой в момент пикового спроса формирует устойчивый негативный пользовательский опыт.
3. Пиковые события. Сезонные распродажи, рекламные кампании, вирусные публикации — всё это создаёт кратковременные всплески трафика.
4. Соответствие SLA. Договор с клиентом фиксирует доступность и время отклика. Нарушение влечёт штрафные санкции.

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

Виды нагрузочного тестирования

Термин «нагрузочное тестирование» нередко используют как обобщающий для целой группы тестов производительности. На практике каждый вид решает свою задачу. Более широкую картину даёт обзор видов тестирования программного обеспечения.

Стресс-тестирование

Стресс-тестирование — намеренная перегрузка системы. Нагрузку поднимают выше ожидаемых значений, пока не будет достигнута точка отказа. Главный вопрос: не «выдержит ли система норму», а «где она сломается и как восстановится».

Стресс-тестирование отличается от нагрузочного одним ключевым атрибутом: оно измеряет время восстановления — сколько секунд нужно системе после снятия перегрузки, чтобы метрики вернулись к норме. Также фиксируют характер отказа: возвращает 503, зависает или деградирует постепенно.

Тестирование на выносливость (soak testing)

Тестирование на выносливость проводится при нормальной нагрузке, но в течение многих часов или суток. Задача — обнаружить проблемы, невидимые за 30 минут: утечки памяти (когда потребление RAM постепенно растёт), деградацию времени отклика из-за накопления незакрытых соединений или нестабильность кэша при длительной работе.

Тестирование масштабируемости и другие виды

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

Смежные виды: тесты объёма (как система справляется с большим объёмом данных в БД), тестирование отказоустойчивости (поведение при падении одного из узлов), тесты потенциальных возможностей (максимальная пропускная способность при идеальных условиях).

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

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

Типичная цепочка обработки запроса выглядит так:

Виртуальные пользователи → Firewall → Балансировщик нагрузки → Веб-серверы → Серверы приложений → База данных

Каждый элемент цепочки может стать узким местом:

• Firewall — ограничивает число одновременных соединений.
• Балансировщик нагрузки — при неправильной настройке направляет трафик неравномерно и перегружает один узел.
• Веб-сервер / сервер приложений — упирается в CPU или RAM.
• База данных — чаще всего здесь кроется корневая причина замедлений: медленные запросы, блокировки, нехватка соединений.

Почему нельзя тестировать в QA-среде? QA: 1 сервер приложений + 1 БД. Производственная среда: 3 сервера приложений + 2 БД + балансировщик. Результаты нагрузочного тестирования в QA будут нерепрезентативными — узкие места окажутся в других компонентах или вовсе скроются.

Для внешних сервисов (платёжный шлюз, SMS-провайдер) используют заглушки (stubs): они возвращают предсказуемые ответы и не нагружают реального поставщика.

Как провести нагрузочное тестирование: этапы и методика

Нагрузочное тестирование — итеративный процесс. Один цикл включает семь этапов: анализ требований → подготовка МНТ → создание среды → разработка тест-сценариев → прогон → анализ результатов → отчёт. По итогам анализа вносятся доработки — и запускается следующий цикл.

Методика нагрузочного тестирования (МНТ)

МНТ — документ, который составляют до начала тестирования и согласовывают с заказчиком. Он фиксирует:

• Цели и ограничения — что проверяем, что выходит за рамки.
• Бизнес-сценарии — какие пользовательские пути воспроизводим: логин, поиск, оформление заказа.
• Правила моделирования — число VU, паттерн нагрузки, think time.
• Характеристики стенда — конфигурация серверов, версии ПО.
• Критерии приёмки — конкретные пороги. Пример: время отклика страницы входа ≤5 сек; CPU ≤80%; пропускная способность ≥100 транзакций/сек.
• Требования к отчёту — какие графики и метрики обязательны.

МНТ формализует отношения между командой тестирования и заказчиком. Без него критерии успеха остаются размытыми, и итоговая оценка результатов становится субъективной.

Моделирование рабочей нагрузки и think time

Think time — пауза между действиями виртуального пользователя, имитирующая реальное поведение: открыл страницу → прочитал → кликнул. Типичный диапазон: 1–10 секунд. Значение рассчитывают по логам production-сервера.

Если установить think time = 0, инструмент отправляет запросы без пауз — нагрузка становится нереалистично высокой, близкой к DDoS-атаке. Результаты такого теста вводят в заблуждение: система падёт раньше, чем при реальном трафике, а выявленные узкие места окажутся артефактом теста, а не реальной проблемой.

Стандартный паттерн нагрузки:

• Ramp-up — постепенное увеличение числа виртуальных пользователей, 15 минут.
• Стабильная нагрузка — удерживаем целевое число VU, 60 минут.
• Ramp-down — плавное снижение, 15 минут.

Оценочная формула пропускной способности: Транзакций/час = VU × (3600 / время_цикла). Для интернет-магазина: 500 VU, цикл 120 сек → 15 000 транзакций в час.

Инструменты для нагрузочного тестирования

Выбор инструмента зависит от трёх факторов: бюджета, технологического стека команды и сложности сценариев. Открытый исходный код — для большинства задач; коммерческие решения — для enterprise-масштаба.

Apache JMeter — универсальный стандарт отрасли

Apache JMeter распространяется под лицензией Apache 2.0, написан на Java. Поддерживает широкий спектр протоколов: HTTP/HTTPS, FTP, JDBC (тестирование баз данных), SOAP, LDAP.

Сильные стороны: графический интерфейс рабочего стола для создания тест-планов без написания кода, огромная экосистема плагинов, крупное сообщество. Интегрируется с Jenkins и Grafana; для облачного масштабирования подключают BlazeMeter.

Ограничение: при генерации нагрузки свыше 500 VU на одной машине JMeter начинает потреблять значительный объём RAM и CPU самого генератора нагрузки. Решение — распределённый режим (несколько машин-агентов) или запуск в облаке.

k6 — нагрузочное тестирование в CI/CD

k6 разработан Grafana Labs, сценарии пишутся на JavaScript (ES6+). Ключевое преимущество — нативная интеграция с пайплайнами непрерывной интеграции (CI/CD): Jenkins, GitLab CI, GitHub Actions. После каждого коммита автоматически запускается базовый нагрузочный тест; если время отклика выросло на 20% — сборка помечается как нестабильная.

Экспорт метрик: Grafana, InfluxDB, Prometheus, Datadog. Лучший сценарий: API-тестирование, микросервисная архитектура, DevOps-команды с культурой автоматизации.

Locust — нагрузочное тестирование на Python

Locust — open-source инструмент, сценарии пишутся на Python. Веб-интерфейс позволяет управлять тестом в реальном времени: запускать, останавливать, менять число пользователей без перезапуска процесса.

Низкий порог входа: Python знаком большинству разработчиков и специалистов по анализу данных. Идеален для команд без выделенной QA-экспертизы и для быстрого прототипирования сценариев нагрузки.

Java и Scala: Gatling и LoadRunner

Gatling написан на Scala, поддерживает также Java и Kotlin. Использует асинхронную архитектуру (Akka), что позволяет генерировать высокую нагрузку при низком потреблении ресурсов. Формирует детальные HTML-отчёты с графиками по каждому запросу. Порог входа — высокий: нужен опыт работы со Scala или Java.

LoadRunner от Micro Focus — коммерческое решение корпоративного класса. Поддерживает эмуляцию миллионов виртуальных пользователей, широкий набор протоколов и интеграцию с корпоративными системами мониторинга. Стоимость лицензии ориентирована на крупные организации.

Нагрузочное тестирование для специфических систем

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

Нагрузочное тестирование сайта онлайн

Веб-приложения работают по HTTP/HTTPS, используют сессии, Cookie и нередко JavaScript-рендеринг на клиенте. Ключевые сценарии для нагрузочного тестирования сайта: главная → каталог → карточка товара → корзина → страница оплаты.

Для быстрого старта без локальной установки подойдут облачные платформы: k6 Cloud предоставляет бесплатный уровень (free tier), BlazeMeter также имеет бесплатный тир. Оба позволяют запустить нагрузочное тестирование сайта онлайн за несколько минут прямо из браузера.

Нагрузочное тестирование 1С

Специфика 1С: COM-соединения, бизнес-транзакции платформы, работа через СУБД (PostgreSQL или MS SQL Server). Типичные узкие места — блокировки базы данных при параллельных операциях проведения документов и медленные регламентные задачи (закрытие периода, формирование сводных отчётов).

Инструменты: Apache JMeter с JDBC-сэмплером для прямой работы с СУБД, специализированные скрипты тестирования на уровне платформы 1С.

Нагрузочное тестирование PostgreSQL

При нагрузочном тестировании PostgreSQL используют: JDBC-драйвер для подключения из JMeter, встроенную утилиту pgbench, расширения k6 для работы с SQL.

Ключевые метрики: дисковые операции (I/O), время выполнения запросов, число активных соединений, размер connection pool (пула соединений). Узкое место нередко обнаруживается именно в некорректно настроенном пуле — когда приложение исчерпывает лимит и новые запросы встают в очередь.

Метрики нагрузочного тестирования

Метрики делятся на две группы: клиентские — то, что ощущает пользователь, и серверные — то, что происходит внутри инфраструктуры.

Клиентские метрики:

• Время отклика — среднее, p90, p95, p99. Стандартный SLA: p95 < 2000 мс.
• RPS (requests per second — запросов в секунду) — пропускная способность системы.
• Процент ошибок — допустимое значение обычно не выше 2%.

Серверные метрики:

• CPU utilization (загрузка процессора) — порог: ≤80%.
• RAM — рост потребления памяти под нагрузкой указывает на утечку.
• Дисковые операции (I/O) — критично для баз данных.
• Сетевой трафик — пропускная способность канала.

Percentile-метрики (p90/p95/p99) точнее среднего: среднее скрывает выбросы — медленные запросы, которые получает каждый двадцатый или каждый сотый пользователь. p95 < 2000 мс означает: 95 из 100 пользователей получат ответ быстрее двух секунд.

Базовый тест (baseline) — первый прогон с номинальной нагрузкой, результаты которого становятся точкой отсчёта. Все последующие тесты сравниваются с ним: выросло ли время отклика после последнего деплоя? Без baseline невозможно отделить деградацию от нормы.

Для ускорения поиска корневой причины применяют APM-инструменты (Application Performance Monitoring — мониторинг производительности приложений): DynaTrace, AppDynamics показывают, какой именно метод или запрос к базе данных является источником замедления.

Нормативная база: ГОСТ Р 51901 и ISO 25010

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

ISO 25010 (серия SQuaRE — Software Quality Requirements and Evaluation, система оценки качества программного обеспечения) определяет восемь характеристик качества. Одна из них — Performance Efficiency (эффективность производительности): временны́е характеристики, использование ресурсов, ёмкость системы. Именно эти атрибуты проверяет нагрузочное тестирование.

ГОСТ Р 51901 — российский стандарт управления надёжностью систем и продуктов. Устанавливает требования к анализу и обеспечению надёжности, что напрямую связано с методикой нагрузочного тестирования и критериями приёмки в МНТ.

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

Как стать специалистом по нагрузочному тестированию

Специалист по нагрузочному тестированию уровня middle+ — это одновременно архитектор, аналитик и программист. Роль требует широкого технического кругозора и умения мыслить системно.

Карьерный путь: функциональное тестирование (ФТ) → автоматизированное тестирование (АФТ) → нагрузочное тестирование. Каждый этап добавляет новый уровень технических компетенций.

Ключевые навыки специалиста:

• Языки программирования: Python, JavaScript (для k6), Java (для JMeter), Scala (для Gatling на продвинутом уровне).
• Администрирование серверов: Linux, управление ресурсами.
• Инструменты наблюдаемости: Grafana, Prometheus, DynaTrace.
• Математическая статистика: понимание percentile-метрик, распределений, выбросов.
• Составление МНТ: умение формализовать требования к производительности и согласовывать критерии приёмки.

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

Программа «Тестировщик программного обеспечения» в ProfiFuture рассчитана на ~7 недель и стоит 29 900 ₽ с господдержкой. За это время вы разберёте виды тестирования, научитесь работать с инструментами и соберёте портфолио — стартовую точку для специализации в нагрузочном направлении.

Часто задаваемые вопросы

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

Нагрузочное тестирование проверяет систему при ожидаемой нагрузке: 5 000 пользователей в будний день — всё работает? Стресс-тестирование намеренно превышает этот уровень, чтобы найти точку отказа. Дополнительная цель стресс-теста — оценить время восстановления системы после снятия перегрузки. Коротко: нагрузочное тестирование = «выдержит ли норму», стресс = «где сломается».

Когда нужно проводить нагрузочное тестирование?

Обязательно: до производственного запуска нового продукта, перед пиковыми событиями (Чёрная пятница, рекламная кампания), после архитектурных изменений, перед подписанием SLA. Нагрузочное тестирование вручную оправдано только до 10 пользователей; при большей нагрузке необходима автоматизация через JMeter, k6 или Locust.

Что такое think time и почему он важен?

Think time — пауза между действиями виртуального пользователя (обычно 1–10 секунд), имитирующая чтение страницы перед кликом. Если think time = 0, инструмент генерирует запросы без передышки — нагрузка становится нереалистично высокой, близкой к DDoS. Реалистичные значения рассчитываются по логам production-сервера.

Какие метрики собирают при нагрузочном тестировании?

Клиентские: время отклика (p90/p95/p99), RPS, процент ошибок. Серверные: CPU utilization, RAM, дисковые I/O, сетевой трафик. Типовой SLA для веб-сервисов: p95 < 2000 мс, ошибки < 2%, CPU < 80%. APM-инструменты (DynaTrace, AppDynamics) ускоряют поиск корневой причины проблемы.

Можно ли автоматизировать нагрузочное тестирование в CI/CD?

Да — это современный стандарт DevOps-команд. k6 нативно интегрируется с Jenkins, GitLab CI, GitHub Actions. После каждого коммита автоматически запускается базовый нагрузочный тест: если время отклика выросло на 20% — сборка помечается как нестабильная. Это регрессионное тестирование производительности на уровне пайплайна непрерывной интеграции.

Почему нельзя проводить нагрузочное тестирование в QA-среде?

QA-среда: 1 сервер приложений + 1 БД. Production: 3 сервера приложений + 2 БД + балансировщик нагрузки. Результаты нагрузочного тестирования в QA будут нерепрезентативными — узкие места окажутся в других компонентах или скроются. Среда для тестирования должна быть идентична production по числу серверов и их конфигурации.

Что такое методика нагрузочного тестирования (МНТ)?

МНТ — документ, формализующий все аспекты проверки: цели, ограничения, бизнес-сценарии, правила моделирования нагрузки, характеристики тестового стенда, критерии приёмки и требования к отчёту. МНТ составляется до начала тестирования и согласовывается с заказчиком. Частично регулируется ГОСТ Р 51901 и внутренними стандартами организации.

Что такое базовый тест (baseline) в нагрузочном тестировании?

Baseline — первый прогон с номинальной нагрузкой, результаты которого становятся точкой отсчёта. Все последующие тесты сравниваются с ним: выросло ли время отклика после изменения кода? Уменьшилась ли пропускная способность после обновления БД? Без baseline невозможно понять — произошла деградация или, напротив, улучшение.

Хотите разобраться в тестировании программного обеспечения и двигаться в сторону нагрузочного направления? В ProfiFuture можно пройти обучение за ~7 недель с господдержкой — 75% стоимости компенсируется образовательной квотой. Смотрите программу «Тестировщик программного обеспечения».