Как прогнать коллекцию в Postman за 5 секунд
Привет! Я Сергей, тестировщик в финтехе. Ещё я успел побыть менеджером — чуваком от бизнеса, который заказывал доработки. Пока корпорации закладывали большие бюджеты на автоматизацию, на деле много где не было не то что автоматизации, а даже базовых вещей. Я ощущал боль без автотестов с двух сторон.
На собеседованиях в QA меня десятки раз спрашивали, умею ли я создавать коллекции в Postman.
Я не умел, но заучил теорию к третьему собесу. Постепенно я рос, и вот уже в моих интересах было запустить историю с автоматизацией.
Часто компании сразу идут в написание кода, вливают деньги в дорогих специалистов и фулстек‑тестирование. До автоматизации доходят руки далеко не сразу. Я расскажу, как затащить первый уровень автоматизации на проекте: настроить буквально две кнопки в бесплатном софте, обойдясь без закупки серваков и железа. Вас полюбят разработчики, тестировщики и даже системные аналитики, которым вы сэкономите много скучных часов.
Итак, начинаем автоматизацию с Postman
Часто ИТ‑команды ищут автоматизаторов, хотя можно значительно ускорить тестирование уже имеющимися инструментами. На первом шаге важно понять, что именно вы тестируете, какие сервисы критичны для системы и какие проверки нужно проводить регулярно. После этого можно максимально прикрутить к тестированию Postman.
Дальше я расскажу про базовую автоматизацию проверки API‑запросов и их результатов.
Использование переменных в Postman
Допустим, у нас есть метод POST, который авторизует пользователя в системе. Обычно на проектах используются несколько тестовых сред, поэтому часть запроса, содержащая origin, может быть вынесена в переменные среды.
Точно так же можно вынести логин и пароль, которые зависят от окружения. Все переменные среды заключаются в {{}}.

