Облачное нагрузочное тестирование с Postman: от ноутбука до CI

9 октября 2026 г.

Облачное нагрузочное тестирование дает то, чего не может обеспечить ноутбук: распределение нагрузки между множеством машин, чистую базовую линию и результаты, доступные всей команде. Вы задаете количество виртуальных пользователей (VU). Postman берет на себя управление парком машин, настройку и объединение данных, а вы получаете набор показателей, которым можно доверять.

Большинство команд все еще начинают нагрузочное тестирование на ноутбуке, и это нормально. В этой статье рассказывается о том, что добавляет облако, почему это становится важнее по мере того, как AI-агенты превращаются в одних из самых активных потребителей ваших API, и как внедрить это в ваш конвейер (pipeline).

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

При локальном запуске машина, выполняющая нагрузочный тест, становится его частью. Ваш процессор, Wi-Fi, VPN и канал связи — все это находится между источником нагрузки и API. Когда показатели выглядят плохо, невозможно понять, медленно ли работает API или ваш ноутбук. Кроме того, на ноутбуке быстро заканчиваются ресурсы: увеличение нагрузки требует повышения лимитов ОС и настройки TCP, что может иметь побочные эффекты и требовать прав администратора, которых у вас может не быть. А два запуска в разные дни и в разных сетях не поддаются объективному сравнению.

Облачный запуск отправляет трафик из инфраструктуры Postman. Вы получаете:

• Чистую базовую линию. Генератор нагрузки не конкурирует за ресурсы с вашим почтовым клиентом.
• Реальный сетевой путь. Запросы приходят через общедоступный интернет, так же, как к вам обращаются удаленные пользователи и агенты.
• Воспроизводимость. Одинаковая конфигурация исполнителя (runner) каждый раз, поэтому изменение результатов означает изменение в вашем API.
• Масштабируемость. Облако Postman масштабируется до миллионов виртуальных пользователей. Часовой тест при 2000 одновременных пользователей — это не предел.
• Общие результаты. Каждый запуск, включая запуски из CI, сохраняется в Postman с историей и трендами. Вся ваша команда видит одни и те же цифры.

Нагрузка исходит из региона вашего аккаунта Postman: по умолчанию из США или из ЕС в планах с поддержкой Data Residency.

Что берет на себя облако Postman

Облачные запуски используют ту же коллекцию, что вы запускаете локально. Разница заключается в работе, которую вам больше не нужно выполнять. (О том, как это работает «под капотом», см. «Нагрузочное тестирование в облаке с Postman: что мы построили».) Вот что вы делаете сами, если настраиваете все с нуля, и что вам не нужно делать с Postman.

Масштабирование. Самостоятельно: вы подбираете размер машин, настраиваете парк, распределяете виртуальных пользователей и синхронизируете запуск всех машин. С Postman: вы задаете --vu-count. Postman выбирает машины и распределяет нагрузку между ними.

Настройка машин. Самостоятельно: каждый генератор нагрузки требует увеличения лимитов файловых дескрипторов и портов, а также настройки TCP. Эти параметры нужно вносить в образ и поддерживать одинаковыми для всего парка. На ноутбуке или ограниченной в правах машине вы, возможно, вообще не сможете их изменить. С Postman: генераторы нагрузки уже готовы к работе.

Объединение результатов. Самостоятельно: вы собираете вывод с каждой машины и объединяете его. Правильный расчет перцентилей требует дополнительных усилий, и вам нужна панель мониторинга для их отображения. С Postman: метрики со всех машин приходят как один результат с расчетом перцентилей задержки в реальном времени и итоговыми данными по пропускной способности и уровню ошибок.

Один тест, один инструмент. Самостоятельно: скрипты нагрузки живут в отдельном инструменте, отдельно от коллекций API, которые уже поддерживает ваша команда. С Postman: коллекция, поток авторизации, набор данных и условия прохождения, которые вы используете для локального тестирования, работают в облаке и из CI. Ничего не нужно переписывать. Некоторые вещи остаются только локальными: файлы данных, клиентские сертификаты mTLS и секреты Local Vault. Для облачных запусков используйте наборы данных и секреты Shared Vault.

Настройка и очистка (Setup and teardown). Самостоятельно: вы пишете отдельные скрипты для подготовки и сброса тестовых данных до и после нагрузочного теста. С Postman: --setup-collection выполняется один раз перед началом нагрузки, а --teardown-collection — один раз после завершения, независимо от результата. Они запускаются как отдельные этапы, вне фазы нагрузки.

