Автоматические тесты API в Postman и Newman

Как это устроено

Автотест в Postman — это обычный запрос плюс скрипт, который проверяет ответ. У запроса есть два места для кода:

• Pre-request — выполняется до отправки: подготовить данные, получить токен, сгенерировать уникальный email.
• Post-response (в старых версиях вкладка называлась Tests) — выполняется после ответа: проверить статус, поля, время, сохранить значения для следующих запросов.

Скрипты можно писать и на уровне папки или коллекции — тогда они выполняются для каждого запроса внутри.

Запуск всей коллекции подряд делает Collection Runner в интерфейсе или Newman из командной строки.

Пишем проверки

pm.test("Статус 200", () => {
  pm.response.to.have.status(200);
});

pm.test("Ответ содержит id пользователя", () => {
  const body = pm.response.json();
  pm.expect(body.id).to.be.a("number");
  pm.expect(body.email).to.include("@");
});

pm.test("Ответ быстрее секунды", () => {
  pm.expect(pm.response.responseTime).to.be.below(1000);
});

pm.test задаёт название проверки, pm.expect использует синтаксис библиотеки Chai. Что проверять в первую очередь:

• Код статуса — для успешных и для ошибочных сценариев.
• Структуру ответа — обязательные поля и их типы.
• Бизнес-правила — например, что сумма заказа равна сумме позиций.
• Негативные случаи — запрос без токена должен вернуть 401, а не 200.

Связываем запросы

Типичная цепочка: войти → создать ресурс → прочитать его → удалить.

После запроса Login сохраните токен:

const { token } = pm.response.json();
pm.collectionVariables.set("token", token);

После Create order сохраните id созданного заказа:

pm.collectionVariables.set("orderId", pm.response.json().id);

Следующий запрос использует его в адресе: {{baseUrl}}/orders/{{orderId}}.

В pre-request скрипте удобно готовить уникальные данные, чтобы тесты не конфликтовали между прогонами:

pm.variables.set("email", `qa+${Date.now()}@example.com`);

Если токен нужен до любого запроса, его можно получить прямо в pre-request скрипте коллекции через pm.sendRequest.

Collection Runner

В интерфейсе Postman откройте коллекцию и нажмите Run. Можно:

• выбрать окружение и порядок запросов;
• задать число итераций;
• подключить CSV или JSON-файл с данными — каждая строка станет отдельной итерацией, а значения будут доступны как переменные.

Runner удобен для ручной проверки перед релизом и отладки тестов.

Newman: запуск из командной строки

Newman — консольный запускатель коллекций Postman на Node.js. Экспортируйте коллекцию и окружение в JSON и выполните:

npm install -g newman

newman run api.postman_collection.json \
  -e staging.postman_environment.json \
  --reporters cli,junit \
  --reporter-junit-export results/newman.xml

Полезные флаги:

• -d data.csv — файл с тестовыми данными;
• --env-var "token=..." — передать значение переменной снаружи, например из секретов CI;
• --bail — остановиться на первой ошибке.

Если проверка не прошла, Newman завершится с ненулевым кодом, и CI отметит сборку как упавшую. У Postman есть и собственный Postman CLI с похожей задачей; он теснее связан с облаком Postman, а Newman работает полностью локально с файлами.

Добавляем в CI

Пример для GitHub Actions:

name: API tests
on: [push]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install -g newman
      - run: >
          newman run tests/api.postman_collection.json
          -e tests/staging.postman_environment.json
          --env-var "token=${{ secrets.API_TOKEN }}"
          --reporters cli,junit
          --reporter-junit-export results/newman.xml

Отчёт JUnit большинство CI-систем умеют показывать как список тестов. В GitLab CI, Jenkins и других системах шаги те же: установить Newman и запустить коллекцию.

Частые ошибки

• Тесты зависят друг от друга без необходимости. Если один запрос упал, валится вся цепочка. Делайте независимые сценарии, где это возможно.
• Тесты пишут в production. Запускайте их на отдельном стенде с тестовыми данными.
• Проверяется только статус 200. Сервер может вернуть 200 с ошибкой в теле.
• Секреты закоммичены в файле окружения. Передавайте их через --env-var и секреты CI.
• Коллекция в репозитории устарела. Договоритесь, что источник правды — файл в Git, и обновляйте его вместе с кодом API.