27 октября 2026 г.
Ваша коллекция для проверки оформления заказа выполняет вход, добавляет товар, применяет купон и проверяет ответ. Она успешно проходит на каждом пулл-реквесте. Затем кто-то просит провести нагрузочное тестирование, и план превращается в создание второго набора тестов в совершенно другом инструменте. С этим сталкивается большинство наших клиентов, и именно поэтому мы создали функционал тестирования производительности в Postman.
Одна и та же коллекция может служить одновременно и функциональным тестом, и тестом производительности. Просто настройте конфигурацию теста производительности, такую как виртуальные пользователи, профиль нагрузки и длительность. Ваши существующие проверки в коллекции будут выполняться под нагрузкой. Вы также можете настроить блокировку сборки по перцентилю p95 для задержки или по уровню ошибок.
Тесты производительности Postman можно запускать на вашем ноутбуке в процессе разработки или развертывать в облаке для поддержки до 1 миллиона виртуальных пользователей (VU), а также интегрировать в CI в качестве условий блокировки сборки.
Как нагрузочное тестирование в Postman выглядит на практике?
Допустим, у вас есть коллекция для оформления заказа. Она выполняет вход, добавляет товар, применяет купон, обращается к /checkout и проверяет ответ с помощью нескольких проверок pm.test(). Она зеленеет на каждом PR. Ваше правило релиза: «p95 ниже 500 мс при 200 VU».
При нагрузочном тестировании в Postman та же самая коллекция становится нагрузочным тестом. Вы направляете на нее исполнитель тестов производительности (performance runner), указываете нужное количество виртуальных пользователей и продолжительность, и каждый VU циклически и параллельно проходит коллекцию. Скрипты выполняются. Проверки pm.test() выполняются. Шаг входа по-прежнему извлекает токен привычным образом. Вам не нужно переписывать что-либо на другом DSL и поддерживать вторую копию схемы авторизации.
Вы можете запустить его из приложения Postman, Postman CLI или в Postman Cloud. Коллекция остается тем же самым артефактом во всех трех случаях.
А как же k6, JMeter, Gatling, Locust или ReadyAPI?
Все они — отличные инструменты. Честное сравнение сводится к тому, что именно вам придется поддерживать параллельно.
Вопрос не в том, какой инструмент лучше сам по себе. Вопрос в том, стоит ли создавать второй набор тестов, если первый уже описывает ваше API.
Как на самом деле запустить тест?
Начните локально. Откройте терминал и выполните:
--peak-vu задает количество виртуальных пользователей. --duration измеряется в целых минутах. --load-profile принимает значения fixed (постоянная), ramp-up (плавное увеличение), spike (всплеск) или peak (пик). --pass-if оценивает результаты после завершения теста по одному из параметров: avg, p90, p95, p99, error_rate или rps.
Код возврата имеет значение для CI. Когда условие --pass-if не выполняется, команда возвращает ненулевой код выхода. Без --pass-if команда всегда возвращает 0. Поэтому, если вы хотите, чтобы CI действительно прерывал сборку, передайте условие проверки.
Вот этот же шаг в рабочем процессе GitHub Actions:
Если значение p95 превышает 500 мс, шаг завершается с ненулевым кодом, и PR становится красным. Та же коллекция, те же проверки, новый барьер.
Откуда должна поступать нагрузка?
Локальные запуск отлично подходят для этапа разработки. Емкость зависит от вашей машины, что хорошо для дымового теста, но может не дотягивать до уровня производственного трафика.
Для создания более высокой нагрузки добавьте --runner postman-cloud к той же команде. Нагрузка распределяется по машинам Postman, поэтому вы получаете большую пропускную способность, чем может дать один ноутбук, и вам ничего не нужно настраивать. Команда по-прежнему возвращает результат --pass-if в качестве кода выхода, поэтому ваша задача CI может использовать его для блокировки точно так же. Обратите внимание на один нюанс: установите таймаут задания CI по меньшей мере равным длительности теста, иначе CI может отменить задание до того, как придут результаты.
Если ваше API скрыто за списком разрешенных IP-адресов (allowlist), используйте --runner postman-cloud-static-ip. Вы получаете фиксированные IP-адреса в регионе вашей учетной записи (США или ЕС для режима хранения данных в ЕС), которые можете добавить в этот список. В документации по статическим IP-адресам приведен актуальный список для вашего региона.
Несколько замечаний о данных. Результаты облачных запусков сохраняются в Postman для рабочего пространства, поэтому ваша команда сможет просмотреть результаты после тестирования и сравнить их. Файлы данных переносятся из параметра --data-file в набор данных (dataset), который работает везде, где выполняется команда. Секреты перемещаются в секреты Shared Vault. Локальные секреты из Local Vault недоступны при облачных запусках.
Как понять, что всё сработало?
Откройте результат выполнения в Postman, и вы увидите представление метрик: p90, p95, p99, среднее значение, процент ошибок (error %) и процент неудач (failure %). Процент ошибок считает запросы, завершившиеся сбоем. Процент неудач считает проверки pm.test(), которые не прошли под нагрузкой. Эти два показателя рассказывают разные истории, и важны оба.
Тепловая карта «Тесты и VU» показывает количество виртуальных пользователей, при котором проверки начинают давать сбои. Вы также можете сравнить два запуска бок о бок, что удобно, когда вы пытаетесь доказать, что исправление действительно улучшило показатель p95.
Каковы ограничения нагрузочного тестирования в Postman?
Несколько вещей, о которых стоит знать заранее:
- Модель основана только на виртуальных пользователях (VU). Вы выбираете количество виртуальных пользователей, а не целевое количество запросов в секунду (RPS). Если вам нужно мыслить в терминах RPS, RPS calculator at postman.com/tools послужит хорошей отправной точкой для конвертации одного значения в другое.
- Один регион на учетную запись. Облачные запуски выполняются из региона, привязанного к вашей учетной записи.
- Конфигурация теста не является файлом в Git. Команда CLI выступает в роли «конфигурации как кода» (config-as-code), а флаги, которые вы фиксируете в файле рабочего процесса, являются источником правды.
- --pass-if выполняет проверку по задержке, ошибкам и пропускной способности. Этот параметр не проверяет сбои проверок pm.test(). Если для вас главным сигналом являются сбои проверок под нагрузкой, следите за процентом неудач (failure %) в окне результатов.
- Только HTTP-запросы. Генерация нагрузки для gRPC, подписок GraphQL или WebSocket не поддерживается.
- Нет встроенного экспорта в Grafana, Datadog или OpenTelemetry. Результаты хранятся в рабочем пространстве.
Часто задаваемые вопросы
Может ли Postman провалить сборку CI на основе результатов нагрузочного теста?
Передайте параметр --pass-if с метрикой и порогом, например "less_than(p95, 500)" или "less_than(p99, 800)". Когда после выполнения теста условие не выполняется, CLI возвращает ненулевой код, и шаг CI завершается ошибкой. Без --pass-if команда всегда возвращает 0, поэтому сборка остается успешной. Такой же механизм работает и с --runner postman-cloud; задайте таймаут задания CI по крайней мере равным продолжительности теста.
Является ли нагрузочное тестирование в Postman бесплатным?
Локальные запуски доступны на всех тарифных планах. Облачные запуски и статическиe IP-адреса доступны на платных тарифах. Для облачных запусков требуется минимум 10 виртуальных пользователей, а локальная емкость зависит от вашего компьютера. Если вы хотите попробовать быстрый нагрузочный тест без регистрации, доступны бесплатный тест нагрузки API без регистрации (100 VU, 60 с, только GET) и калькулятор RPS на странице .
Стоит ли мне конвертировать мою коллекцию Postman в k6?
k6 — мощный инструмент, особенно если ваша команда уже пишет тестовый код на JavaScript и нуждается в исполнителях с заданной интенсивностью поступления запросов (arrival-rate executors). Вопрос в том, стоит ли поддерживать второй набор тестов, если ваша коллекция Postman уже определяет запросы, авторизацию и проверки. Если вам нужна именно модель k6, используйте ее. В противном случае запуск уже имеющейся коллекции обычно требует меньше усилий.
Как соотносятся виртуальные пользователи (VU) и запросы в секунду (RPS)?
Виртуальные пользователи циклически и параллельно проходят коллекцию, поэтому RPS зависит от того, сколько времени занимает один полный цикл. 50 VU на коллекции из четырех запросов, выполнение которой занимает 2 секунды на цикл, отправляют около 100 запросов в секунду. Чтобы достичь определенного значения RPS, рассчитайте его в обратном порядке от среднего времени цикла или воспользуйтесь калькулятором RPS на сайте postman.com/tools. Полную методику расчета см. в статье «Сколько виртуальных пользователей вам нужно для нагрузочного теста?» (How many virtual users do you need for a load test?).
Как работают наборы данных (datasets) и секреты при облачных запусках?
Наборы данных работают везде, где выполняется запуск — локально или в облаке, поэтому набор данных, прикрепленный к запуску, доступен каждому VU. С секретами дело обстоит иначе. Локальные секреты Vault недоступны при облачных запусках; их нужно сохранить как секреты Shared Vault, чтобы облачные исполнители могли их прочитать. Перенесите учетные данные перед переключением исполнителя.
Каков следующий шаг?
Начните с локального запуска на любом тарифном плане, а затем добавьте флаг --runner postman-cloud, когда потребуется большая нагрузка, чем может создать одна машина.
Все подробности приведены в документации по конфигурации тестов производительности.