Фиксированные исходящие IP-адреса. Самостоятельно: вы запускаете NAT-шлюзы или зарезервированные IP и обновляете списки разрешенных адресов при каждом изменении парка. С Postman: в тарифе Enterprise параметр --runner postman-cloud-static-ip отправляет нагрузку из выделенного кластера с фиксированным исходящим IP, который вы добавляете в белый список один раз.

Ничего не нужно поддерживать. Самостоятельно: вы обновляете образы, обновляете исполнитель тестов, выключаете машины после каждого теста и платите за мощности, которые простаивают между тестами. С Postman: вы платите только за использованные VU-часы.

Почему AI-агенты делают нагрузочное тестирование еще важнее

Человеческий трафик имеет свою специфику. Люди кликают, читают и кликают снова. Трафик агентов — нет.

Агенты быстро становятся основной аудиторией для API, и они ведут себя не так, как люди. Агент, выполняющий одну задачу, может вызывать ваш API много раз подряд. Он может вызывать несколько эндпоинтов одновременно. Он не делает перерывов и не соблюдает рабочие часы. Один запрос пользователя может превратиться в десятки вызовов API, и множество пользователей, делающих это одновременно, могут создать нагрузку, которую вы не учитывали при планировании мощностей.

Это делает профиль нагрузки таким же важным, как и ее объем. Нагрузочное тестирование в Postman имеет четыре профиля нагрузки (–load-profile), и каждый из них соответствует вопросу о трафике агентов:

• fixed (фиксированный): Может ли API поддерживать стабильную конкурентность в течение долгого времени? Количество VU остается постоянным. Это ваша базовая линия для агентов, работающих весь день.
• ramp-up (плавное увеличение): Где начинаются деградация при подключении новых агентов? Количество VU растет с 25% до 100%, затем удерживается. Используйте это, чтобы найти «колено» на графике до того, как его найдут ваши пользователи.
• spike (всплеск): Что произойдет, когда много агентов начнут работу одновременно, например, при запуске запланированного задания или релизе? VU начинаются с 10%, прыгают до 100%, затем падают обратно до 10%.
• peak (пик): Может ли система выдержать работу при максимальной нагрузке? VU растут с 20% до 100%, удерживаются, затем снижаются до 20%. Агенты не уходят домой, поэтому пиковая нагрузка может длиться часами.

Каждый профиль — это фиксированный шаблон на протяжении всей длительности запуска, которую вы задаете в минутах. Профили основаны на VU: RPS — это то, что вы можете ограничивать, а не скорость, с которой вы создаете нагрузку. Если ваша команда обсуждает нагрузочные и стресс-тесты, статья «Performance testing vs. load testing vs. stress testing» объясняет, как эти термины соотносятся.

Агенты также не прощают медленных или нестабильных ответов. Человек подождет. Агент выдаст тайм-аут, повторит попытку или выберет другой путь. Поэтому ваш p95 и уровень ошибок становятся характеристиками продукта.

Почему здесь важно облако? Нагрузка от агентов может быть большой, стабильной и длительной. Ноутбук первым упрется в свои собственные ограничения. Облачный запуск распределяет нагрузку между машинами и продолжает работу столько, сколько нужно для теста.

Один момент, который стоит учесть. Облачные запуски происходят из диапазонов IP-адресов Postman. Если ваш API использует белый список IP или ограничивает количество запросов на IP, используйте исполнитель со статическим IP (Enterprise) и добавьте его в белый список. В противном случае ваш нагрузочный тест будет тестировать ваш файрвол, а не ваш API.

Делайте нагрузочные тесты реалистичными с помощью наборов данных

Отправка одного и того же запроса тысячу раз вводит в заблуждение: кэши отвечают быстро, а «горячие» строки остаются в памяти.

Прикрепите набор данных, чтобы каждый виртуальный пользователь отправлял разные реальные входные данные. Наборы данных работают одинаково, где бы ни происходил запуск, что делает их правильным выбором для облачных и CI-запусков. Вы можете подключить набор данных к работающей базе данных MySQL, PostgreSQL или SQL Server в планах Team и Enterprise, чтобы не экспортировать устаревшие CSV-файлы. Для пользовательских источников JDBC требуется Enterprise. Используйте тестовую или промежуточную копию, либо учетную запись только для чтения с анонимизированными данными.

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

Как добавить нагрузочное тестирование в CI с пороговым значением p95?

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

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

