Как перенести тесты JMeter в Postman

9 ноября 2026 г.

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

Установите плагин Postman для вашего агента кодирования, укажите ему на ваш файл .jmx и попросите импортировать план. В результате вы получите коллекцию Postman, готовую к запуску команду performance run для Postman и отчет о том, что именно было импортировано, что было приближено к оригиналу и что требует ручной доработки. Затем проведите дымовое тестирование одной итерации, запустите нагрузочный тест и сравните перцентиль p95 и частоту ошибок с вашим последним запуском в JMeter.

Быстрый старт. Установите плагин для каждого агента кодирования на вашей машине (требуется Node.js 22 или более поздней версии):

Перезапустите агент, откройте его в папке с вашим файлом .jmx и вставьте следующее:

Нет Node.js? В десктопном приложении Postman нажмите Справка > Postman CLI и плагины > Установить плагин агента кодирования Postman. Другие варианты см. в разделе Установка плагина Postman.

Как выглядит типичный план JMeter до миграции?

Допустим, вы владеете файлом checkout-load.jmx. Он выполняет вход с помощью HTTP Basic, извлекает токен из ответа входа с помощью регулярного выражения (Regex Extractor) и отправляет этот токен в качестве заголовка Bearer при каждом последующем вызове. Утверждение продолжительности (Duration Assertion) вызывает сбой любого семпла, который работает медленнее вашего соглашения об уровне обслуживания (SLO). В нем есть набор данных CSV с тестовыми аккаунтами, построцессор Groovy JSR223, выполняющий пользовательское подписание, и постоянный таймер (Constant Timer) между шагами. Набор тестов запускается на выделенном компьютере после каждой ночной сборки.

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

Каковы ваши варианты отказа от JMeter?

Есть четыре разумных пути. Каждый из них подходит одним командам лучше, чем другим.

Ни один из них не является ошибочным. Правильный выбор зависит от того, какая доля ваших тестов работает по протоколу HTTP и насколько сильно вы хотите объединить функциональное и нагрузочное тестирование в одном месте.

Как перенести тесты JMeter в Postman?

Установите плагин Postman для вашего агента:

Это установит плагин во все поддерживаемые агенты, обнаруженные на вашей машине, включая Claude Code, Cursor, Codex и GitHub Copilot CLI. Требуется Node.js 22 или более поздней версии. Для установки только в один агент выполните npx @postman/postman-plugin install --agent cursor. Отдельного бинарного импортера нет, и после этого ничего не нужно настраивать вручную.

Откройте агент в каталоге с вашим файлом .jmx и отправьте этот промпт дословно:

Импортируйте checkout-load.jmx в Postman и дайте мне команду для запуска производительности.

Импортируйте checkout-load.jmx в Postman и дайте мне команду для запуска производительности.

Агент читает файл .jmx и следует правилам маппинга JMeter плагина. Вы получите три вещи:

• Коллекцию Postman в формате v2.1.
• Готовую к запуску команду postman performance run.
• Отчет об импорте с четырьмя разделами: Успешно импортировано, Приблизительно, Требуется ручная доработка и Не поддерживается.

Что импортируется точно?

Для такого плана оформления заказа, как ваш, переносятся без изменений: семплы HTTP-запросов (HTTP Request samplers), Менеджер заголовков (Header Manager), Дефолтные значения HTTP-запросов (HTTP Request Defaults), Базовая (Basic) и дайджест-аутентификация (Digest auth), Транзакционные и простые контроллеры (они становятся папками), Экстракторы регулярных выражений и границ (Regex and Boundary extractors), простые JSON-экстракторы, Утверждения ответов (Response Assertions), ваше Утверждение продолжительности (в виде pm.test плюс подсказка --pass-if p95), Пользовательские переменные (${var} становится {{var}}), __UUID, __time и неявная проверка успешности JMeter с кодами от 200 до 399.

Таким образом, ваш вызов входа сохраняет базовую аутентификацию (Basic auth). Экстрактор регулярных выражений, который захватывает токен, превращается в скрипт, сохраняющий его в переменную, и последующие запросы отправляют его в качестве Bearer-токена. Утверждение продолжительности сохраняется как проверка для каждого запроса, так и критерий успешности для всего запуска.

