Автоматизация рутины в Postman (часть 1): 10 pre-request скриптов, которые мне упростили жизнь

Евгений Гусинец

Middle+ QA Engineer в Бизнес-Инфо (Минск)

Привет, коллеги по цеху! На связи снова Евгений Гусинец, QA Engineer и автор ТГ-канала о тестировании QA❤️4Life.

За плечами у меня 3 года в тестировании, и за это время мне приходилось сталкиваться с самыми разными задачами от ручного тестирования бэкенда, UI и их автоматизации до построения полного цикла тестирования производительности. А опыт в управлении проектами научил меня ценить эффективность и находить оптимальные решения.

Если вы, как и я, проводите немало времени в Postman, то знаете, насколько рутинной может быть работа: постоянно копировать значения, вручную обновлять токены, проверять одни и те же поля... Знакомо?

Вот тут-то на сцену и выходят наши помощники - pre-request и post-request скрипты в Postman. Эти небольшие кусочки кода способны превратить вашу работу с API из нудного прокликивания в элегантный и автоматизированный процесс.

В этой серии из двух статей я поделюсь своей подборкой скриптов, которые не раз меня выручали. Моя цель — на простых примерах показать, как они могут сэкономить вам кучу времени и сделать тестирование API чем-то вроде увлекательного квеста.

В первой части мы сосредоточимся на Pre-request скриптах — наших верных помощниках, которые выполняют всю подготовительную работу до отправки основного запроса: генерируют данные, получают токены и подставляют нужные переменные.

Готовы узнать, какие секреты они хранят? Тогда поехали!

Что такое Pre-request скрипты в Postman и зачем они нужны?

Что такое Pre-request скрипты в Postman и зачем они нужны?

Прежде чем мы начнем рассматривать конкретные примеры, давайте разберемся, что же такое pre-request скрипты в Postman и какую роль они играют в процессе тестирования API.

Представьте себе ситуацию, когда перед отправкой вашего основного запроса к API вам необходимо выполнить какие-либо подготовительные действия. Это может быть получение временного токена авторизации, генерация уникального идентификатора, установка определенного параметра в зависимости от текущего окружения или даже простая задержка перед отправкой запроса. Именно для автоматизации таких предварительных шагов и существуют pre-request скрипты.

Где найти Pre-request скрипты?

В Postman вы можете добавлять pre-request скрипты на разных уровнях:

1. На уровне коллекции: скрипт будет выполняться перед каждым запросом в коллекции. Это удобно, когда вам нужно выполнить одно и то же действие перед всеми запросами (например, получить токен).

   

2. На уровне папки: скрипт будет выполняться перед каждым запросом, находящимся в этой папке. Это полезно для группировки запросов, требующих схожей предварительной подготовки.

   

3. На уровне отдельного запроса: скрипт будет выполняться только перед выбранным вами запросом. Это позволяет настраивать специфическую подготовку для конкретного эндпоинта.

   

Чтобы добавить или отредактировать pre-request скрипт, выберите нужный элемент (коллекцию, папку или запрос) в левой панели Postman и перейдите на вкладку "Pre-request Script". Там вы увидите текстовый редактор, где вы сможете писать свой JavaScript код.

Какую роль выполняют Pre-request скрипты?

Основная задача pre-request скриптов – это выполнение любого JavaScript кода до отправки вашего HTTP-запроса. Это дает вам огромную гибкость в подготовке запроса. С помощью этих скриптов вы можете:

• Динамически изменять параметры запроса (URL, заголовки, тело).

• Устанавливать или обновлять значения переменных окружения или глобальных переменных.

• Выполнять условную логику, например, пропускать определенные запросы в зависимости от результатов предыдущих шагов.

• Генерировать необходимые данные (случайные числа, временные метки и т.д.).

• Автоматически получать и устанавливать токены аутентификации, как мы увидим в первом примере.

Почему Pre-request скрипты важны?

Использование pre-request скриптов значительно повышает эффективность и удобство тестирования API. Они помогают:

• Автоматизировать рутинные задачи: Избавляют от необходимости выполнять одни и те же действия вручную перед каждым запросом.

• Создавать более сложные и гибкие сценарии тестирования: Позволяют динамически адаптировать запросы в зависимости от различных условий.

