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

Введение в нагрузочное тестирование: цели, виды и основные понятия

Представьте, что вы владелец небольшого уютного магазина. Обычно к вам заходят 10–20 покупателей в час, и один кассир прекрасно справляется с работой. Но наступает «Чёрная пятница». В магазин одновременно пытаются войти 500 человек. Кассир в панике, очередь выходит на улицу, терминал оплаты зависает, а недовольные клиенты уходят к конкурентам.

В мире IT происходит то же самое. Только вместо магазина — ваш веб-сайт или приложение, а вместо покупателей — виртуальные пользователи.

Эта статья открывает курс «Основы нагрузочного тестирования». Сегодня мы разберем фундамент: что это такое, зачем это нужно бизнесу и инженерам, и какие виды нагрузок существуют.

!Визуальное сравнение штатной работы системы и работы в условиях критической нагрузки

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

Нагрузочное тестирование (Performance Testing) — это вид нефункционального тестирования, который определяет, как система ведет себя под определенной нагрузкой.

В отличие от функционального тестирования, где мы проверяем «работает ли кнопка», здесь мы спрашиваем: «как быстро сработает кнопка, если на неё нажмут 10 000 человек одновременно?».

Основные цели

Главная цель — не просто «сломать» сервер, а получить измеримые показатели качества. Мы хотим убедиться в следующем:

Производительность (Performance): Система отвечает достаточно быстро.

Масштабируемость (Scalability): Система может обрабатывать больше пользователей при добавлении ресурсов.

Стабильность (Stability): Система работает без сбоев в течение длительного времени.

Надежность (Reliability): Система корректно обрабатывает ошибки при высокой нагрузке.

Ключевые метрики и понятия

Прежде чем углубляться в виды тестирования, нам нужно выучить «язык», на котором говорят нагрузочные тестировщики. Всё тестирование строится вокруг нескольких ключевых метрик.

1. Время отклика (Response Time)

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

> «Пользователь не должен ждать загрузки страницы больше 2 секунд» — типичное требование к времени отклика.

2. Пропускная способность (Throughput)

Это количество данных или запросов, которые система может обработать за единицу времени. Часто измеряется в RPS (Requests Per Second — запросов в секунду).

3. Количество виртуальных пользователей (Virtual Users / VU)

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

Математическая связь метрик: Закон Литтла

В теории массового обслуживания существует фундаментальная теорема, которая связывает эти понятия — Закон Литтла. Он помогает проверить корректность ваших тестов.

Формула выглядит так:

Где: * — среднее количество пользователей в системе (Concurrency). * — скорость поступления запросов или пропускная способность (RPS). * — среднее время нахождения запроса в системе (Response Time).

Пример: Если ваша система обрабатывает 100 запросов в секунду (), и каждый запрос обрабатывается 0.5 секунды (), то в любой момент времени в системе находится 50 активных пользователей ().

Если вы видите в отчете, что при 100 пользователях и времени отклика 0.5 секунды ваш RPS равен 1000, значит, в отчете ошибка или вы неправильно понимаете модель нагрузки. Закон Литтла не обмануть.

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

Многие новички называют всё подряд «стресс-тестированием», но это неверно. Существует несколько видов тестов, каждый из которых отвечает на свой вопрос.

!Графическое отображение профилей нагрузки для разных видов тестирования

1. Нагрузочное тестирование (Load Testing)

Это «классическое» тестирование. Мы подаем на систему ожидаемую нагрузку (например, ту, которая планируется в продакшене).

* Цель: Проверить, справляется ли система с заявленными требованиями. * Вопрос: «Выдержит ли сайт 1000 пользователей, как мы обещали заказчику?»

2. Стресс-тестирование (Stress Testing)

Здесь мы намеренно превышаем ожидаемую нагрузку, пока система не сломается.

* Цель: Найти предел прочности (точку отказа) и проверить восстанавливаемость. * Вопрос: «При какой нагрузке сервер упадет? И поднимется ли он сам, когда нагрузка спадет?»

3. Тестирование стабильности (Stability / Soak Testing)

Длительный тест (от нескольких часов до нескольких суток) со средней нагрузкой.

* Цель: Найти утечки памяти, переполнение логов или баз данных. * Вопрос: «Не начнет ли система тормозить, если будет работать под нагрузкой 24 часа подряд?»