Что приближается (транслируется приблизительно)?

Группы потоков превращаются в виртуальных пользователей. Продолжительность запуска и один из четырех профилей нагрузки (фиксированный, с нарастанием, пиковый, скачкообразный) заменяют настройки нарастания нагрузки и планировщика JMeter. Количество циклов преобразуется в продолжительность. Условные контроллеры If и While транслируются с помощью максимально близкой логики. Утверждения размера и JSON, набор данных CSV (один файл) и __Random переносятся, но могут потребовать дополнительной проверки.

Дымовое тестирование, затем запуск нагрузочного теста

Прежде чем запускать нагрузочный тест, выполните прогон в одну итерацию:

Исправьте все, что завершится ошибкой. Отправьте коллекцию в рабочее пространство. Затем запустите нагрузочный тест:

Откуда должна исходить нагрузка?

План JMeter выполнялся на выделенном компьютере. Вам не нужно пересобирать этот компьютер. Добавьте --runner postman-cloud в ту же команду, и нагрузка будет поступать из управляемой облачной инфраструктуры Postman. Коллекция, конфигурация теста и способ отчетности о результатах остаются прежними.

Это дает вам три преимущества, которые не мог обеспечить компьютер с JMeter:

• Нагрузка выше, чем может дать одна машина. Облачный запуск генерирует нагрузку, выходящую за рамки того, что может произвести ваш ноутбук или раннер CI, без выноса теста из вашего пайплайна. Команда ожидает завершения выполнения и возвращает результат --pass-if в качестве кода выхода, поэтому установите тайм-аут вашей задачи CI по меньшей мере на время выполнения теста.
• Нагрузка, которой может доверять ваш брандмауэр. Если стейджинг пропускает только известные адреса, используйте --runner postman-cloud-static-ip. Нагрузка поступает из фиксированного набора IP-адресов в регионе вашей учетной записи (по умолчанию США или ЕС для планов хранения данных в ЕС), поэтому ваша команда безопасности добавляет их в белый список один раз. Текущие адреса находятся в docs.
• Результаты, которые видит вся команда. Каждый запуск записывается в Postman, поэтому любой участник рабочего пространства может открыть результаты и сравнить запуски.

Для облачного запуска изменяются две вещи. Ваш файл CSV переносится в dataset, так как параметр --data-file не может использоваться с облачными запусками. Секреты перемещаются в секретное хранилище Shared Vault, поскольку секреты Local Vault недоступны в облаке.

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

Не доверяйте импорту только потому, что он прошел тихо. Измерьте его.

Прочитайте отчет об импорте от начала до конца. Все, что находится в разделе «Приблизительно», — это то, что нужно проверить, а не то, что следует игнорировать. Запустите коллекцию один раз с помощью postman collection run и убедитесь, что каждый запрос зеленый с реальными учетными данными для вашей тестовой среды.

Затем сравните результаты «яблоки к яблокам». Запустите тест производительности Postman с тем же количеством виртуальных пользователей, которое ваш план JMeter использовал в последний раз. Извлеките ваш последний чистый результат JMeter и сравните перцентиль p95 и частоту ошибок. Ожидайте, что пропускная способность будет выше, чем в JMeter, поскольку таймеры не переносятся. Если p95 и частота ошибок находятся в том же диапазоне, корреляции и аутентификация работают. Если p95 сильно отличается, проверьте, не выполнял ли ваш старый план фоновую работу с таймерами ожидания больше, чем вы помнили.

Что не переносится из JMeter?

Будьте честны со своей командой относительно того, что не переносится:

• Таймеры и время ожидания (think time) не поддерживаются.
• Конкурентные группы потоков не поддерживаются; одна коллекция на запуск.
• Не-HTTP семплеры (JDBC, FTP, LDAP, TCP, Java) не поддерживаются.
• Аутентификация Kerberos и NTLM не поддерживается.
• Скрипты Groovy и BeanShell, экстракторы XPath и CSS, а также сложные JSONPath требуют ручной доработки.
• --data-file не может использоваться с облачными запусками. Вместо этого используйте набор данных.

