Нагрузочные тесты

НЕ ОБЯЗАТЕЛЬНО ДЛЯ НОВИЧКОВ

Материалы в энциклопедии (раздел 7 — тестирование)

Перед лабораторной имеет смысл прочитать теорию и смежные темы — так метрики и шаги эксперимента будут на своих местах.

Задача Статья
Маршрут по всему разделу Тестирование — о разделе
Типы нагрузочного и стресс-теста, RPS, latency, SLO Нагрузочное и стресс-тестирование
Практика: сценарии, точка насыщения, отчёт Проверка надежности под нагрузкой
Нагрузка среди видов тестирования Основы тестирования · Классификация видов
Где baseline в процессе QA Жизненный цикл тестирования
Автоматизация прогонов и CI Автоматизация тестирования
Оформление результатов Документация тестировщика

Рекомендуемый порядок: 122 → 1014 → эта лабораторная.

Зачем нужна эта лабораторная

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

В этой лабораторной вы пройдете полный цикл:

  1. Подготовите стенд и выберете реалистичный сценарий.
  2. Проведете базовый прогон.
  3. Постепенно увеличите нагрузку.
  4. Снимете метрики и сделаете выводы.
  5. Сформулируете план улучшений.

Базовые понятия

  • RPS (Requests Per Second) — сколько запросов в секунду обрабатывает сервис.
  • Latency (задержка) — время ответа сервера. Важно смотреть не только среднее, но и p95/p99.
  • Error rate — доля запросов с ошибкой (4xx, 5xx, таймауты).
  • Throughput — объем обработанных данных или операций за единицу времени.
  • Saturation — степень "забитости" ресурсов (CPU, RAM, диск, сеть, пул соединений).

Ключевая идея: "среднее время ответа 100 мс" ничего не гарантирует, если p99 уже 5 секунд. Подробнее о метриках и различии нагрузочного и стресс-теста — в статье про нагрузочное тестирование.

Подготовка стенда

1) Выберите инструмент

Для старта удобно использовать k6:

  • простой JS-сценарий,
  • понятные отчеты,
  • удобно запускать локально и в CI.

2) Зафиксируйте условия

Чтобы результаты были сравнимыми:

  • тестируйте один и тот же билд;
  • выключите лишние фоновые процессы;
  • используйте стабильное окружение (один и тот же хост/контейнер);
  • запишите конфигурацию сервиса (лимиты CPU/RAM, БД, кэш).

3) Определите SLO

Пример SLO для API:

  • p95 < 300ms,
  • error_rate < 1%,
  • минимум 400 RPS на целевом эндпоинте.

Без SLO нельзя понять, тест пройден или нет. Как формулировать цели и пороги — см. нагрузочное и стресс-тестирование.

Пошаговый эксперимент

Шаг 1. Выберите критичный сценарий

Не тестируйте "абстрактный ping". Берите пользовательский путь, например:

  • авторизация,
  • поиск,
  • оформление заказа,
  • создание заявки.

Шаг 2. Сделайте smoke-прогон

Цель — проверить, что тест вообще корректный (см. также проверку надёжности под нагрузкой):

  • 1-5 виртуальных пользователей,
  • короткая длительность (30-60 секунд),
  • валидация кодов ответа и структуры ответа.

Шаг 3. Запустите baseline

Запустите умеренную нагрузку, которую система должна выдерживать "всегда" — это эталон для сравнения с ramp-up и стресс-тестом. Baseline обычно фиксируют после smoke и до роста нагрузки; место этого шага в общем процессе QA — в жизненном цикле тестирования.

Снимите:

  • p50/p95/p99,
  • RPS,
  • error rate,
  • CPU/RAM сервера,
  • время ответов БД.

Шаг 4. Сделайте ramp-up

Плавно увеличивайте нагрузку, например:

  • 50 пользователей -> 100 -> 200 -> 400,
  • каждый этап по 3-5 минут,
  • пауза 1-2 минуты между этапами для фиксации состояния.

Задача — найти момент деградации, где:

  • резко растет p95/p99,
  • увеличивается число ошибок,
  • один из ресурсов выходит на потолок.

Шаг 5. Проведите стресс-тест

Нагрузите систему выше целевых значений (отличие от нагрузочного теста — в энциклопедии), чтобы увидеть:

  • как именно она ломается;
  • насколько быстро восстанавливается;
  • нет ли "утечек" после перегрузки.

Шаг 6. Повторите тест после оптимизации

Любая гипотеза (индекс в БД, пул соединений, кэш, асинхронная обработка) подтверждается только повторным прогоном по тем же условиям.

Минимальный пример k6

Как интерпретировать результаты

Смотрите на связку "нагрузка -> узкое место":

  • высокий CPU + рост latency: возможно, неэффективная бизнес-логика;
  • нормальный CPU, но высокий latency БД: вероятны медленные запросы/индексы;
  • всплеск 5xx при росте RPS: проблемы с таймаутами, пулом подключений или очередями;
  • резкий рост p99, при нормальном среднем: "длинный хвост" из-за блокировок или редких тяжелых операций.

Типичные ошибки

  • Тест "не тех" эндпоинтов (не отражает реальное поведение пользователей).
  • Нет прогрева приложения перед замером.
  • Сравнение прогонов в разных условиях.
  • Анализ только среднего времени ответа.
  • Отсутствие серверных метрик (видно симптом, но не причину).

Что добавить в отчет

  1. Цели и SLO.
  2. Описание сценария и профиля нагрузки.
  3. Конфигурацию окружения.
  4. Таблицу метрик по этапам.
  5. Найденные узкие места.
  6. Подтвержденный эффект после оптимизаций.

Хороший отчет позволяет другому инженеру повторить эксперимент и получить сопоставимый результат. Шаблоны артефактов QA — в документации тестировщика.

Чтобы встроить прогоны в pipeline, см. автоматизацию тестирования.