4. Тестирование всплесков (Spike Testing)

Резкое увеличение и уменьшение нагрузки.

* Цель: Проверить реакцию на внезапные скачки трафика (например, рассылка пуш-уведомлений или реклама по ТВ). * Вопрос: «Что будет, если за 1 минуту придет 10 000 человек, а потом все уйдут?»

5. Тестирование масштабируемости (Scalability Testing)

Мы постепенно увеличиваем нагрузку и одновременно добавляем ресурсы (например, новые сервера).

* Цель: Понять, дает ли добавление «железа» прирост производительности. * Вопрос: «Если мы поставим второй сервер, сможем ли мы обработать в 2 раза больше людей?»

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

Нагрузочное тестирование — это не просто «запустить скрипт и смотреть на графики». Это процесс, состоящий из этапов:

Анализ требований: Понимаем, что тестируем и какие метрики считаем успехом.

Разработка профиля нагрузки: Определяем, как ведут себя пользователи (сколько их, что они делают).

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

Настройка окружения: Готовим тестовые стенды (они должны быть похожи на продакшен).

Проведение тестов: Запускаем нагрузку.

Анализ результатов: Ищем узкие места (bottlenecks).

Заключение

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

Запомните главное правило: нельзя оптимизировать то, что нельзя измерить. Нагрузочное тестирование дает нам именно измерения.

Планирование: определение профиля нагрузки, метрики производительности и SLA

В предыдущей лекции мы разобрали, что такое нагрузочное тестирование и зачем оно нужно. Теперь представьте, что вы архитектор, которому поручили построить мост. Вы не начинаете сразу заливать бетон. Сначала вы проводите расчеты: сколько машин проедет в час пик? Сколько грузовиков? Какой силы ветер должен выдержать мост?

В нагрузочном тестировании этот этап называется планированием. Это самый важный шаг, от которого зависит 90% успеха. Если вы подадите нагрузку, которая не соответствует реальности, вы получите красивые, но бесполезные графики.

Сегодня мы научимся составлять профиль нагрузки, выбирать правильные метрики и разбираться в аббревиатурах SLA, SLO и SLI.

Профиль нагрузки: моделирование реальности

Профиль нагрузки — это набор параметров и сценариев, который описывает поведение реальных пользователей в вашей системе. Это ваш «чертеж» для написания тестов.

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

!Визуализация распределения пользователей по разным сценариям использования системы

Как составить профиль нагрузки?

Чтобы составить реалистичный профиль, нужно ответить на три вопроса:

Что делают пользователи? (Сценарии)

Как часто они это делают? (Интенсивность)

Какими данными они оперируют? (Тестовые данные)

#### 1. Сбор статистики Не нужно гадать. Используйте данные, которые у вас уже есть:

* Системы веб-аналитики: Google Analytics, Яндекс.Метрика. Они покажут самые популярные пути пользователей. * Логи веб-сервера (Access Logs): Самый точный источник. Можно посчитать точное количество запросов к каждому URL. * Бизнес-требования: Если система новая и логов нет, спросите у аналитиков или маркетологов: «Сколько пользователей мы ожидаем в день запуска?».

#### 2. Принцип Парето в тестировании Вы не сможете протестировать 100% функционала системы. Это дорого и долго. Используйте правило 80/20:

> 20% сценариев создают 80% нагрузки на систему.

Обычно достаточно покрыть тестами 3–5 ключевых сценариев, чтобы найти большинство проблем производительности.

Пример профиля нагрузки для интернет-магазина

Предположим, мы ожидаем 1000 активных пользователей в час. Профиль может выглядеть так:

| Сценарий | Доля пользователей | Интенсивность (операций/час) | | :--- | :--- | :--- | | Просмотр главной страницы | 100% | 1000 | | Поиск товара | 60% | 600 | | Просмотр карточки товара | 40% | 400 | | Добавление в корзину | 10% | 100 | | Оформление заказа (Checkout) | 2% | 20 |

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

Метрики производительности: что мы измеряем?

В прошлой статье мы упоминали время отклика и пропускную способность. Теперь углубимся в детали. Метрики делятся на две большие группы: бизнес-метрики (со стороны пользователя) и технические метрики (со стороны сервера).

1. Бизнес-метрики (Client-side)