Для плана оформления заказа вам нужно будет принять решение относительно двух элементов: постпроцессора Groovy JSR223 и таймера Constant Timer. Вы можете переписать логику подписи в виде сценария предварительного запроса Postman на JavaScript. Что касается Constant Timer, удалите его и позвольте профилю нагрузки формировать трафик.

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

Обязательно ли удалять тест-планы JMeter?

Нет. Процесс импорта считывает файл .jmx и создает коллекцию. Ваш исходный файл останется на месте. Команды обычно сохраняют оба варианта на пару релизов, запускают их параллельно и выводят набор тестов JMeter из эксплуатации, когда показатели p95 и частота ошибок совпадают. Если позже вам понадобится протокол, который Postman не поддерживает, ваш план JMeter останется доступен.

Что происходит с таймерами и паузами (think time) в JMeter?

Таймеры не поддерживаются, поэтому элементы Constant Timer или Gaussian Random Timer не перенесутся. На практике профиль нагрузки (разгон, всплеск, пик, фиксированная нагрузка) выполняет ту же работу по формированию трафика, для которой большинство команд использовали таймеры. Ожидайте более высокую пропускную способность по сравнению с прогонами в JMeter и сравнивайте p95 и частоту ошибок при одинаковом количестве виртуальных пользователей, а не запросов в секунду.

Можно ли запускать мигрированный нагрузочный тест в CI?

Да. Postman CLI поддерживает как postman collection run для функциональных проверок, так и postman performance run для нагрузочных. Добавьте обе команды на шаге GitHub Actions, в этап Jenkins или в задание GitLab. Настройте падение сборки по пороговым значениям с помощью параметра --pass-if. Добавьте --runner postman-cloud, чтобы генерировать нагрузку из облака Postman вместо CI-раннера.

Какой тарифный план Postman необходим для проведения тестов производительности?

Локальные запуск доступны на всех тарифах. Облачные запуск и статические IP-адреса доступны на платных тарифах. Для облачных запусков требуется минимум 10 виртуальных пользователей. Сначала проверьте тест локально, а затем добавьте --runner postman-cloud, когда вам потребуется большая нагрузка, чем может выдать одна машина, фиксированный набор исходных IP-адресов или результаты, доступные всей команде.

Можно ли задать продолжительность теста в секундах или добавить несколько критериев успешности?

Параметр --duration исчисляется целыми минутами, поэтому --duration 10 означает 10-минутный пропуск. Дробные минуты не принимаются, поэтому для коротких дымовых тестов округляйте значение в большую сторону. Для критериев успешности параметр --pass-if принимает метрику и пороговое значение, например "less_than(p95, 500)"; допустимыми метриками являются avg, p90, p95, p99, error_rate и rps.

Следующий шаг

Ознакомьтесь с полным справочником по конфигурации в разделе Конфигурация теста производительности и добавьте команду в ваше задание CI с флагом --runner postman-cloud. Сведения об опциях, специфичных для облака, см. в разделе запуск теста производительности в Postman Cloud.

Попробовать Postman

Ресурсы

• Установите плагин Postman: установите его в Claude Code, Cursor, Codex и другие агенты программирования одной командой из настольного приложения или через маркетплейс каждого агента.
• Конфигурация теста производительности Postman: полное руководство по postman performance run, профилям нагрузки и критериям успешности.
• Обзор Postman CLI: шаги установки и справочник команд для запуска коллекций и тестов производительности из CI.
• Написание тестовых скриптов в Postman: справочник по API pm.*, который вы будете использовать для замены постпроцессоров Groovy.
• Написание сценариев предварительного запроса в Postman: справочник по хуку pre-request, с помощью которого вы перенесете логику подписи из JSR223.
• Руководство пользователя Apache JMeter: канонический источник информации о семантике семплеров, контроллеров и ассертов на случай, если вам потребуется проверить приближенный элемент.