• Улучшить читаемость и поддерживаемость ваших коллекций: Логика подготовки запроса становится более явной и централизованной.

• Упростить работу с API, требующими сложной аутентификации или предварительной настройки.

10 важнейших Pre-request скриптов в работе QA

1. Автоматическое получение и установка токенов аутентификации

1. Автоматическое получение и установка токенов аутентификации

Современные API в большинстве своем используют токенную аутентификацию (например, OAuth 2.0). Представьте себе, что каждый раз перед выполнением запроса вам нужно вручную идти в отдельный эндпоинт, логиниться, копировать полученный токен и вставлять его в заголовок или параметры вашего основного запроса. Звучит утомительно, правда? Вот тут-то нам на помощь и приходят pre-request скрипты!

Зачем это нужно начинающему тестировщику?

Умение автоматизировать процесс получения токена – это один из базовых навыков при тестировании защищенных API. Это не только экономит кучу времени, но и снижает вероятность ошибок, связанных с использованием устаревших токенов.

Практический пример:

Давайте предположим, что наш API использует OAuth 2.0, и для получения доступа нам нужно отправить POST-запрос на эндпоинт /auth/login с логином и паролем. В ответе мы получаем JSON, содержащий access_token.

Вот как может выглядеть pre-request скрипт для одного из запросов, требующих авторизации:

JavaScript

if (!pm.environment.get("accessToken")) {
    // Если токен еще не установлен, получаем его
    pm.sendRequest({
        url: 'https://your-api.com/auth/login',
        method: 'POST',
        header: {
            'Content-Type': 'application/json'
        },
        body: {
            mode: 'raw',
            raw: JSON.stringify({
                "username": "{{username}}", // Используем переменные окружения для логина
                "password": "{{password}}" // и пароля
            })
        }
    }, function (err, response) {
        if (err) {
            console.error(err);
        } else {
            const responseJson = response.json();
            pm.environment.set("accessToken", responseJson.access_token);
            console.log("Access token получен и установлен.");
        }
    });
} else {
    console.log("Access token уже существует.");
}

Как это работает:

1 Проверяем наличие токена. Скрипт обращается к переменным окружения и ищет accessToken.

2 Отправляем запрос, если токена нет. Если переменная пуста, скрипт инициирует фоновый pm.sendRequest на эндпоинт авторизации с логином и паролем.

3 Парсим ответ. В случае успешного ответа (код 200), скрипт разбирает (парсит) полученный JSON.

4 Сохраняем токен. Скрипт извлекает значение access_token из ответа и сохраняет его в переменную окружения accessToken для использования в основном и последующих запросах.

Теперь процесс аутентификации полностью автоматизирован и вам больше не нужно вручную получать и подставлять токен перед запуском тестов.

Практика применения:

В настройках вашего основного запроса, в разделе "Authorization", выберите тип "Bearer Token" и в поле "Token" вставьте {{accessToken}}. Теперь при каждом выполнении запроса Postman будет автоматически подставлять актуальный токен.

Довольно часто бывают проекты, где токен OAuth 2.0 "живет" всего час. Без автоматизации его обновления, каждый раз перед запуском коллекции API-тестов приходится вручную логиниться и обновлять токен в Postman. Написание такого простого pre-request скрипта экономит просто уйму времени и делает наши тесты стабильными.

Автоматическое обновление токена по истечении срока жизни (улучшенная версия)

В предыдущем примере мы решили проблему ручного получения токена. Но что, если токен имеет ограниченный срок жизни, например, 1 час? Простой скрипт не будет запрашивать новый токен, пока мы вручную не очистим переменную в окружении. Это приведет к падению тестов, как только токен на сервере "протухнет".

Этот улучшенный скрипт решает данную проблему, делая процесс полностью автономным.

Зачем это нужно начинающему тестировщику?

Умение работать с токенами, у которых истекает срок действия — это следующий шаг в профессиональном тестировании API. Этот скрипт сделает ваши тестовые наборы значительно более надежными и готовыми к автоматическому запуску по расписанию (например, в CI/CD), так как они не будут требовать ручного вмешательства для обновления аутентификации.
JavaScript