Эти метрики показывают, насколько комфортно пользователю работать с системой.

* Время отклика (Response Time): Время от отправки запроса до получения последнего байта ответа. * Время отрисовки (Render Time): Время, которое браузер тратит на отображение страницы после получения данных. Нагрузочное тестирование бэкенда обычно это не измеряет, но об этом важно помнить. * Количество ошибок (Error Rate): Процент запросов, завершившихся ошибкой (коды 4xx, 5xx). Обычно допустимый уровень — менее 1% или даже 0.1%.

2. Технические метрики (Server-side)

Эти метрики показывают «здоровье» серверов под нагрузкой. Их называют мониторингом утилизации ресурсов.

* CPU Usage (Загрузка процессора): Если процессор загружен на 100%, очередь запросов начнет расти. * Memory Usage (Использование памяти): Опасно не только исчерпание памяти, но и активная работа сборщика мусора (Garbage Collector), которая может «фризить» приложение. * Disk I/O (Дисковые операции): Скорость чтения и записи на диск. Часто является узким местом для баз данных. * Network Bandwidth (Сетевой трафик): Хватает ли ширины канала для передачи всех данных?

!Пример дашборда мониторинга во время нагрузочного теста

SLA, SLO и SLI: разбираемся в аббревиатурах

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

SLI (Service Level Indicator) — Индикатор

Это конкретная метрика, которую мы измеряем. То, ЧТО мы меряем.

Пример:* Время отклика главной страницы. Пример:* Процент успешных запросов.

SLO (Service Level Objective) — Цель

Это целевое значение индикатора, к которому мы стремимся. То, СКОЛЬКО должно быть.

Пример:* Время отклика главной страницы должно быть мс. Пример:* 99.9% запросов должны быть успешными.

SLA (Service Level Agreement) — Соглашение

Это официальный договор (часто юридический) между поставщиком услуг и клиентом. Он описывает, ЧТО БУДЕТ, если цель (SLO) не достигнута.

Пример:* Если время отклика превысит 200 мс в течение часа, мы вернем клиенту 10% стоимости подписки за месяц.

> Простое правило: Инженеров волнует SLO (цели), юристов и менеджеров волнует SLA (штрафы), а система мониторинга показывает SLI (факты).

Математика планирования: расчет интенсивности

Как перевести требования бизнеса в настройки нагрузочного скрипта? Часто нам нужно рассчитать Pacing — паузу между итерациями (повторениями) сценария для одного виртуального пользователя.

Допустим, нам нужно достичь определенной пропускной способности (RPS — Requests Per Second).

Формула для расчета необходимого количества пользователей или пауз выглядит так:

Где: * — целевое количество запросов в секунду. * — количество виртуальных пользователей (Virtual Users). * — время отклика системы (Response Time) в секундах. * — время паузы (Pacing/Think Time) в секундах.

Из этой формулы мы можем выразить паузу (), которую нужно прописать в скрипте, чтобы при заданном количестве пользователей получить нужную нагрузку:

Где: * — искомая пауза (Pacing). * — количество виртуальных пользователей. * — целевая нагрузка. * — ожидаемое время отклика.

Пример расчета: У нас есть 100 виртуальных пользователей (). Мы хотим создать нагрузку 20 запросов в секунду (). Ожидаемое время отклика сервера — 0.5 секунды (). Какую паузу ставить?

Ответ: нужно установить паузу 4.5 секунды между действиями каждого виртуального пользователя.

Чек-лист этапа планирования

Прежде чем переходить к написанию скриптов (чем мы займемся в следующей статье), проверьте себя по этому списку:

Цели определены: Мы знаем, зачем тестируем (поиск предела, проверка SLA, тест стабильности).

Профиль нагрузки согласован: Мы знаем сценарии и их интенсивность.

Метрики выбраны: Мы знаем, какие SLI будем отслеживать и какие SLO считаются успехом.

Окружение готово: Тестовый стенд соответствует (или похож) на продакшен.

Данные подготовлены: У нас есть база данных с тестовыми товарами и пользователями.

Планирование может показаться скучным этапом, но именно оно отличает профессионального инженера по производительности от человека, который просто умеет нажимать кнопку «Start» в инструменте тестирования. В следующем уроке мы выберем инструменты и начнем писать код.