Тестирование API с помощью Postman: от запроса до автоматизации

Практически каждый современный веб-проект строится поверх API. Фронтенд получает данные с сервера, мобильное приложение обращается к облаку, платёжные системы обмениваются запросами друг с другом. Чтобы убедиться, что всё это работает правильно, невозможно вручную проверять каждый запрос в браузере. Именно здесь на сцену выходит Postman. Это самый популярный инструмент для тестирования, документирования и автоматизации API, и он охватывает весь спектр задач — от отправки простого GET-запроса до подключения целого набора тестов к конвейеру непрерывной интеграции.

В этой статье мы изучим Postman с нуля. Сначала познакомимся с интерфейсом и базовыми запросами, затем наведём порядок в работе с помощью коллекций и окружений. После этого напишем тестовые скрипты на JavaScript и научимся автоматически проверять ответы API, а в финале автоматизируем весь набор тестов с помощью Collection Runner и Newman, подключив его к процессу непрерывной интеграции. Материал будет одинаково полезен и разработчикам, и тестировщикам.

Что такое Postman и зачем он нужен

Postman — это графическая среда для построения и отправки HTTP-запросов. Если браузер удобно отправляет только GET-запросы, то Postman поддерживает все методы — POST, PUT, DELETE, PATCH, позволяет точно настраивать заголовки и тело запроса и показывает ответ в удобном формате. Самое важное, что Postman сохраняет каждый запрос, группирует их в коллекции и позволяет делиться ими с командой. Это служит единым источником истины для всей команды, работающей над API.

Сила Postman в том, что он не просто отправляет запросы. Он позволяет автоматически генерировать документацию по API, запускать имитационный сервер (mock server), настраивать мониторинг и, что самое главное, писать автоматические тесты. Поэтому во многих командах Postman становится центральным инструментом, управляющим всем жизненным циклом API от проектирования до эксплуатации.

Первый запрос: GET и POST

После открытия Postman вы создаёте новый запрос, выбираете метод и вводите URL. Простой GET-запрос используется для получения данных. Например, чтобы получить список пользователей, вы отправляете такой запрос, и Postman показывает ответ в виде JSON:

GET https://api.example.com/v1/users
Accept: application/json

# Ответ:
{
  "data": [
    { "id": 1, "name": "Ali" },
    { "id": 2, "name": "Vali" }
  ]
}

Запрос POST используется для отправки новых данных на сервер. Для этого вы переходите в раздел Body, выбираете формат raw и JSON и пишете отправляемые данные. Если требуется аутентификация, в разделе Authorization вы выбираете тип Bearer Token или API Key. Следующий пример показывает создание нового пользователя:

POST https://api.example.com/v1/users
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiI...

{
  "name": "Sardor",
  "email": "sardor@example.com"
}

Коллекции и окружения (environment)

Когда вы начинаете работать с несколькими запросами, возникает потребность их упорядочить. Коллекция — это набор связанных между собой запросов, например «API пользователей» или «API платежей». Коллекции позволяют разбивать запросы по папкам, добавлять к ним описания и запускать весь набор за один раз. Это основной способ поддерживать API в порядке.

Окружение (environment) — это набор переменных, который позволяет использовать одну и ту же коллекцию в разных условиях. Например, у вас могут быть окружения «dev», «staging» и «production», и в каждом из них URL и токен будут разными. Вместо жёстко прописанных значений вы используете в запросах переменные вроде {{base_url}}, и как только вы переключаете окружение, все запросы начинают работать с новыми значениями:

// Переменные окружения:
base_url = https://api.example.com/v1
token    = eyJhbGciOiJIUzI1NiI...

// Использование в запросе:
GET {{base_url}}/users
Authorization: Bearer {{token}}

Написание тестов: скрипты на JavaScript

Самая мощная сторона Postman — возможность прикреплять к каждому запросу тестовые скрипты. Эти скрипты пишутся на JavaScript и запускаются автоматически после получения ответа на запрос. Тестовые скрипты проверяют корректность ответа: соответствует ли код состояния ожидаемому, за какое время пришёл ответ, есть ли в теле нужные поля. В примере ниже показаны простые тесты, проверяющие код состояния и структуру ответа:

pm.test("Код состояния равен 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Ответ быстрее 500мс", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("В ответе есть массив data", function () {
    const json = pm.response.json();
    pm.expect(json.data).to.be.an('array');
    pm.expect(json.data.length).to.be.above(0);
});

Тестовые скрипты не только проверяют, но и могут сохранять переменные для последующих запросов. Например, очень распространённая практика — сохранить токен, полученный из запроса входа, в переменную и использовать его в следующих запросах. Это позволяет строить цепочки связанных (chained) запросов:

// Извлечение и сохранение токена из ответа входа:
const json = pm.response.json();
pm.environment.set("token", json.access_token);

// Теперь {{token}} автоматически работает в следующих запросах

Автоматизация: Collection Runner и Newman

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

Настоящая же автоматизация начинается с Newman. Newman — это инструмент для запуска коллекций Postman в командной строке. Он позволяет запускать тесты автоматически после каждого изменения кода, то есть подключать их к конвейеру непрерывной интеграции (CI/CD). Следующий пример показывает установку Newman и запуск коллекции:

# Установка Newman:
npm install -g newman

# Запуск коллекции с окружением:
newman run users-api.postman_collection.json \
  -e production.postman_environment.json \
  --reporters cli,json

Эту команду можно поместить внутрь GitHub Actions или GitLab CI и обеспечить автоматический запуск тестов API после каждого push. Если какой-то тест завершается неудачей, конвейер останавливается, и команда немедленно узнаёт об этом. Это самый надёжный способ перехватить регрессии API ещё до их попадания в продакшен.

Mock-сервер и реальный рабочий процесс

Иногда команде фронтенда нужно начать работу, не дожидаясь готовности API. Для этой ситуации и предназначена функция mock-сервера в Postman. Вы сохраняете в коллекции ожидаемые ответы в качестве примеров, и Postman выдаёт вам URL, имитирующий настоящий API. Фронтенд может работать с этим имитационным сервером, а когда настоящий API будет готов, вы просто меняете URL.

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