// Устанавливаем срок жизни токена в миллисекундах (например, 50 минут)
const tokenExpiryMargin = 50 * 60 * 1000; 
const savedTokenTimestamp = pm.environment.get("tokenTimestamp");
const now = new Date().getTime();

// Проверяем, есть ли токен ИЛИ не истек ли его срок жизни
if (!pm.environment.get("accessToken") || (now - savedTokenTimestamp > tokenExpiryMargin)) {
    console.log("Токен отсутствует или истек. Запрашиваю новый...");
    pm.sendRequest({
        url: 'https://your-api.com/auth/login',
        method: 'POST',
        header: {'Content-Type': 'application/json'},
        body: {
            mode: 'raw',
            raw: JSON.stringify({
                "username": "{{username}}",
                "password": "{{password}}"
            })
        }
    }, function (err, response) {
        if (err) {
            console.error(err);
        } else if (response.code === 200) {
            const responseJson = response.json();
            pm.environment.set("accessToken", responseJson.access_token);
            // Важно: обновляем не только токен, но и временную метку его получения
            pm.environment.set("tokenTimestamp", new Date().getTime());
            console.log("Access token получен и установлен.");
        } else {
            console.error("Не удалось получить токен, ответ:", response.status, response.text());
        }
    });
} else {
    console.log("Используется существующий активный токен.");
}

Как это работает:

1 Определяем "срок годности". В tokenExpiryMargin мы задаем безопасный срок жизни токена в миллисекундах. Мы берем его чуть меньше реального (например, 50 минут вместо 60), чтобы избежать ситуации, когда токен истечет прямо в момент отправки запроса.

2 Получаем временные метки. Скрипт берет из переменных окружения tokenTimestamp (время, когда токен был сохранен в прошлый раз) и получает текущее время now.

3 Выполняем ключевую проверку. Логика в условии if теперь сложнее. Запрос за новым токеном отправится, если выполнится хотя бы одно из условий:

!pm.environment.get("accessToken") — токена нет в принципе (первый запуск).

(now - savedTokenTimestamp > tokenExpiryMargin) — разница между текущим временем и временем сохранения токена больше, чем наш "срок годности". Проще говоря, токен устарел.

4 Запрашиваем новый токен. Если проверка пройдена, выполняется уже знакомый нам pm.sendRequest.

5 Сохраняем токен и ВРЕМЕННУЮ МЕТКУ. Это самый важный шаг. После успешного получения нового токена мы сохраняем не только сам accessToken, но и tokenTimestamp — новое текущее время. Это "сбрасывает счетчик" и позволяет корректно отсчитывать срок жизни при следующем запуске.

Теперь ваша тестовая коллекция становится полностью автономной в плане аутентификации. Она самостоятельно отслеживает срок жизни токена и обновляет его, что критически важно для стабильности автоматических запусков в CI/CD.

2. Настройка условных данных в зависимости от окружения (Environment)

2. Настройка условных данных в зависимости от окружения (Environment)

При разработке и тестировании приложений мы часто работаем с несколькими окружениями: dev, staging, production и так далее. Каждый из них может иметь свои особенности, например, разные базовые URL API, различные ключи доступа и прочее. Чтобы не создавать отдельные коллекции для каждого окружения, мы можем использовать переменные окружения Postman и pre-request скрипты для динамической настройки данных.

Зачем это нужно начинающему тестировщику?

Умение работать с разными окружениями – важный навык. Этот скрипт поможет вам легко переключаться между окружениями без необходимости вручную менять настройки в каждом запросе.

Практический пример:

Предположим, у нас есть переменная окружения environment, которая может принимать значения "dev", "staging" или "prod". В зависимости от этого значения, мы хотим использовать разные базовые URL для наших API-запросов.

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

JavaScript

const currentEnvironment = pm.environment.get("environment");
let baseUrl;

if (currentEnvironment === "dev") {
    baseUrl = "https://dev.example.com/api/v1";
} else if (currentEnvironment === "staging") {
    baseUrl = "https://staging.example.com/api/v1";
} else if (currentEnvironment === "prod") {
    baseUrl = "https://api.example.com/v1";
} else {
    console.warn("Неизвестное окружение:", currentEnvironment, ". Используется URL по умолчанию для разработки.");
    baseUrl = "https://dev.example.com/api/v1";
}