Если вы еще не настроили CLI, начните с раздела «Работа с Postman CLI». Затем войдите в систему с помощью ключа API, добавьте условие прохождения, и тест станет «воротами» (gate):

postman login --with-api-key "$POSTMAN_API_KEY"

postman performance run <collectionId> \ --runner postman-cloud \ --load-profile ramp-up \ --vu-count 50 \ --duration 10 \ --pass-if "less_than(p95, 500)" \ --output ndjson

Эта команда запускает коллекцию из облака Postman с 50 виртуальными пользователями в течение 10 минут. Она завершается с кодом 1 и проваливает сборку, если задержка p95 превышает 500 мс. Проверка происходит после выполнения, поэтому неудачная сборка все равно отправляет полную нагрузку до того, как сработает ограничение. Начинайте с небольшого количества виртуальных пользователей и короткой длительности для любых рабочих сред.

Вы можете установить пороговые значения для avg, p90, p95, p99, error_rate или rps, используя less_than, less_than_eq, greater_than или greater_than_eq. Параметр –output ndjson выводит результаты в формате JSON, разделенном символами новой строки, что удобно для логов CI и кодирующих агентов, где терминальная панель не может отобразить данные.

Когда локальное нагрузочное тестирование — правильный выбор

Локальное нагрузочное тестирование быстрое и бесплатное на любом тарифе. Это лучший выбор, когда вы только создаете тест, когда API находится на localhost, за VPN или брандмауэром, когда требуется mTLS или когда вы проверяете dev-сборку на наличие очевидных проблем, таких как медленный запрос или утечка памяти. Не платите за то, что вам не нужно.

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

Когда лучше использовать инструмент, ориентированный на скрипты?

Postman — это кратчайший путь, если ваши API-тесты уже живут в коллекциях Postman и вы хотите проводить нагрузочное тестирование без их переписывания. Инструмент для нагрузочного тестирования, ориентированный на код, может подойти лучше, если вам нужно:

• Посекундное формирование профиля нагрузки, например, от 50 до 3000 клиентов ровно за 30 секунд.
• Модель интенсивности поступления запросов (arrival-rate), которая задает целевое количество запросов в секунду вместо количества виртуальных пользователей.
• Чтобы сам нагрузочный тест, а не только шаг конвейера, был обычным файлом скрипта в вашем репозитории.

Попробуйте

Возьмите коллекцию, которую вы уже запускаете локально. Прикрепите набор данных. Запустите ее один раз локально и один раз в облаке, а затем сравните результаты. Разница — это то, что скрывал ваш ноутбук. Как только вы начнете доверять цифрам, добавьте строку --pass-if в ваш конвейер.

Часто задаваемые вопросы

Может ли Postman запускать нагрузочные тесты из облака, а не только с моего компьютера? Да. Команда postman performance run <collectionId> --runner postman-cloud отправляет нагрузку из управляемой облачной инфраструктуры Postman. Без параметра --runner нагрузка идет с машины, на которой выполняется команда.

Нужно ли для нагрузочного тестирования в Postman настольное приложение? Нет. Postman CLI запускает нагрузочные тесты в фоновом режиме в любой системе CI. Настольное приложение — это один из способов настройки теста, а не требование для его запуска.

Сколько виртуальных пользователей может сгенерировать Postman? Облако Postman масштабируется до миллионов виртуальных пользователей. Для облачных запусков требуется минимум 10. Локальный запуск ограничен мощностью машины, на которой он выполняется.

Могу ли я провалить сборку CI, если задержка p95 слишком высока? Да. Добавьте --pass-if "less_than(p95, 500)". Команда завершается с кодом 1, если условие не выполнено, что приводит к сбою задания CI. Это работает как для локальных, так и для облачных запусков.

Является ли нагрузочное тестирование в Postman бесплатным? Локальные нагрузочные запуски безлимитны на всех тарифах, включая Free. Облачные запуски стоят $0.04 за виртуальный пользователь-час на тарифах Solo, Team и Enterprise при включенной оплате по мере использования.

Могу ли я добавить генераторы нагрузки Postman в белый список брандмауэра? Да, на тарифе Enterprise. Параметр –runner postman-cloud-static-ip отправляет нагрузку из кластера со статическим IP в регионе вашего аккаунта (США или ЕС для планов с хранением данных в ЕС).

Откуда облачные запуски отправляют нагрузку? Из региона вашего аккаунта Postman: по умолчанию из США или из ЕС для планов с хранением данных в ЕС. Каждый запуск использует один раннер, поэтому вы не можете объединить локальную и облачную нагрузку в одном запуске.