Автотесты в Postman: проверка статус-кода, тела и времени ответа

Что такое автотесты в Postman и где их писать

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

Например, в коллекции интернет-магазина лежат запросы каталога, корзины и оформления заказа, у каждого свои тесты. После выкладки новой сборки коллекцию прогоняют целиком, и если запрос добавления в корзину стал отвечать 500, его проверка краснеет в отчёте, даже если этот экран сегодня никто не открывал руками.

В версии 2025 года тесты пишут на вкладке Scripts в разделе Post-response, он выполняется после получения ответа. Раздел Pre-request срабатывает до отправки запроса, и для первых тестов он не понадобится. В старых версиях, в том числе в моём уроке 2020 года, тесты пишут на отдельной вкладке Tests.

Рядом с редактором Postman показывает список сниппетов. Сниппет вставляет рабочий код проверки, и остаётся поменять в нём название и ожидаемое значение. Для проверок сложнее понадобится JavaScript, а пока его нет, такой тест можно попросить у ChatGPT или другого помощника, об этом ниже.

Сниппеты: проверка статуса, тела, заголовка и времени

Каждая проверка – это вызов pm.test с названием и функцией внутри. Название из сниппета вроде "Status code is 200" лучше сразу заменить своим, потому что оно просто констатирует факт. Название попадает в отчёт, и по нему другой человек должен понять, что проверялось, например "Питомец находится по id, статус-код 200".

Ожидаемое значение пишут с учётом типа данных. Строку берут в кавычки, а число, true и false пишут без них. Если id в ответе число, а в проверке стоит "840" в кавычках, тест упадёт, потому что строка не равна числу.

Вот сниппеты, которые стоит освоить первыми. Они пригодятся почти на любом проекте.

• Status code: Code is 200

  Проверяет статус-код: pm.response.to.have.status(200). Если сервер ответит 404, тест упадёт и покажет, какой код пришёл на самом деле.

• Response body: JSON value check

  Проверяет значение поля в теле ответа. Сниппет кладёт разобранный ответ в переменную jsonData через pm.response.json() и сравнивает jsonData.value с ожидаемым значением. Вместо value пишут имя ключа, например jsonData.name, а в to.eql(...) указывают, чему он должен быть равен.

• Response headers: Content-Type header check

  Проверяет, что в ответе есть заголовок: pm.response.to.have.header("Content-Type"). Имя заголовка меняют на тот, который нужен по требованиям. На проекте проверка типа содержимого ловит, например, ошибку в адресе API: сервер фронтенда отвечает на незнакомый путь страницей index.html со статусом 200, и проверка статус-кода проходит. Тест pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json") в этом случае упадёт, потому что пришёл text/html.

• Response time is less than 200ms

  Проверяет время ответа: pm.expect(pm.response.responseTime).to.be.below(200). Время в миллисекундах видно и рядом со статус-кодом в окне ответа, а порог берут из требований, если в них есть ограничение по времени.

• Шпаргалкаскрипты и тесты в Postman
• СтатьяHTTP для тестировщика: методы и коды ответов

Пример: тесты на поиск питомца по id

В уроке я пишу тесты на учебном API Petstore к запросу GET, который находит питомца по идентификатору. Ответ приходит объектом с ключами id, category, name, photoUrls, tags и status, и к ключам объекта можно обращаться напрямую, без циклов. Id подставляется из переменной petId, которую я завёл в предыдущем уроке.

В уроке 2020 года то же самое показано на reqres.in: тест проверяет, что в ответе со списком пользователей поле page равно 2.

• 1. Статус-код

  Сниппет Status code: Code is 200 со своим названием. Чтобы проверить, что тест умеет падать, адрес запроса портят: приходит 404, и проверка краснеет.

• 2. Имя питомца

  Сниппет JSON value check, где вместо jsonData.value стоит jsonData.name, а ожидаемое имя записано в кавычках, потому что это строка. Если поменять имя в ожидании, тест упадёт с сообщением о расхождении.

• 3. Id и статус

  В ту же функцию добавляют ещё две проверки: jsonData.id с числом без кавычек и jsonData.status. Тест пройдёт, только если совпадут все три значения, и упадёт, если не совпадёт хотя бы одно.

• 4. Заголовок

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

• 5. Неожиданное падение

  Однажды тест упал без всякой правки: в общем учебном API кто-то успел перезаписать питомца с тем же id. На проекте с постоянными тестовыми данными такое случается редко, но упавший тест сначала перепроверяют запросом вручную и только потом заводят баг.

Прогон коллекции: порядок запросов и негативные проверки

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

От порядка зависит многое. Если DELETE удалит питомца раньше, чем до него дойдут GET и PUT, они получат 404 вместо 200 и упадут, хотя написаны правильно: им просто не с чем работать. Поэтому удаление ставят в конец, перед запросами после удаления создают новую сущность или заранее заводят несколько с разными id.

Негативную проверку оформляют отдельным запросом со своим тестом, например запросом с несуществующим id, который должен вернуть ошибку. Функция Add Example создаёт по запросу пример с другим ответом, но тесты к примеру не добавить, поэтому для проверок лучше заводить отдельные запросы.

Коллекцию с тестами и переменными экспортируют в файл JSON и импортируют обратно или передают коллеге, тесты и переменные при этом сохраняются. На бесплатном тарифе число прогонов коллекции ограничено, и тратить их все на одно домашнее задание не стоит. Действующий лимит указан на сайте Postman.

Когда в ответе массив: сложные проверки и ChatGPT

Сниппет JSON value check рассчитан на объект. Поиск питомцев по статусу возвращает массив объектов, и проверка jsonData.name падает со значением undefined: у массива нет поля name, оно есть у каждого элемента. Нужно обратиться к конкретному элементу, например jsonData[0].name, или пройти по всем элементам циклом, а это уже JavaScript.

Для таких проверок я беру ChatGPT или другого помощника и пишу ему так: "Представь, что ты тестировщик ПО и тестируешь API в Postman. Для этого тела ответа напиши тест, который будет проверять наличие всех ключей и значений. Ответ пришли в формате теста для Postman". Под запросом вставляют тело ответа целиком и уточняют, что это массив объектов, внутри которых тоже есть массивы. Помощник написал тест с проверкой длины массива и полей каждого объекта, и прогон прошёл.

Запрос я строю по схеме, которую советую всем, кто раньше не просил ИИ писать код: сначала роль, затем задача, затем формат ответа. Готовый тест стоит прочитать, а потом один раз намеренно сломать в нём ожидаемое значение и посмотреть, упадёт ли он. Больше готовых вариантов проверок есть в документации Postman.

Видеоуроки, шпаргалки и задания

Встроенные тесты я показываю в третьем уроке мини-курса "Postman для тестировщика" на YouTube, на вкладке Tests и учебном API reqres.in. В 2025 году вышел обновлённый урок на вкладке Scripts и API Petstore, где есть прогон коллекции, экспорт и тест для массива, написанный ChatGPT.

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

• Урок курсаЭтот урок с заданиями – бесплатно
• Мой видеоурокпростые встроенные автотесты в Postman
• Мой видеоурокPostman для тестировщика 2.0, простые автотесты
• Шпаргалкаскрипты и тесты в Postman
• Шпаргалкакоды ответов HTTP
• Тренажёрпрактика API-запросов
• СтатьяПеременные и окружения в Postman
• СтатьяPostman для тестировщика: с чего начать

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441
• платный

  Тестирование REST API в Postman. Легенды и мифы Древней Греции

  Древняя Греция · REST API

  45 уроков544

Вопросы и ответы