pm.environment.set("baseUrl", baseUrl);
console.log("Базовый URL установлен:", baseUrl);

Как это работает:

1. Получаем имя текущего окружения. Скрипт берет значение переменной environment (например, "dev", "staging").

2. Определяем базовый URL. С помощью условного оператора if-else if скрипт сопоставляет имя окружения с соответствующим ему URL.

3. Устанавливаем URL для запросов. Найденный URL сохраняется в переменную окружения baseUrl. Если окружение не найдено, устанавливается значение по умолчанию.

Теперь коллекция становится универсальной. Простое переключение окружения в Postman автоматически меняет все URL в запросах, исключая ошибки и ручную работу.

Практика применения:

В URL ваших API-запросов вместо конкретного адреса используйте переменную {{baseUrl}}. Теперь, просто меняя значение переменной environment в Postman, вы будете автоматически переключаться между разными API.

Нередкая проблемная ситуация на проектах, когда начинающие тестировщики случайно отправляют запросы на production-сервер, работая в окружении для разработки. Внедрение такого скрипта и четкое определение переменных окружения позволяет полностью исключить эту неприятную ситуацию. Как отмечается в стандартах ISTQB, тестирование должно проводиться в окружениях, максимально приближенных к реальным, и этот скрипт помогает нам в этом.

3. Динамическое формирование параметров запроса

3. Динамическое формирование параметров запроса

Очень часто при работе с API возникает необходимость формировать параметры запроса динамически, в зависимости от каких-либо условий, значений переменных окружения или даже данных, полученных в предыдущих запросах. Pre-request скрипты отлично справляются с этой задачей.

Зачем это нужно начинающему тестировщику?

Умение динамически формировать параметры запроса позволяет создавать более гибкие и мощные тесты. Это особенно полезно при тестировании фильтрации, поиска, пагинации и других сценариев, где параметры запроса могут меняться.

Практический пример:

Предположим, у вас есть API для получения списка пользователей (/users), и вы хотите добавить параметр status для фильтрации пользователей по их статусу. Значение этого статуса вы хотите брать из переменной окружения userStatus.

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

JavaScript

const userStatus = pm.environment.get("userStatus");
const queryParams = [];

if (userStatus) {
    queryParams.push(`status=${userStatus}`);
}

// Здесь можно добавить и другие условия для формирования параметров

if (queryParams.length > 0) {
    pm.request.url.query.add(queryParams.join('&'));
    console.log("Добавлены параметры запроса:", queryParams.join('&'));
} else {
    console.log("Нет динамических параметров для добавления.");
}

Как это работает:

1. Получаем значение для фильтрации. Скрипт считывает значение переменной userStatus из окружения.

2. Проверяем, нужно ли добавлять параметр. Если переменная userStatus не пустая, скрипт формирует строку параметра, например, status=active.

3. Добавляем параметр к URL. Если в массиве queryParams есть хотя бы один элемент, скрипт добавляет все сформированные параметры к URL запроса, используя метод pm.request.url.query.add(). Параметры объединяются символом &.

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

Практика применения:

