Урок 7 из 8 · 25 мин · обновлено
Проверки и автотесты в Postman
Как проверять ответы автоматически: тесты в Postman на JavaScript, проверка кода ответа, времени, полей и типов, негативные проверки и запуск всей коллекции через Collection Runner.
Зачем автоматизировать
Отправить запрос и посмотреть на ответ глазами — нормально для первого знакомства. Но в коллекции 30 запросов, а разработчики выкладывают изменения каждый день. Пересматривать всё вручную долго и скучно, и глаз начинает пропускать ошибки.
Поэтому в Postman к запросам добавляют тесты — короткие проверки на JavaScript. Они выполняются после каждого ответа и показывают: прошло или нет.
Первые тесты
Откройте запрос «Товар по номеру» GET {{baseUrl}}/products/1, вкладка Scripts → Post-response:
pm.test("Код ответа 200", function () {
pm.response.to.have.status(200);
});
pm.test("Ответ быстрее секунды", function () {
pm.expect(pm.response.responseTime).to.be.below(1000);
});
pm.test("У товара есть название и цена-число", function () {
const product = pm.response.json();
pm.expect(product.title).to.be.a("string");
pm.expect(product.price).to.be.a("number");
pm.expect(product.price).to.be.above(0);
});
После Send откройте вкладку Test Results под ответом: три зелёные строки PASSED. Если что-то не так — красная FAILED и объяснение, что ожидали и что пришло.
pm.test("название", function () { … })— одна проверка с понятным названием. По названиям потом читают отчёт;pm.expect(значение)— что проверяем, а дальше — каким должно быть:.to.eql(5)— равно 5,.to.be.a("number")— число,.to.be.above(0)— больше нуля,.to.include("phone")— содержит;pm.response.json()— тело ответа как объект. Поля берут по цепочке, как в уроке 3:json.products[0].title.
Повторять тесты можно по образцу: структура почти всегда одинаковая, меняется только проверка внутри. В Postman есть и готовые заготовки — кнопка Snippets справа от редактора скрипта.
Негативные проверки
API нужно проверять не только на правильных данных. Что будет, если товара нет? Если пароль неверный? Если не передать токен? Такие проверки называют негативными.
Запрос GET {{baseUrl}}/products/0:
pm.test("Несуществующий товар — 404", function () {
pm.response.to.have.status(404);
});
pm.test("Понятное сообщение об ошибке", function () {
pm.expect(pm.response.json().message).to.include("not found");
});
Хороший API на ошибку отвечает правильным кодом и понятным сообщением. Плохой — кодом 200 с пустым ответом или кодом 500, как будто сломался сам. Оба случая — повод завести баг.
Запустить всю коллекцию
Collection Runner запускает все запросы коллекции по порядку и собирает результаты тестов:
- В меню коллекции выберите Run.
- Отметьте запросы и порядок. Вход должен идти первым — он сохранит токен для остальных.
- Нажмите Run Учебный магазин.
В отчёте видно, сколько тестов прошло и какие упали. Такой прогон делают после каждого обновления сервера: если что-то сломалось, вы узнаете через минуту, а не от пользователей.
Те же коллекции можно запускать без окон, из командной строки, — через Postman CLI или Newman. Так проверки встраивают в автоматическую сборку проекта: тесты API запускаются сами при каждом изменении кода.
Попробуйте сами. Напишите тесты для запроса GET {{baseUrl}}/products/search?q=phone&limit=5: код 200, в ответе не больше 5 товаров, у первого товара в названии или описании есть слово phone без учёта регистра.
Решение
const json = pm.response.json();
pm.test("Код ответа 200", function () {
pm.response.to.have.status(200);
});
pm.test("Не больше 5 товаров", function () {
pm.expect(json.products.length).to.be.at.most(5);
});
pm.test("Первый товар подходит под поиск", function () {
const first = json.products[0];
const text = (first.title + " " + first.description).toLowerCase();
pm.expect(text).to.include("phone");
});
json.products.length — сколько элементов в массиве. toLowerCase() переводит текст в строчные буквы, чтобы проверка не зависела от регистра: iPhone превратится в iphone и подойдёт.
Почему проверяем и описание: сервер может найти товар по описанию, даже если в названии слова нет. Тест должен проверять то, что обещает документация API, а не наши догадки.
Мини-тест: проверьте себя
Закрепите урок: несколько вопросов, разбор ответов — в конце.
-
Что проверяет тест pm.response.to.have.status(200)?
Это самая базовая проверка: сервер ответил тем кодом, который мы ожидаем.
-
Зачем проверять тип поля, например что price — число?
Сервер может вернуть 200 и неправильные данные. Проверки полей и типов ловят такие ошибки.
-
Что такое Collection Runner?
Так проверяют весь API после каждого изменения на сервере: одна кнопка — и видно, что сломалось.