Performance testing исследует, как быстро система выполняет полезную работу, насколько стабильно делает это под нагрузкой и где достигает ограничений. Для QA это способ ответить на продуктовые вопросы: выдержит ли каталог рекламную кампанию, останется ли оформление заказа отзывчивым, что произойдёт при росте очереди.
Сам по себе запуск тысячи виртуальных пользователей ничего не доказывает. Результат появляется, когда известны профиль нагрузки, критерии качества, состояние окружения и фактически выполненная работа. График CPU без этой информации легко приводит к неверному выводу.
Какой вопрос должен быть у теста
Начни с одной проверяемой гипотезы. Например: новая версия поиска выдерживает ожидаемый пик без ухудшения p95 и доли успешных результатов. Или: после краткого всплеска система возвращается к обычной скорости без ручного перезапуска.
Вместе с командой определи критерии и окно измерения. Учебный пример: при 100 поисковых запросах в секунду на протяжении 20 минут p95 полного времени запроса меньше 500 мс, технических ошибок меньше 1%, корректность содержимого проверена. Эти числа иллюстрируют формулировку; требования вашего продукта могут быть другими.
Из чего складывается модель нагрузки
Нужны сценарии, их доли, интенсивность, длительность и распределение данных. Каталог из 80% просмотров и 20% поиска ведёт себя иначе, чем поток одинаковых запросов к одной популярной карточке. Учитывай авторизацию, think time, кэш, размер ответа и повторные обращения.
Опирайся на аналитику или явно записанные предположения. Отдельно укажи, создаёт ли тест новые соединения, повторно использует сессию и выполняет retries. Один бизнес-сценарий может включать несколько HTTP-запросов: 100 начатых покупок в секунду не равны 100 RPS.
Открытая и закрытая модели
В закрытой модели фиксированные виртуальные пользователи начинают следующую итерацию после завершения предыдущей. При замедлении сервиса интенсивность запросов может снижаться. Это подходит для некоторых моделей ограниченной пользовательской популяции, но способно скрыть проблему при независимом внешнем потоке. Такое согласованное снижение потока при замедлении сервиса связано с проблемой coordinated omission: часть ожидаемой работы не попадает в измерения.
В открытой модели новые итерации запускаются по заданному расписанию независимо от завершения предыдущих. Выбирай модель по вопросу теста. Если требуется сохранять интенсивность поступления, проверь, что генератор действительно её обеспечивает; пропущенные старты и нехватка ресурсов делают вывод об устойчивости сервера неполным.
Окружение и тестовые данные
Зафиксируй сборку, инфраструктуру, лимиты, autoscaling, конфигурацию базы и состояние зависимостей. Укажи, какие сервисы реальны, а какие заменены. Мгновенный mock платёжной системы меняет время сценария и распределение занятых ресурсов.
Подготовь достаточное число аккаунтов и объектов, чтобы тест не упирался в уникальность данных и искусственные блокировки одного пользователя. Одновременно нужны реалистичные крупные аккаунты и перекос популярности. Слишком маленький набор целиком помещается в кэш и создаёт результат, который не повторится на реальных данных.
Почему сначала нужен маленький прогон
При минимальной нагрузке проверь сам сценарий: токены действительны, найден нужный объект, тело ответа соответствует ожиданию, создаваемые сущности имеют корректные связи. HTTP 200 с пустым результатом из-за неправильного фильтра не подтверждает успешный поиск.
Сверь количество операций с серверными метриками и подготовленными данными. Если сценарий заказа обрывается на авторизации, масштабирование лишь создаст больше неудачных логинов. Небольшой smoke позволяет быстро исправить сценарий и проверить сбор телеметрии до дорогого эксперимента.
Практический пример: новая версия поиска
Подготовь 10 000 поисковых фраз с реалистичной частотой повторения и известными проверками для выбранных запросов. Сначала измерь базовую версию, затем новую в одинаковой конфигурации. Раздели прогрев и стабильное окно; не прячь первое включение кэша в средний результат.
- →Подними интенсивность до 100 запросов в секунду по согласованному профилю.
- →Удерживай стабильное окно 20 минут и фиксируй фактическую частоту стартов, завершений и ошибок.
- →Сравни p50, p95, p99, корректность ответов, очередь, CPU, память и ожидания базы.
- →После снижения нагрузки проверь возврат задержек и очередей к исходному состоянию.
Если новая версия даёт p95 420 мс, но 3% запросов возвращают некорректную пустую выдачу, тест не проходит. Если генератор выполнил только 60 из требуемых 100 запросов в секунду, нельзя утверждать выполнение критерия нагрузки.
Как искать ограничение
Сопоставляй клиентские симптомы с серверными сигналами по общему времени и идентификаторам. Рост задержки вместе с ожиданием соединения с базой задаёт гипотезу о пуле, но не доказывает её сам по себе. Низкий общий CPU также не исключает очередь, блокировку или ограничение внешнего сервиса.
Изменяй одну существенную переменную за эксперимент. После увеличения пула проверь, не перенеслась ли очередь в базу и не ухудшились ли другие сценарии. Цель анализа — найти механизм деградации, а не выбрать самый заметный график.
Что должно быть в отчёте
Опиши цель, профиль, окружение, данные, критерии, фактическую нагрузку и ограничения. Покажи распределение времени вместе с ошибками и полезной пропускной способностью. Для найденного порога укажи, какой критерий нарушился первым и восстановилась ли система.
Типичные ошибки: среднее вместо хвостов, общий процент по разным операциям, скрытые retries и сравнение несопоставимых прогонов. Один удачный тест не превращается в гарантию для всех нагрузок. После исправления повторяй релевантный эксперимент в тех же условиях, а дополнительные прогоны выбирай по изменившемуся риску.
Что должен вынести QA из этой темы
Производительность проверяется через полезную работу при известных условиях. Сценарий должен быть корректным, генератор — обеспечивать заявленную нагрузку, критерии — появляться до запуска. Хороший вывод объясняет, что выдержала система, где началась деградация и какие данные подтверждают результат.