В URL вашего запроса к /users просто укажите базовый путь (например, https://your-api.com/users). Pre-request скрипт автоматически добавит необходимые параметры в зависимости от значения переменной userStatus.

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

4. Генерация случайных данных

4. Генерация случайных данных

При тестировании API часто возникает необходимость создавать новые ресурсы с уникальными данными (например, при регистрации пользователя, создании заказа и т.д.). Использование одних и тех же данных может приводить к ошибкам (например, "пользователь с таким email уже существует"), а придумывать их вручную — долго и неэффективно.В Postman существует два основных подхода к генерации случайных данных: использование встроенных динамических переменных и написание собственных Pre-request скриптов. Рассмотрим оба.

Способ 1: Встроенные динамические переменные (самый простой)

Postman умеет генерировать множество типов случайных данных "на лету" без единой строчки кода. Для этого используются специальные переменные, которые начинаются со знака $.

Как это работает:

Вы просто вставляете одну из этих переменных прямо в URL, тело запроса или заголовки. Перед отправкой запроса Postman автоматически заменит ее на сгенерированное значение.

Популярные переменные:

• {{$guid}} — генерирует уникальный идентификатор GUID.

• {{$timestamp}} — подставляет текущую временную метку Unix.

• {{$randomInt}} — генерирует случайное целое число от 0 до 1000.

• {{$randomEmail}} — генерирует случайный email.

• {{$randomFullName}} — генерирует случайное имя и фамилию.

• {{$randomPhoneNumber}} — генерирует случайный номер телефона (в американском формате).

  

В теле вашего запроса на регистрацию пользователя можно написать так:

{
    "email": "{{$randomEmail}}",
    "fullName": "{{$randomFullName}}",
    "login_id": "{{$guid}}"
}

При каждом запуске Postman подставит в эти поля новые случайные значения.

Способ 2: Генерация данных с помощью Pre-request скрипта (гибкий)

Иногда требуются данные в специфическом формате, который не покрывается встроенными переменными. Например, российский номер телефона или случайное число в заданном диапазоне. В таких случаях на помощь приходят скрипты.

Практический пример:

Давайте представим, что вам нужно протестировать API регистрации, и каждый раз вам требуется уникальный email, но с вашим корпоративным доменом и префиксом test_.

JavaScript

// Pre-request Script
const randomString = Math.random().toString(36).substring(2, 15);
const randomEmail = `test_${randomString}@mycompany.com`;

pm.environment.set("customRandomEmail", randomEmail);
console.log("Сгенерирован кастомный email:", randomEmail);

Как это работает:

1 Генерируем случайную строку. С помощью Math.random() создается уникальная последовательность символов.Скрипт использует функцию Math.random() для генерации случайного числа, преобразует его в строку в 36-ричной системе счисления и берет подстроку, чтобы получить случайный набор символов.

2 Формируем email. К случайной строке добавляется наш префикс test_ и домен @mycompany.com,чтобы получился валидный формат email. .

3 Сохраняем результат. Сгенерированный email помещается в переменную окружения randomEmail.

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

Когда какой способ использовать?

• Используйте встроенные переменные {{$...}}, если вам нужны стандартные случайные данные (имя, email, GUID) и не важен их конкретный формат. Это самый быстрый и простой способ.

• Используйте Pre-request скрипт, если вам нужны данные:

  В специфическом формате (например, российский номер телефона +7(9...).

  В определенном диапазоне (например, случайное число от 100 до 200).

  Зависящие от других переменных или условий.

При тестировании API, которое позволяло пользователям создавать объявления, было необходимо убедиться, что система корректно обрабатывает большое количество объявлений с уникальными заголовками. Написание скрипта, который генерировал случайные заголовки, значительно ускорило этот процесс и позволило провести более качественное тестирование. Как отмечается в книге "Как тестируют в Google", использование разнообразных тестовых данных помогает выявить большее количество потенциальных проблем.

5. Подготовка данных для тела запроса

5. Подготовка данных для тела запроса

При тестировании API, особенно при отправке POST, PUT или PATCH запросов, нам часто приходится формировать тело запроса в формате JSON или XML. Иногда данные для этого тела могут зависеть от определенных условий, значений переменных окружения или даже результатов предыдущих запросов. Pre-request скрипты позволяют нам динамически подготавливать эти данные перед отправкой запроса.

Зачем это нужно тестировщику?

Умение программно формировать тело запроса открывает перед вами гораздо больше возможностей для тестирования различных сценариев. Вы сможете легко создавать запросы с нужными данными в зависимости от ситуации, что делает ваши тесты более гибкими и мощными.

Практический пример:

Предположим, вы тестируете API для создания нового заказа. Вам нужно включить в тело запроса информацию о товарах, их количестве и, возможно, промокод, если он доступен. Значение промокода вы хотите брать из переменной окружения promoCode, и добавлять его в запрос только если эта переменная задана.

Вот как может выглядеть pre-request скрипт для подготовки тела запроса:
JavaScript

const orderData = {
    "customer_id": "{{customerId}}", // Используем переменную окружения для ID клиента
    "items": [
        { "product_id": 123, "quantity": 2 },
        { "product_id": 456, "quantity": 1 }
    ],
    "total_amount": 150.00
};

const promoCode = pm.environment.get("promoCode");

if (promoCode) {
    orderData.promo_code = promoCode;
    console.log("Промокод добавлен в заказ:", promoCode);
} else {
    console.log("Промокод не задан.");
}

// Преобразуем объект JavaScript в JSON-строку и сохраняем в переменную окружения
pm.environment.set("orderBody", JSON.stringify(orderData));

Как это работает:

1 Сначала мы создаем объект orderData с основной информацией о заказе. Обратите внимание, что мы используем переменные окружения ({{customerId}}) для динамических значений.

2 Затем мы получаем значение переменной окружения promoCode.

3 С помощью условного оператора if мы проверяем, задан ли промокод. Если да, мы добавляем поле promo_code в наш объект orderData.

3 Наконец, мы преобразуем объект orderData в JSON-строку с помощью JSON.stringify() и сохраняем ее в переменную окружения orderBody.

В теле вашего POST запроса на создание заказа выберите формат raw и вставьте туда переменную {{orderBody}}. Pre-request скрипт позаботится о том, чтобы в тело запроса попали актуальные данные, включая промокод, если он задан.

Практика применения:

В проектах довольно часто в каком-нибудь запросе обязательно будет какая-нибудь заковыристая структура тела запроса для создания нового объекта, а некоторые поля, например, часто являются необязательными и зависят от определенных условий. Использование pre-request скрипта для формирования этого тела всегда позволяет избежать множества дублирующихся запросов и сделать ваши тесты более лаконичными и понятными.

6. Проверка наличия обязательных переменных окружения и установка значений по умолчанию, если они не заданы

6. Проверка наличия обязательных переменных окружения и установка значений по умолчанию, если они не заданы

При работе с Postman коллекциями, особенно если вы делитесь ими с коллегами или используете в разных окружениях, очень важно убедиться, что все необходимые переменные окружения заданы. Pre-request скрипты могут помочь вам в этом, проверяя наличие нужных переменных и устанавливая для них значения по умолчанию, если они отсутствуют.

Зачем это нужно тестировщику?

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

Практический пример:

Предположим, для работы вашей коллекции необходимы переменные окружения apiKey и defaultTimeout. Вы можете добавить следующий pre-request скрипт на уровне коллекции:
JavaScript

if (!pm.environment.get("apiKey")) {
    pm.environment.set("apiKey", "YOUR_DEFAULT_API_KEY");
    console.warn("Переменная окружения 'apiKey' не задана. Установлено значение по умолчанию.");
}

if (!pm.environment.get("defaultTimeout")) {
    pm.environment.set("defaultTimeout", "5000"); // Значение по умолчанию в миллисекундах
    console.warn("Переменная окружения 'defaultTimeout' не задана. Установлено значение по умолчанию: 5000 мс.");
}

console.log("Проверка обязательных переменных окружения завершена.");

Как это работает:

Скрипт использует условный оператор if и функцию pm.environment.get() для проверки наличия каждой обязательной переменной окружения.

Если переменная не найдена (функция get() возвращает undefined), скрипт устанавливает для нее значение по умолчанию с помощью pm.environment.set() и выводит предупреждение в консоль, чтобы пользователь знал об этом.

Практика применения:

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

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

7. Установка динамических заголовков

7. Установка динамических заголовков

HTTP-заголовки предоставляют дополнительную информацию о запросе и ответе. Иногда возникает необходимость устанавливать или изменять заголовки запроса динамически, в зависимости от определенных условий или значений переменных. Pre-request скрипты идеально подходят для решения этой задачи.

Зачем это нужно начинающему тестировщику?

Понимание работы с заголовками – важная часть тестирования API. Заголовки могут контролировать такие аспекты, как тип контента, авторизация (если токен передается не в теле запроса), кэширование и многое другое. Умение динамически управлять ими делает ваши тесты более гибкими.

Практический пример:

Предположим, вам нужно отправить запрос с определенным заголовком Content-Type в зависимости от значения переменной окружения contentType.

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

JavaScript

const contentType = pm.environment.get("contentType");

if (contentType) {
    pm.request.headers.set("Content-Type", contentType);
    console.log("Заголовок Content-Type установлен в:", contentType);
} else {
    console.log("Заголовок Content-Type не был установлен динамически.");
}

// Вы также можете удалять заголовки, если это необходимо:
// pm.request.headers.remove("X-Custom-Header");

Как это работает:

1 Скрипт получает значение переменной окружения contentType.

2 Если значение существует, он устанавливает заголовок Content-Type в запросе на это значение, используя метод pm.request.headers.set().

3 Если переменная contentType не задана, скрипт просто выводит сообщение в консоль.

4 Также в примере показано, как можно удалить заголовок с помощью метода pm.request.headers.remove().

Практика применения:

В настройках вашего запроса вы можете оставить поля заголовков пустыми или задать значения по умолчанию. Pre-request скрипт при необходимости переопределит или добавит нужные заголовки.

Была ситуация, когда в одном из проектов API поддерживало обмен данными как в формате JSON, так и в XML. Для тестирования обоих форматов мы использовали pre-request скрипт, который динамически устанавливал заголовок Content-Type в значениеapplication/json или application/xml в зависимости от того, какой сценарий мы тестировали. Это позволило нам использовать одну и ту же коллекцию для тестирования разных форматов данных.

8. Установка текущей даты и времени в нужном формате

8. Установка текущей даты и времени в нужном формате

Многие API при работе с данными требуют указания даты и времени в определенном формате. Чтобы не делать это вручную каждый раз, вы можете использовать pre-request скрипты для автоматической генерации текущей даты и времени и форматирования их в соответствии с требованиями API.

Зачем это нужно тестировщику?

Работа с датами и временем – довольно распространенная задача при тестировании API, особенно если вы тестируете функциональность, связанную с расписаниями, событиями или временными метками. Этот скрипт поможет вам легко генерировать даты в нужном формате.

Практический пример:

Предположим, API ожидает дату в формате YYYY-MM-DD.

Вот как может выглядеть pre-request скрипт для установки текущей даты в этом формате:

JavaScript

const today = new Date();
const year = today.getFullYear();
const month = String(today.getMonth() + 1).padStart(2, '0'); // Месяцы в JavaScript нумеруются с 0
const day = String(today.getDate()).padStart(2, '0');
const formattedDate = `${year}-${month}-${day}`;

pm.environment.set("currentDate", formattedDate);
console.log("Текущая дата установлена в:", formattedDate);

Как это работает:

1Скрипт создает новый объект Date, представляющий текущую дату и время.

2 Затем он извлекает год, месяц и день из этого объекта. Обратите внимание, что месяц в JavaScript начинается с 0, поэтому мы добавляем 1. Также мы используем метод padStart(2, '0') для добавления ведущего нуля, если число состоит из одной цифры.

3 Далее мы формируем строку даты в нужном формате YYYY-MM-DD.

4 Наконец, мы сохраняем эту отформатированную дату в переменную окружения currentDate.

Практика применения:

Теперь вы можете использовать переменную {{currentDate}} в теле или параметрах вашего запроса, где требуется указать дату в формате YYYY-MM-DD.

Представьте что, вам на тестирование отдали проект, где необходимо протестировать API для бронирования отелей. Одним из обязательных параметров обязательно будет "дата заезда" в формате YYYY-MM-DD. Чтобы каждый раз не вводить текущую дату вручную, вам очень поможет написание такого pre-request скрипта, который автоматически подставит сегодняшнюю дату в нужном формате. Это значительно ускорит процесс тестирования и сделает его более удобным.

9. Кодирование данных (например, в Base64)

9. Кодирование данных (например, в Base64)

В некоторых случаях API могут требовать передачи определенных данных, особенно учетных данных или специфических параметров, в закодированном виде. Одним из распространенных форматов кодирования является Base64. Pre-request скрипты могут легко справиться с этой задачей.

Зачем это нужно тестировщику?

Хотя это может встречаться не так часто, как другие сценарии, понимание того, как кодировать данные, может быть полезно при работе с определенными типами API, особенно в контексте безопасности или интеграций.

Практический пример:

Предположим, API требует передачи логина и пароля, объединенных через двоеточие, в Base64-кодированном виде в кастомном заголовке.

Вот как может выглядеть pre-request скрипт для этого:

JavaScript

const username = pm.environment.get("username");
const password = pm.environment.get("password");

if (username && password) {
    const credentials = `${username}:${password}`;
    const encodedCredentials = btoa(credentials); // btoa() - встроенная функция для кодирования в Base64
    pm.environment.set("encodedCredentials", encodedCredentials);
    console.log("Закодированные учетные данные:", encodedCredentials);
} else {
    console.warn("Не заданы логин или пароль в переменных окружения.");
}

Как это работает:

1 Скрипт получает значения логина и пароля из переменных окружения.

2 Если обе переменные заданы, он объединяет их через двоеточие в строку credentials.

3 Затем с помощью встроенной JavaScript функции btoa() кодирует эту строку в формат Base64.

4 Закодированные учетные данные сохраняются в переменную окружения encodedCredentials.

Практика применения:

В настройках вашего запроса, в разделе "Headers", вы можете добавить новый заголовок (например, Authorization) и в качестве его значения использовать переменную {{encodedCredentials}}.

В одном из интеграционных проектов API партнера требовало передачи учетных данных именно в таком формате. Написание этого простого скрипта позволило тестировщикам автоматизировать процесс аутентификации и избежать ручных ошибок при кодировании.

10. Разделение или обработка строк для параметров

10. Разделение или обработка строк для параметров

Иногда у вас может быть одна переменная окружения или значение, полученное из предыдущего ответа, которое необходимо разделить на несколько частей или обработать определенным образом, чтобы сформировать параметры для текущего запроса. Pre-request скрипты отлично подходят для таких манипуляций со строками.

Зачем это нужно тестировщику?

Этот скрипт демонстрирует, как можно работать со строками в JavaScript внутри Postman, что может пригодиться в различных ситуациях при тестировании API, где требуется преобразование данных.

Практический пример:

Предположим, у вас есть переменная окружения productIds, которая содержит строку с ID товаров, разделенных запятыми (например, "123,456,789"). Вам нужно передать эти ID как отдельные query-параметры в запросе к эндпоинту /products.

Вот как может выглядеть pre-request скрипт для этого:

JavaScript

const productIdsString = pm.environment.get("productIds");

if (productIdsString) {
    const productIdsArray = productIdsString.split(',');
    productIdsArray.forEach(productId => {
        pm.request.url.query.add(`productId=${productId.trim()}`);
    });
    console.log("Добавлены ID продуктов как параметры запроса:", productIdsArray);
} else {
    console.log("Строка с ID продуктов не найдена в переменной окружения.");
}

Как это работает:

1 Скрипт получает строку с ID продуктов из переменной окружения productIds.

2 Если строка существует, он разделяет ее на массив подстрок, используя запятую в качестве разделителя (split(',')).

3 Затем он перебирает полученный массив ID и для каждого ID добавляет его как отдельный query-параметр к URL запроса с помощью метода pm.request.url.query.add(). Метод trim() используется для удаления лишних пробелов по краям ID.

Практика применения:

В URL вашего запроса к /products укажите базовый путь. Pre-request скрипт автоматически добавит параметры productId=123, productId=456 и productId=789.

Была ситуация, когда API возвращало список ID связанных объектов в виде строки, разделенной точкой с запятой. Для получения детальной информации по каждому из этих объектов нужно было отправлять отдельные запросы, передавая каждый ID в качестве параметра. Использование такого pre-request скрипта значительно упростило эту задачу.

Заключение

В этой статье мы рассмотрели 10 ключевых pre-request скриптов, которые значительно упрощают подготовку к тестированию API в Postman. Теперь вы знаете, как с помощью нескольких строк кода автоматизировать аутентификацию, генерировать динамические данные и гибко управлять параметрами запросов.

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

Но подготовка запроса — это лишь половина дела. Что происходит после того, как он отправлен и сервер вернул ответ? Как автоматически проверить его корректность, извлечь из него данные и использовать их в следующих шагах?

Именно об этом и пойдет речь во второй части, которая выйдет в ближайшее время. Мы погрузимся в мир post-request скриптов и завершим наше знакомство с основами автоматизации в Postman.

Продолжайте экспериментировать, и успехов в работе! До встречи в канале QA❤️4Life.