Автоматизация проверок и пара важных правил из JavaScript
Когда мы запускаем коллекцию тестов, вручную проверять каждый ответ на валидность или копировать тестовые данные для следующего запроса долго и неудобно.
Проще использовать Scripts → Tests. Здесь мы можем:
Проверить статус ответа
pm.test("Статус код успешный",()=>{
pm.response.to.have.status(200);
});
2. Сравнить ответ с заданной JSON-схемой
pm.test("Ответ соответсвует JSON схеме", ()=> {
var schema = {
"type":"object",
"properties":{
"userId":{"type":"string"},
"username":{"type":"string"},
"password":{"type":"string"},
"token":{"type":"string"},
"expires":{"type":"string"},
"created_date":{"type":"string"},
"isActive":{"type":"boolean"}
},
"required":["userId","username","password","token","expires","created_date","isActive"]
};
pm.expect(pm.response.json()).to.have.jsonSchema(schema);
});
3. Проверить корректность значений в ответе
pm.test("Значения из ответа корректны", ()=> {
var jsonData = pm.response.json();
var userNameEnv = pm.environment.get("user_Name");
var passworEnv = pm.environment.get("password");
pm.expect(jsonData.userId).to.not.empty;
pm.expect(jsonData.username).to.eql(userNameEnv);
pm.expect(jsonData.password).to.eql(passworEnv);
pm.expect(jsonData.token).to.not.empty;
pm.expect(jsonData.isActive).to.be.false;
});
4. Записать значения из ответа в переменные для дальнейшего использования
var jsonData = pm.response.json();
var userId = jsonData.userId;
pm.environment.set("user_Id", userId);
console.log("Id пользователя сохранен", userId);
var jsonData = pm.response.json();
var token = jsonData.token;
pm.environment.set("auth_token", token);
console.log("Сохраненный токен:", token);
В целом наш скрипт будет выглядеть так:
pm.test("Статус код успешный",()=>{
pm.response.to.have.status(200);
});
pm.test("Ответ соответсвует JSON схеме", ()=> {
var schema = {
"type":"object",
"properties":{
"userId":{"type":"string"},
"username":{"type":"string"},
"password":{"type":"string"},
"token":{"type":"string"},
"expires":{"type":"string"},
"created_date":{"type":"string"},
"isActive":{"type":"boolean"}
},
"required":["userId","username","password","token","expires","created_date","isActive"]
};
pm.expect(pm.response.json()).to.have.jsonSchema(schema);
});
pm.test("Значения из ответа корректны", ()=> {
var jsonData = pm.response.json();
var userNameEnv = pm.environment.get("user_Name");
var passworEnv = pm.environment.get("password");
pm.expect(jsonData.userId).to.not.empty;
pm.expect(jsonData.username).to.eql(userNameEnv);
pm.expect(jsonData.password).to.eql(passworEnv);
pm.expect(jsonData.token).to.not.empty;
pm.expect(jsonData.isActive).to.be.false;
});
var jsonData = pm.response.json();
var userId = jsonData.userId;
pm.environment.set("user_Id", userId);
console.log("Id пользователя сохранен", userId);
var jsonData = pm.response.json();
var token = jsonData.token;
pm.environment.set("auth_token", token);
console.log("Сохраненный токен:", token);
Это JavaScript. Если вы никогда не работали с JS, не паникуйте. Пока вам не нужно становиться экспертом — достаточно запомнить несколько правил:
Оборачивать тесты в pm.test ().
Использовать pm.response.to.have.status (X); для проверки статуса.
Проверять JSON‑схему с pm.expect ().to.have.jsonSchema ().
Проверять значения ответа с pm.expect ().
Использовать pm.environment.set () для сохранения переменных.
Выводить отладочную информацию через console.log ().
Обратите внимание на четвертый пункт с сохранением данных из ответа в переменную. Это полезная команда, если данные из одного запроса вы переиспользуете в другом запросе.
Возьмём запрос, который добавляет книгу в корзину. Для его выполнения нам нужен token, который мы сгенерировали в предыдущем запросе. Дальше есть два варианта. Первый: взять данные из переменной среды, которую мы сохранили из предыдущего запроса. Этот вариант больше подходит, если мы часто запускаем коллекцию, и методы выполняются один за другим. Второй: сделать скрипт в pre‑request, который будет отрабатывать каждый раз, когда вы отправите запрос. Этот вариант удобен, когда методы используются не единым порядком. С первым вариантом, думаю, справится каждый, а вот пример pre‑request смотрите ниже.
var requestBody = {
"userName": pm.environment.get("user_Name"),
"password": pm.environment.get("password")
};
pm.sendRequest({
url: 'https://demoqa.com/Account/v1/Login',
method: 'POST',
header: {
"Content-Type": "application/json"
},
body: {
mode: "raw",
raw: JSON.stringify(requestBody)
}
}, function (err, res) {
if (err) {
console.log("Ошибка при авторизации:", err);
} else {
var responseData = res.json();
// Проверяем, есть ли поле token в ответе
if (responseData.token) {
pm.environment.set("token", responseData.token);
console.log("Токен успешно сохранен:", responseData.token);
} else {
console.log("Ошибка: поле 'token' отсутствует в ответе");
}
}
});
Давайте разберём по порядку, что тут происходит:
Создаём объект requestBody, содержащий userName и password, которые подставляются из переменных окружения.
pm.environment.get («user_Name») — получаем сохранённый логин.
pm.environment.get («password») — получаем сохранённый пароль.
Отправляем POST‑запрос на https://demoqa.com/Account/v1/Login.
Устанавливаем заголовок Content‑Type: application/json (оповещаем сервер, что отправляется JSON).
Преобразуем requestBody в строку JSON (JSON.stringify (requestBody)).
Обрабатываем ответ, передавая его в function (err, res) {…}.
Если произошла ошибка сети или запроса, выводим сообщение в консоль Postman.
Преобразуем ответ в формат JSON и сохраняем его в responseData.
Проверяем, есть ли поле token в ответе.
Если token найден, сохраняем его в переменную окружения auth_token.
Выводим в консоль console.log («Токен успешно сохранен:», responseData.token);.
Если token отсутствует — выводим сообщение «Ошибка: поле 'token' отсутствует в ответе».
Далее мы можем прописать переменную auth_token в разделе Authorization/Bearer. Так мы сократим себе время, если нам понадобится несколько раз отправить этот запрос. Нам не нужно будет искать метод авторизации, отправлять его, копировать из ответа token, возвращаться обратно и проставлять его по новой.
Упрощаем себе работу с коллекцией Postman
Автоматизировав API‑тестирование в Postman, вы не просто сократите время на рутинные проверки, вы улучшите процесс разработки в целом. Если правильно организовать коллекцию, можно значительно упростить тестирование, снизить количество ошибок и повысить прозрачность тестов для всей команды.
Используя описанный выше подход, достаточно один раз:
Настроить pre‑request скрипты и тесты — так вы сможете автоматически проверять ответы и готовить данные перед выполнением запросов.
Определить переменные окружения — вы избавитесь от ручного изменения данных при работе на разных средах.
Организовать структуру коллекции — сделаете тестирование удобнее и логичнее.
Результат: тестирование API станет быстрее, а процесс — более предсказуемым и стабильным.
Пруфы: сколько у меня занимает прогон коллекций
Собственно, дальше самое интересное. Вот наглядный пример, как я уменьшил время тестирования на моём пет‑проекте. У меня четыре метода: два POST, один DELETE, один PUT. На выполнение этих запросов руками уйдёт 5 минут (генерация токена, подстановка тестовых данных, проверка ответа). Настроив pre‑request и test способом, что я пошагово описал выше, я снизил скорость выполнения запросов и проверки их ответов до 5 секунд, то есть в 60 раз.

