Newman — инструмент командной строки для выполнения Postman-коллекций в формате v2.1 JSON. Он встречается в существующих API-проектах и CI, поэтому QA полезно уметь читать его команды и разбирать результаты. При этом на октябрь 2026 года официальная документация объявляет Newman устаревшим и больше не поддерживаемым. Он не выполняет коллекции v3 из новых рабочих процессов Postman v12; для дальнейшего развития Postman рекомендует собственный CLI.
Что Newman исполняет на самом деле
Входом служат коллекция, параметры окружения, необязательные данные итераций и настройки запуска. Результат — отправленные запросы, выполненные assertions, ошибки и отчёты. Newman не превращает произвольные запросы в тесты: если коллекция не проверяет бизнес-значения, runner их не добавит. Успешное завершение процесса означает только то, что исполнение удовлетворило заложенным проверкам. Коллекция без assertions может дать зелёный результат при совершенно неверном поведении продукта.
Когда поддерживать существующий запуск
Если команда уже имеет стабильную v2.1-коллекцию, разумно сначала зафиксировать её поведение и ограничения, затем планировать переход. Не стоит одновременно менять runner, тестовые данные и весь контракт: станет сложно понять причину расхождения. Для нового проекта сначала оцени актуальный Postman CLI или подходящий тестовый фреймворк. Выбор зависит от требований к исполнению, данным и сопровождению, а привычное название Newman само по себе не является аргументом.
Воспроизводимые зависимости и входные файлы
Храни runner как зависимость проекта, зафиксируй lock-файл и используй поддерживаемую организацией версию Node.js, совместимую с этим runner. В CI устанавливай зависимости через npm ci. В репозитории должны лежать коллекция, безопасный шаблон окружения, тестовые данные и инструкция запуска. Секреты поступают из предназначенного хранилища CI в временную конфигурацию; такой файл не включают в артефакты и удаляют после работы. Не передавай настоящий токен в публичной команде или примере.
Ниже пример для проекта, где Newman уже установлен и закреплён. Файл environment.runtime.json формируется перед запуском, а папка reports создана заранее. Команды выполняют последовательно; это иллюстрация существующего pipeline, а не рекомендация начинать новый проект с устаревшего runner.
npm ci
npx --no-install newman run collections/orders.v2.1.json \
-e environment.runtime.json \
-d data/orders.json \
--reporters cli,junit \
--reporter-junit-export reports/orders.xmlПрактика: API smoke в pipeline
Пусть коллекция создаёт тестовый заказ, читает его и удаляет либо помечает для уборки. Входные данные содержат известный товар и количество, окружение указывает тестовый API, а сборка доступна по зафиксированному адресу. Цель запуска — быстро обнаружить потерю критической интеграции после развёртывания, а не покрыть все случаи заказа.
- 1.Проверь доступность зависимостей и подготовь отдельный маркер запуска. Ожидается, что созданные данные можно отличить от данных других jobs.
- 2.Выполни коллекцию с проверками статусов, идентификатора, суммы и последующего чтения. Ожидается согласованный бизнес-результат, подтверждённый assertions.
- 3.Сохрани код завершения и JUnit-отчёт даже при падении. Ожидается красная job и понятное место сбоя; публикация отчёта не должна скрывать ошибку запуска.
- 4.Намеренно измени ожидаемую сумму в отдельной проверочной ветке. Ожидается падение assertion и pipeline; затем верни корректное значение.
- 5.Проверь уборку при частичном сбое. Ожидается отсутствие накопления тестовых заказов, даже если чтение упало после успешного создания.
Данные итераций и изоляция
Data-файл удобен для нескольких граничных значений, но каждая строка не обязательно означает независимый тест. Если скрипты сохраняют id и токены в общей области, итерации могут использовать чужое состояние. Очищай временные значения перед созданием объекта, не полагайся на порядок старых запусков и явно задавай ожидаемый результат каждой строки. Успешные и негативные сценарии полезно разделить, когда для них различаются подготовка, assertions и правила последующей очистки.
Код завершения и смысл зелёной job
Проверь код процесса реальным падающим assertion, сетевой ошибкой и отсутствующим входным файлом. Не применяй --suppress-exit-code, если pipeline должен блокировать изменение при сбое. Опция --bail меняет поведение остановки, но раннее прекращение может пропустить завершающую очистку. Сам факт появления XML не означает успех: отчёт может содержать failures. И наоборот, ошибка публикации артефакта не всегда означает дефект API. Эти причины в сообщениях pipeline должны различаться.
Совместимость с Postman
Обязательно проверь формат коллекции и функции скриптов. Newman не поддерживает v3 и скрипты из Postman Package Library; интерактивное получение OAuth-токена также нельзя считать переносимым из приложения в headless-запуск. Для такого сценария отдельно проектируют получение пригодных credentials и их обновление. Не обходи проблемы совместимости постоянным отключением TLS-проверки или копированием токена из личной сессии сотрудника. Это скрывает причину и делает ночные результаты непредсказуемыми.
Для сетевой диагностики отделяй невозможность установить соединение от ответа сервиса с ошибкой. Сверь разрешение имени, proxy и сертификат в среде job, затем повтори один безопасный запрос. Не добавляй автоматический retry ко всем изменяющим операциям: после потери ответа сервер уже мог создать объект. Если повторы нужны, их семантику согласуют с контрактом и проверяют на отдельных тестовых данных. Runner не может самостоятельно определить, безопасно ли повторить конкретную бизнес-операцию.
Как переходить на Postman CLI
Сохрани эталонный запуск одной v2.1-коллекции: список запросов, названия assertions, итоговые статусы и созданные данные. Выполни тот же сценарий новым runner в том же контролируемом окружении. Сравни обработку переменных, scripts, данных итераций, кодов завершения и отчётов. После подтверждения замени команду в одной job и наблюдай несколько штатных прогонов. Миграцию формата v3 проводи отдельно, сохраняя проверяемую историю изменений и инструкцию воспроизведения.
Разбор падений и практический вывод
Начинай с первой содержательной ошибки. Последующие 404 могут быть следствием неудачного создания, а timeout — недоступного стенда. В отчёт добавляй commit, сборку, окружение, версию runner и очищенную диагностику; не прикладывай весь runtime-файл с секретами. Частые ошибки — случайно обновить зависимости, игнорировать exit code и принять число отправленных запросов за покрытие. Newman полезно понимать как часть существующего стека, а устойчивость API-проверок строить на явных данных, assertions и поддерживаемом исполнении.