За пределами стандартного нагрузочного тестирования
В предыдущих уроках вы научились использовать инструменты JMeter, k6, Gatling и Locust для создания нагрузочных тестов. Но выбор правильного типа теста производительности не менее важен, чем выбор правильного инструмента. Разные типы тестов отвечают на разные вопросы о системе.
Этот урок охватывает четыре специализированных типа тестирования производительности, выходящих за рамки стандартного нагрузочного тестирования. Каждый из них имеет свою цель, профиль нагрузки и набор выявляемых дефектов.
Стресс-тестирование: Поиск точки отказа
Определение: Стресс-тестирование нагружает систему сверх проектной мощности для определения точки отказа и наблюдения за характером сбоя.
Ключевой вопрос: «В какой момент система выходит из строя и как это происходит?»
Профиль нагрузки
Стресс-тестирование постепенно увеличивает нагрузку до деградации или сбоя системы:
Типичный стресс-тест поднимает нагрузку значительно выше ожидаемого максимума:
| Фаза | Длительность | Уровень нагрузки |
|---|---|---|
| Разогрев | 5 мин | 50% от ожидаемого макс. |
| Нормальная нагрузка | 10 мин | 100% от ожидаемого макс. |
| Стресс фаза 1 | 10 мин | 150% от ожидаемого макс. |
| Стресс фаза 2 | 10 мин | 200% от ожидаемого макс. |
| Экстремальный стресс | 10 мин | 300% от ожидаемого макс. |
| Восстановление | 10 мин | Возврат к 0 или норме |
На что обращать внимание
- При каком количестве пользователей начинают появляться ошибки?
- Система деградирует плавно (замедление ответов) или отказывает катастрофически (полный сбой, повреждение данных)?
- Восстанавливается ли система при возврате нагрузки к норме, или требуется перезапуск?
- Информативны ли сообщения об ошибках? Пользователи должны видеть дружественные страницы, а не стектрейсы.
- Есть ли каскадные отказы? Падение одного компонента вызывает падение других?
Типичные обнаруживаемые дефекты
- Неотвечающие эндпоинты при экстремальной нагрузке
- Ошибки нехватки памяти (OOM)
- Исчерпание пула потоков
- Превышение лимитов подключений к БД
- Некорректная конфигурация балансировщика нагрузки
- Отсутствие circuit breakers или rate limiting
- Повреждение данных при конкурентной записи
Тестирование выносливости (Soak): Длительный забег
Определение: Тестирование выносливости (также soak-тестирование) применяет умеренную стабильную нагрузку в течение длительного периода — обычно часы или даже дни.
Ключевой вопрос: «Остаётся ли система стабильной и производительной при длительной нормальной эксплуатации?»
Профиль нагрузки
15 мин] --> B[Стабильная нагрузка 70-80% мощности
4-24 часа] B --> C[Снижение
15 мин] end
| Фаза | Длительность | Уровень нагрузки |
|---|---|---|
| Разгон | 15-30 мин | от 0% до 70-80% мощности |
| Стабильное состояние | 4-72 часа | 70-80% от ожидаемого макс. |
| Снижение | 15-30 мин | Возврат к 0 |
Уровень нагрузки должен представлять типичное продакшн-использование, а не экстремальные условия. Цель — работать достаточно долго, чтобы проявились зависящие от времени дефекты.
На что обращать внимание
- Использование памяти во времени: Есть ли тренд на рост? Медленная утечка, добавляющая 1МБ в час, обрушит систему через несколько дней.
- Тренды времени ответа: Растут ли времена ответа постепенно, хотя нагрузка остаётся постоянной?
- Пул соединений к БД: Возвращаются ли соединения корректно, или пул медленно истощается?
- Дисковое пространство: Растут ли логи, временные файлы или кэш без ограничений?
Типичные обнаруживаемые дефекты
- Утечки памяти (объекты не собираются сборщиком мусора)
- Исчерпание пула соединений к БД
- Потребление дискового пространства логами
- Постепенная деградация производительности
- Проблемы управления сессиями (накопление устаревших сессий)
- Кэш, растущий без политики вытеснения
Пиковое тестирование (Spike): Внезапный всплеск
Определение: Пиковое тестирование имитирует внезапное массивное увеличение нагрузки с последующей высокой нагрузкой или столь же резким снижением.
Ключевой вопрос: «Может ли система выдержать внезапный наплыв пользователей и быстро восстановиться?»
Профиль нагрузки
5 мин] --> B[Мгновенный пик
10x пользователей] B --> C[Удержание пика
5-10 мин] C --> D[Падение к норме
мгновенно] D --> E[Восстановление
5 мин] end
Реальные сценарии для пикового тестирования
- Флэш-распродажи: Интернет-магазин объявляет скидку 90% в полдень
- Срочные новости: Новостной сайт получает ссылку из соцсетей
- Запуски игр: Открытие сервера для новой онлайн-игры
- Маркетинговые кампании: Email-рассылка направляет миллионы пользователей на лендинг
На что обращать внимание
- Как быстро масштабируется система? Облачной инфраструктуре с автомасштабированием может потребоваться 2-5 минут для запуска новых инстансов.
- Система отбрасывает нагрузку корректно? Должны активироваться очереди, rate limiting или комнаты ожидания.
- Время восстановления: Через сколько после пика система возвращается к нормальным временам ответа?
- Целостность данных: Были ли потерянные транзакции, дублированные заказы или повреждённые данные во время пика?
Объёмное тестирование: Большие наборы данных
Определение: Объёмное тестирование оценивает поведение системы, когда база данных или хранилище содержит очень большие объёмы данных, независимо от числа конкурентных пользователей.
Ключевой вопрос: «Работает ли система хорошо при продакшн-объёмах данных или больше?»
Чем оно отличается
Объёмное тестирование — это не про конкурентных пользователей, а про размер данных. Можно проводить с несколькими пользователями, но с миллионами записей в БД.
| Аспект | Нагрузочное тестирование | Объёмное тестирование |
|---|---|---|
| Фокус | Конкурентные пользователи | Размер данных |
| Пользователи | Много (сотни/тысячи) | Мало (1-10) |
| Данные | Обычный набор | Очень большой набор |
| Измеряет | Время ответа под нагрузкой | Время ответа с большими данными |
Что тестировать
- Запросы к БД: Запросы, работающие с 1000 записями, работают ли с 10 миллионами?
- Поиск: Деградирует ли полнотекстовый поиск с большим индексом?
- Пагинация: Страница 10 000 загружается так же быстро, как страница 1?
- Отчёты и агрегации: Может ли система генерировать отчёты из миллионов записей?
Типичные обнаруживаемые дефекты
- Отсутствующие индексы БД, вызывающие полные сканы таблиц
- Проблемы N+1 запросов, становящиеся критичными на масштабе
- Пагинация через OFFSET вместо курсорной
- Таймауты отчётов на больших наборах данных
Упражнение: Проектирование профилей нагрузки для каждого типа
Вы QA-лид платформы онлайн-бронирования билетов. Платформа обычно обслуживает 500 конкурентных пользователей и хранит 2 миллиона записей бронирований. Спроектируйте профили нагрузки для каждого из четырёх типов тестирования.
Контекст
- Нормальный пик: 500 конкурентных пользователей
- Ожидаемый максимум: 800 конкурентных пользователей
- БД: 2 миллиона бронирований, 500К аккаунтов
- Особые события: Открытие продаж на концерты вызывает 10-кратные пики
- Система работает 24/7
Требования
Для каждого типа теста (стресс, выносливость, пиковый, объёмный) укажите:
- Конкретный вопрос, на который вы хотите ответить
- Профиль нагрузки (фазы, пользователи, длительность)
- Три ключевые метрики для мониторинга
- Два потенциальных дефекта, которые ожидаете найти
Подсказка: Подумайте о реальных сценариях
- Стресс: Что происходит, когда популярный концерт поступает в продажу и пользователи продолжают увеличиваться сверх 800?
- Выносливость: Система работает 24/7 — что происходит после недели непрерывной работы?
- Пик: Известный артист анонсирует внезапный концерт — 5000 пользователей приходят за 30 секунд.
- Объём: После 3 лет работы в БД 20 миллионов бронирований. Поиск работает?
Решение: Полные проекты профилей нагрузки
1. Стресс-тест
Вопрос: «При какой нагрузке система бронирования перестаёт принимать новые бронирования?»
Профиль нагрузки:
- Разогрев: 5 мин на 250 пользователях
- Нормальная: 10 мин на 500 пользователях
- Стресс 1: 10 мин на 800 пользователях (ожидаемый макс.)
- Стресс 2: 10 мин на 1200 пользователях (150% макс.)
- Стресс 3: 10 мин на 2000 пользователях (250% макс.)
- Экстрем: 10 мин на 3000 пользователях
- Восстановление: 15 мин возврат к 500
Ключевые метрики: Процент ошибок на каждой фазе, кривая деградации времени ответа, время восстановления
Ожидаемые дефекты: Исчерпание пула соединений к БД при ~1500 пользователях, очередь email-подтверждений переполняется и падает
2. Тест выносливости
Вопрос: «Сохраняет ли система производительность после 48 часов непрерывной работы?»
Профиль: Разгон 30 мин до 400 пользователей, стабильное состояние 48 часов, снижение 30 мин
Ключевые метрики: Тренд потребления памяти (по часам), тренд p95 времени ответа, утилизация пула соединений
Ожидаемые дефекты: Объекты сессий не очищаются для брошенных бронирований (утечка памяти), ротация логов настроена неверно — диск заполняется через 24 часа
3. Пиковый тест
Вопрос: «Может ли система выдержать внезапный наплыв при открытии продаж на популярный концерт?»
Профиль: Базовая 5 мин на 500, мгновенный скачок до 5000 (10x), удержание 10 мин, мгновенное падение до 500, восстановление 10 мин
Ключевые метрики: Процент ошибок в первые 60 секунд пика, время до первого успешного бронирования, время восстановления до нормального p95
Ожидаемые дефекты: Блокировки резервирования мест вызывают deadlocks при внезапной конкурентности, таймауты платёжного шлюза (сторонний сервис не справляется с всплеском)
4. Объёмный тест
Вопрос: «Будут ли поиск и отчёты работать при 20 миллионах бронирований в БД?»
Настройка: 20 миллионов записей, 5 миллионов аккаунтов, 10 лет истории. Тест с 5-10 пользователями.
Ключевые метрики: Время выполнения поисковых запросов, время генерации отчётов, время загрузки деталей бронирования для старых vs новых записей
Ожидаемые дефекты: Поиск бронирований без фильтра дат вызывает полный скан таблицы (отсутствует составной индекс), агрегация месячного отчёта превышает таймаут 30 секунд при 20М записей
Профессиональные советы
- Комбинируйте типы в стратегии тестирования: Полная стратегия включает все четыре типа. Сначала нагрузочные тесты (базовая линия), затем стресс, потом выносливость и наконец объёмные.
- Мониторьте инфраструктуру, не только приложение: Во время всех тестов производительности отслеживайте CPU, память, дисковый I/O, сеть, соединения к БД и глубину очередей.
- Тестируйте восстановление явно: После стресс- и пиковых тестов всегда включайте фазу восстановления. Система, которая автоматически восстанавливается за 30 секунд, кардинально отличается от требующей ручного вмешательства.
- Генерация данных для объёмного тестирования: Используйте Faker (Python), DataFactory (Java) или кастомные скрипты для генерации реалистичных данных с тем же статистическим распределением, что и в продакшне.
- Установите чёткие критерии приёмки: Перед запуском любого теста определите, что значит «пройдено» и «не пройдено».