Как улучшить работу с коллекцией у себя на проекте
Приведите коллекцию в порядок
Начните с авторизационных запросов. Их используют чаще всего, они ключевые для большинства тестов.
Добавьте описания запросов и переменных, чтобы тестировщики и разработчики могли быстро разобраться в логике тестов.
Убедитесь, что в каждом запросе есть валидные проверки (статусы ответов, соответствие JSON-схеме, ключевые параметры).
Создайте руководство для команды
Подготовьте краткий туториал по использованию коллекции. Опишите:
Как запускать коллекцию?
Какие переменные используются и как их изменять?
Какие проверки выполняются?
Разместите коллекцию и руководство в общем доступе (в Git, Confluence, Google Drive).
Поделитесь ссылкой с командой и проведите демо.
Чем больше людей в вашей компании начнут использовать автоматизированные коллекции, тем меньше времени будет уходить на рутинные проверки и исправление ошибок.
Дополнительные ресурсы для практики
Если у вас ещё нет проекта, вы джун или работаете только с фронтом, вот вам сервис с открытым API, чтобы практиковаться в настройке коллекций: DemoQA. В статье я описал подробно референс — что именно делать. Когда я готовил статью, ChatGPT не выдал нормальных сервисов для экспериментов с API. Я нашёл сам сайт, где можно потренить — забирайте и кайфуйте.
Postman для локального тестирования API можно скачать бесплатно на любой комп за 0 денег.
До тренировок я находил статьи по такой же тематике. Это были переводы, и после прочтения я оставался с большим количеством вопросов:, а где это применять, как быть, если у меня нет проекта?
Тренировки круты для джунов, которые вкатываются в ИТ, либо для тех, кто хочет перейти на мидл-уровень. Вас точно спросят об автоматизации и Postman на собеседовании или перфоманс-ревью. Знанием практики вы отличитесь от других кандидатов, а ещё сможете открыть свой Postman прямо на созвоне и показать, как и с какой скоростью у вас всё работает.
Выводы
Из всех проектов, где я работал, я видел только в Альфе такой уровень автоматизации коллекций. Конечно, запуск Postman — не универсальная таблетка. Подход точно сработает для маленьких процессов. Если всё полетит, сможете масштабировать эту практику на соседние этапы.
Прежде чем углубляться в языки программирования и сложные фреймворки автотестирования, точно советую вам поставить Postman — простой бесплатный инструмент. Освойте его, примените в пет-проекте или в работе и только после этого переходите к более продвинутым методам.
Автоматизация — процесс, который можно начать прямо сейчас. Главное — сделать первый шаг. Надеюсь, статья поможет с этим.
Если у вас есть вопросы или идеи — делитесь в комментариях. Ну и рассказывайте, как часто на собеседованиях вас спрашивали, создавали ли вы коллекцию в Postman?