Реклама уже настроена, посадочная страница открывается быстро, форма отправляет заявку. Всё выглядит готовым к запуску. Но обычная проверка одним посетителем не отвечает на другой вопрос: что произойдёт, когда одновременно начнут искать товары, оформлять заказы и отправлять формы?
Нагрузочное тестирование сайта помогает проверить выбранные действия при заданном потоке запросов и найти ограничения системы. Его результат относится к конкретному сценарию, окружению и профилю нагрузки. По одному удачному запуску нельзя обещать, что сайт выдержит любой наплыв посетителей.
В Гуси-Лебеди предлагаем начинать с вопроса, который важен бизнесу: смогут ли посетители выполнить нужное действие в согласованных условиях? Ниже разберём подготовку такой проверки, показатели для отчёта и вопросы, которые стоит задать исполнителю.
Сначала решите, какой ответ нужен бизнесу
«Проверить, выдержит ли сайт рекламу» звучит понятно, но для теста этого мало. Нужны действия посетителей, ожидаемый поток и критерии успешного выполнения. У каталога это может быть поиск и открытие карточки, у сервиса записи: выбор времени и подтверждение бронирования. Если проверить только главную страницу, вывод об оформлении заказа из такого запуска не следует.
Посещаемость за сутки тоже не задаёт готовую нагрузку. Важно, как распределены обращения во времени и что люди делают между ними. Виртуальные пользователи, запросы в секунду и завершённые действия описывают разные стороны проверки. Один пользователь может выполнить несколько запросов; медленные ответы могут уменьшить число действий, которое он успевает завершить.
Зафиксируйте профиль: плавное увеличение потока, резкий всплеск или длительную работу на выбранном уровне. Выбор зависит от вопроса. Для рекламного запуска полезно проверить характерные сценарии ожидаемого потока, а для поиска предела требуется отдельно согласованный стрессовый режим и условия остановки. Эти проверки нельзя свести к одному числу «пользователей на сайте».
| Показатель | Что означает | Что уточнить в задании |
|---|---|---|
| Виртуальные пользователи | Исполнители сценария в инструменте | Действия, паузы и повторы каждого |
| RPS | Число запросов за секунду | Какие запросы учитываются и какой поток достигнут |
| Завершённые действия | Успешно пройденные операции сценария | Как проверяется результат операции |
Два запуска с одинаковым числом виртуальных пользователей могут дать разный поток запросов. В закрытой модели следующий цикл начинается после завершения предыдущего: замедление ответа меняет достигнутую интенсивность. В открытой модели начало новых итераций задаётся отдельно. Это различие описано в документации k6. Попросите исполнителя указать выбранную модель.
Подготовьте среду и данные до запуска
Отчёт должен объяснять, где проходила проверка: версия приложения, ресурсы, объём данных, настройки кэша и подключённые системы. Если стенд отличается от рабочего сайта, запишите отличия. Результат нельзя автоматически перенести на другую конфигурацию, умножив его на число процессорных ядер.
Продумайте, куда попадут тестовые заявки, заказы и уведомления. У интеграций с оплатой, CRM и сервисами сообщений должны быть согласованы тестовые режимы. Подмена внешнего сервиса заглушкой может помочь исследовать собственное приложение, но тогда взаимодействие с реальной интеграцией остаётся за пределами этого запуска. Это нужно указать в выводах.
Наблюдать стоит и за генератором запросов. Если он упирается в свои ресурсы, сайт может получать меньше нагрузки, чем задано в плане. В официальном руководстве JMeter возможность выполнить нужное число потоков прямо связана с оборудованием и устройством теста. Поэтому в отчёте нужны фактически достигнутые показатели, а не только настройки сценария.
Проверьте сценарий и договоритесь об остановке
До основной нагрузки выполните небольшой пробный запуск: проверьте, что сценарий проходит нужные шаги, данные подходят, проверки результата работают, а измерения собираются. Это проверка самого теста. Она не заменяет запуск на целевом уровне.
Заранее запишите условия остановки и ответственного за неё. Например, потеря данных или выход ошибок за согласованную границу требуют отдельного решения команды. Ждать полного отказа системы по умолчанию не нужно. Продолжительность и интенсивность задаются целью проверки, а не универсальной схемой из чужой статьи.
Настройки защиты входят в описание среды. Если для теста использованы отдельные правила доступа, результат относится к этим правилам. Не делайте вывод о работе обычного посетителя через рабочую защиту по запуску, где она не участвовала.
В руководстве Apache JMeter объясняется, от чего зависит возможность генератора выполнять заданное число потоков. Проверку этого ограничения стоит включить в подготовку.
Проверяйте действие, а не только код ответа
Ответ HTTP 200 ещё не доказывает, что посетитель получил нужный результат. Приложение может вернуть сообщение об ошибке внутри успешного HTTP-ответа. Для поиска важно содержание результата, для оформления заказа: подтверждение его создания. Проверки содержимого задают в сценарии отдельно.
В k6 проверка условия и критерий прохождения теста тоже различаются. Проверка может зафиксировать неуспех, но сама по себе не делает весь запуск проваленным. Для итогового решения задают thresholds. Иначе красивый итоговый статус легко прочитать неправильно.
Среднее время ответа полезно, но оно скрывает распределение задержек. Перцентиль p95 описывает границу для соответствующей доли измерений данного запуска, а не гарантирует скорость будущих обращений. Смотрите его вместе с числом измерений, ошибками, достигнутой интенсивностью и поведением отдельных действий. Допустимые значения согласуйте заранее для конкретного сценария, универсального порога для всех сайтов нет.
Например, p95 = 800 мс означает, что 95% измеренных запросов завершились за 800 мс или быстрее. Оставшиеся запросы могут занять больше времени. Это условная иллюстрация, а не рекомендуемая норма. Для сценария подтверждения записи и для поиска по каталогу допустимые значения могут различаться; их связь с задачей объясняют в отчёте.
Пример приёмки сервиса записи
Для сервиса записи критерий может звучать так: при согласованном потоке посетитель выбирает доступное время, получает подтверждение, а запись появляется в тестовой системе. Временную границу и допустимую долю неуспешных действий команда определяет до запуска. Если проверялась только выдача списка времени, утверждать, что весь путь записи выдержал нагрузку, нельзя.
Этот пример описывает способ сформулировать задачу. Он не является результатом выполненного проекта или готовой нормой для любого сайта.
Различие проверки содержимого и итогового критерия запуска разобрано в документации k6 о checks. В задании полезно явно разделить транспортную ошибку, неуспешную проверку результата и превышение допустимого времени.
Что должно остаться после проверки
Нужен воспроизводимый отчёт: цель, сценарии, параметры среды, профиль нагрузки, временной интервал, критерии, фактические показатели и обнаруженные ограничения. Скриншот графика без этих условий не позволяет уверенно сравнить результаты.
Причину замедления устанавливают по совокупности данных. Рост загрузки процессора, задержка ответа и ошибка приложения могут совпасть по времени, но одного такого совпадения недостаточно для вывода. Сопоставьте логи, показатели приложения, базы данных и инфраструктуры. В рекомендации отделите подтверждённую причину от предположения, которое ещё предстоит проверить.
После исправления повторите согласованный сценарий и укажите изменения среды. Если одновременно изменились данные, ресурсы и профиль нагрузки, сравнение «до и после» требует оговорок. Хороший итог отвечает на исходный вопрос бизнеса и честно обозначает границы проверки, а не обещает, что сайт теперь выдержит всё.
- Сохраните сценарий и параметры запуска, чтобы повторить проверку.
- Покажите заданную и фактически достигнутую нагрузку.
- Разделите успешные действия, ошибки и задержки по операциям.
- Укажите непроверенные интеграции и отличия тестовой среды.
- Для каждого исправления назовите способ проверки результата.
Если ограничение обнаружено в приложении, следующий шаг может потребовать доработки серверной логики. Сначала нужен разбор причины: увеличение ресурсов само по себе не подтверждает, что проблема решена.
В Гуси-Лебеди предлагаем принимать результат через исходный вопрос: какое действие проверено, при каких условиях оно прошло и что осталось выяснить. Тогда отчёт помогает решить, что исправлять и что проверять повторно, вместо обещания абстрактной «готовности к нагрузкам».