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

Postman вывел нагрузочное тестирование в облако: вы задаёте число виртуальных пользователей, а масштабирование, тюнинг и слияние результатов берёт на себя инфраструктура вендора. Тот же прогон можно поставить в CI и валить сборку по p95.

11.10.2026

// Новости

~ 7 мин. 4

Коротко о главном:

Облачные прогоны идут из инфраструктуры Postman, а не с вашего ноутбука: чистый baseline и повторяемость.
По умолчанию нагрузка идёт из региона аккаунта — США, для EU Data Residency — ЕС.
Локальные нагрузочные тесты бесплатны и без ограничений на всех планах, включая Free.
Облачные прогоны стоят $0.04 за VU-час на Solo, Team и Enterprise при pay-as-you-go.

Облачное нагрузочное тестирование Postman — это возможность запускать нагрузку не со своего ноутбука, а из управляемой инфраструктуры вендора. Вы задаёте число виртуальных пользователей (VU), а Postman сам подбирает машины, распределяет нагрузку и сводит метрики в один отчёт. Такой прогон можно запускать и вручную, и из CI-пайплайна.

Что даёт облачный запуск нагрузочных тестов

При локальном прогоне машина, с которой идёт нагрузка, сама становится частью теста: её CPU, Wi-Fi, VPN и канал связи стоят между генератором и API. Если цифры плохие, непонятно, тормозит API или ноутбук. К тому же два прогона в разные дни и в разных сетях нельзя честно сравнить.

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

Чистый baseline. Генератор нагрузки не конкурирует с почтой и браузером.
Реальный сетевой путь. Запросы идут через публичный интернет — так же, как к вам приходят удалённые пользователи и агенты.
Повторяемость. Одинаковая конфигурация раннера от прогона к прогону: изменение результатов означает изменение в API.
Масштаб. Облако Postman разгоняется до миллионов виртуальных пользователей.
Общие результаты. Каждый прогон, включая запуски из CI, попадает в Postman с историей и трендом.

Нагрузка идёт из региона вашего аккаунта Postman: по умолчанию США, для планов EU Data Residency — ЕС.

Что Postman берёт на себя

Облачные прогоны используют ту же коллекцию, что и локальные. Разница — в объёме работы, которую делать не нужно. Если собирать стенд самостоятельно, придётся выбирать машины, настраивать флот, делить между ними виртуальных пользователей и синхронизировать старт. В Postman достаточно указать --vu-count.

Дальше вендор закрывает ещё несколько задач:

Тюнинг машин. Лимиты файловых дескрипторов и портов, настройки TCP — всё уже готово в генераторах нагрузки.
Слияние результатов. Метрики со всех машин возвращаются одним прогоном: latency-перцентили, пропускная способность, доля ошибок.
Один инструмент. Коллекция, авторизация, датасет и условие прохождения работают и локально, и в облаке, и из CI — без переписывания. Локально остаются только data-файлы, mTLS-сертификаты и секреты Local Vault.
Setup и teardown. Флаги --setup-collection и --teardown-collection запускаются один раз до и после нагрузки, независимо от результата.
Фиксированные egress-IP. На Enterprise флаг --runner postman-cloud-static-ip отправляет нагрузку из выделенного кластера с постоянным IP.

Платите вы только за использованные VU-часы — держать простаивающие машины между тестами не нужно.

Почему нагрузочное тестирование стало важнее из-за ИИ-агентов

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

Поэтому форма нагрузки становится не менее важной, чем её размер. В Postman есть четыре профиля нагрузки (--load-profile), и каждый отвечает на свой вопрос:

fixed — выдерживает ли API постоянную конкурентность во времени.
ramp-up — где начинается деградация, когда агентов становится больше.
spike — что происходит, когда много агентов стартуют одновременно.
peak — выдержит ли API длительную работу near-maximum.

Профили задаются в минутах и работают по числу VU: rps — это метрика, по которой можно ставить гейт, а не скорость, которой вы управляете напрямую. Агенты не прощают медленных или нестабильных ответов: человек подождёт, агент уйдёт в таймаут, ретрай или другой путь. Поэтому p95 и доля ошибок становятся частью поведения продукта.

Реалистичные тесты с датасетами и гейт по p95 в CI

Отправлять один и тот же запрос тысячу раз бессмысленно: кэши отвечают быстро, горячие строки остаются в памяти. Подключите датасет, чтобы каждый виртуальный пользователь отправлял разные реальные данные. На планах Team и Enterprise датасет можно связать с живой базой MySQL, PostgreSQL или SQL Server — без выгрузки устаревших CSV. Для агентского трафика включайте длинные промпты, крупные payload, необычные комбинации параметров и немного некорректных запросов.

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

После входа по API-ключу и добавления условия прохождения тест становится гейтом:

команда запускает коллекцию из облака Postman с заданным числом VU и длительностью;
при превышении p95 заданного порога команда завершается с кодом 1 и валит job.

Гейт можно ставить на avg, p90, p95, p99, error_rate или rps. Флаг --output ndjson стримит результаты построчно — удобно для логов CI. Учтите: проверка происходит после прогона, поэтому неудачная сборка всё равно отправит полную нагрузку. На живых средах начинайте с небольшого числа VU и короткой длительности.

Когда локальный запуск всё ещё лучше

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

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

Для команд, у которых API-тесты уже живут в коллекциях Postman, это самый короткий путь к нагрузочному тестированию без переписывания сценариев. Подобрать подходящий план и оформить лицензию Postman Solo на 1 год или Postman Team на 1 год можно в каталоге «ЛегаСофт».

Кому будет полезно

QA- и SDET-командам, которым нужны воспроизводимые нагрузочные прогоны с общей историей результатов.
Backend- и платформенным командам, планирующим мощности под растущий агентский трафик.
DevOps-инженерам, которые хотят добавить гейт по p95 в CI и не держать собственный флот генераторов нагрузки.
Enterprise-заказчикам с требованиями к allowlist по IP — им пригодится статический egress-IP.

Если нужны фиксированные IP, интеграция с живыми базами данных и корпоративные требования к безопасности, стоит присмотреться к лицензии Postman Enterprise на 1 год.

Вопросы и ответы

Можно ли запускать нагрузочные тесты Postman из облака, а не со своего компьютера?

Да. Флаг --runner postman-cloud отправляет нагрузку из управляемой облачной инфраструктуры Postman. Без этого флага нагрузка идёт с той машины, где выполняется команда.

Сколько виртуальных пользователей может генерировать облако Postman?

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

Сколько стоит облачное нагрузочное тестирование Postman?

Локальные прогоны бесплатны и без ограничений на всех планах, включая Free. Облачные прогоны стоят $0.04 за VU-час на Solo, Team и Enterprise при включённом pay-as-you-go. Актуальные условия лицензий уточняйте у менеджеров «ЛегаСофт».

Купить лицензии Postman для компании можно в «ЛегаСофт»: подберём подходящую редакцию и срок подписки, оформим закрывающие документы для юридического лица и проконсультируем по внедрению. Оставьте заявку на сайте или свяжитесь с нашими менеджерами.