Урок 14 — Stress Testing

Название: Stress Testing — как система ведёт себя за пределами нормы
Описание: Разбираем стресс-тестирование: что это, чем отличается от нагрузочного тестирования, как проводить и какие результаты анализировать.
Почему это важно для QA: Стресс-тестирование показывает, как система «умирает» и «восстанавливается». Это критично для понимания реальных пределов системы и поведения при экстренных ситуациях.

1. Что такое Stress Testing

Stress Testing (стресс-тестирование) — это вид нагрузочного тестирования, при котором система намеренно подвергается нагрузке, превышающей ожидаемую. Цель — найти точку разрыва (breaking point) и понять, как система ведёт себя при экстремальных условиях.

Аналогия

Снова мост. Load Testing — это 10 тонн при допустимом пределе 10 тонн. А Stress Testing — это 15, 20, 25 тонн. Ты смотришь:

• При каком весе мост начинает деформироваться?
• Разрушается ли он сразу или постепенно?
• После снятия нагрузки — возвращается ли в исходное состояние?

2. Ключевые вопросы Stress Testing

3. Stress Testing vs Load Testing

4. Типы Stress Testing

4.1 Distributed Stress Testing

Стресс-тест с нескольких клиентов одновременно. Имитирует реальный трафик с разных точек мира.

4.2 Application Stress Testing

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

4.3 Transactional Stress Testing

Тестирование конкретных бизнес-транзакций: что происходит при 10 000 одновременных заказов?

4.4 Spike Testing

Резкий и кратковременный скачок нагрузки:

Имитирует вирусный пост в социальных сетях или запуск акции.

4.5 Soak Testing (Volume / Endurance)

Длительная умеренная нагрузка (70–80%) в течение 8–72 часов. Ищет утечки памяти (memory leaks), накапливаемые ошибки.

5. Сценарии стресс-тестирования

Сценарий 1: Пошаговое увеличение нагрузки (Step Stress Test)

Время | Пользователи | Ожидание
──────┼──────────────┼──────────────────────────
0-5m  │ 100          │ Стабильная работа
5-10m │ 500          │ Стабильная работа
10-15m│ 1000         │ Замедление?
15-20m│ 2000         │ Ошибки?
20-25m│ 5000         │ Crash?
25-30m│ 0            │ Восстановление?

Сценарий 2: Spike Test

Время | Пользователи
──────┼──────────────
0-5m  │ 100 (норма)
5m    │ 5000 (мгновенный скачок)
5-15m │ 5000 (удержание пика)
15m   │ 100 (резкий спад)
15-25m│ 100 (наблюдаем восстановление)

6. Пример Stress Test с k6

// stress-test.js
import http from "k6/http";
import { sleep, check } from "k6";

export const options = {
  stages: [
    // Нормальная нагрузка (baseline)
    { duration: "2m", target: 100 },
    // Начинаем нагнетать сверх нормы
    { duration: "5m", target: 1000 },
    { duration: "5m", target: 2000 },
    { duration: "5m", target: 5000 },
    // Пиковая нагрузка (стресс)
    { duration: "5m", target: 10000 },
    // Снятие нагрузки — наблюдаем восстановление
    { duration: "5m", target: 0 },
  ],
  thresholds: {
    // Порог провала — система полностью упала
    http_req_failed: ["rate<0.5"],   // допускаем до 50% ошибок (стресс-тест)
  },
};

export default function () {
  const response = http.get("https://staging.shop.example.com/");

  check(response, {
    "сервер ответил": (r) => r.status < 500,
    "не 503 (Service Unavailable)": (r) => r.status !== 503,
  });

  sleep(1);
}

Spike Test с k6

// spike-test.js
import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "1m", target: 100 },     // норма
    { duration: "10s", target: 10000 },  // резкий скачок до 10 000
    { duration: "3m", target: 10000 },   // удержание пика
    { duration: "10s", target: 100 },    // резкое снижение
    { duration: "3m", target: 100 },     // наблюдение за восстановлением
    { duration: "1m", target: 0 },       // завершение
  ],
};

export default function () {
  http.get("https://staging.shop.example.com/api/products");
  sleep(1);
}

7. Анализ результатов

Хорошее поведение системы под стрессом

✅ Система замедляется, но не падает
✅ Пользователи получают понятные сообщения об ошибке (503, «Попробуйте позже»)
✅ Данные не теряются при перегрузке
✅ После снятия нагрузки система восстанавливается автоматически
✅ Очередь запросов обрабатывается после пика

Плохое поведение системы под стрессом

❌ Сервер «падает» без возможности восстановления
❌ Данные транзакций теряются
❌ Пользователи видят 500 ошибки без объяснений
❌ После пика нужен ручной перезапуск сервера
❌ Система не восстанавливается — требует вмешательства DevOps
❌ Утечка памяти: каждый час потребление памяти растёт

8. Что фиксировать при стресс-тестировании

Метрики в момент деградации:
├── При каком количестве VU начались ошибки?
├── При каком количестве VU системы упала полностью?
├── Какой процент ошибок на каждом уровне нагрузки?
├── Время восстановления после снятия нагрузки?
└── Ресурсы сервера: CPU, RAM, disk I/O, network

Чек-лист для анализа:
□ Breaking point зафиксирован
□ Тип отказа описан (graceful / abrupt)
□ Данные целостны после отказа
□ Время восстановления измерено
□ Bottleneck определён (сервер, БД, сеть)

9. Частые ошибки

❌ Путают Stress Test и Load Test
→ Запомни: Load = ожидаемая нагрузка, Stress = за пределами нормы до отказа.

❌ Не проверяют восстановление
→ Важно не только как система падает, но и как она восстанавливается.

❌ Не мониторят серверные ресурсы
→ Без метрик CPU/RAM невозможно найти настоящую причину сбоя.

❌ Проводят стресс-тест на production
→ Никогда. Только на изолированном окружении.

Итог

STRESS TESTING
├── Цель: найти breaking point и понять поведение при сбое
├── Нагрузка: превышает ожидаемую (150–1000%+)
├── Ключевые вопросы:
│   ├── При какой нагрузке система ломается?
│   ├── Как ломается — корректно или аварийно?
│   └── Восстанавливается ли автоматически?
├── Инструменты: k6, JMeter, Gatling
├── Типы: Step, Spike, Soak
└── Никогда: не тестируй на production