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

Мы уже подробно разобрали, какую важную роль играют pre-request скрипты в подготовке наших запросов. Теперь давайте поговорим о не менее значимой части – post-request скриптах. Как следует из названия, эти скрипты выполняются после того, как Postman отправил ваш запрос и получил ответ от API.

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

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

На уровне коллекции, на уровне папки или на уровне отдельного запроса

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

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

• Валидация статуса кода ответа: Проверка, что API вернул ожидаемый код (например, 200 OK, 201 Created, 400 Bad Request и т.д.).

• Проверка наличия определенных заголовков в ответе: Убедиться, что API возвращает необходимые заголовки, например, Content-Type, Authorization и другие.

• Анализ тела ответа: Проверка структуры и содержимого JSON или XML, сравнение полученных данных с ожидаемыми значениями.

• Извлечение данных из тела ответа: Получение определенных значений (например, ID созданного ресурса, токена сессии) для использования в последующих запросах.

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

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

• Создание кастомных отчетов и логирование: Хотя Postman не является инструментом для полноценной отчетности, post-request скрипты могут использоваться для отправки результатов проверок во внешние системы.

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

Post-request скрипты являются неотъемлемой частью автоматизированного тестирования API. Они позволяют:

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

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

• Быстро получать обратную связь о состоянии API: Если какая-то проверка не прошла, вы сразу же об этом узнаете.

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

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

1. Валидация кода статуса ответа

После отправки запроса одним из первых и самых важных шагов является проверка HTTP-кода статуса, который вернул API. Этот код говорит нам о результате выполнения запроса: был ли он успешным, возникла ли ошибка на стороне клиента или сервера и т.д. Post-request скрипты позволяют автоматизировать эту проверку.

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

Проверка кода статуса – это основа основ тестирования API. Это позволяет быстро понять, был ли запрос обработан корректно или нет.

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

Предположим, вы отправляете POST запрос на создание нового пользователя, и в случае успеха API должен вернуть код статуса 201 Created.

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

pm.test("Status code is 201", function () {
    pm.response.to.have.status(201);
});

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

• pm.test() – это функция Postman, которая позволяет создавать тесты. В качестве первого аргумента передается название теста (оно будет отображаться в результатах).

• Вторым аргументом передается функция, которая содержит сам код проверки.

• pm.response – это объект, представляющий полученный ответ.

• to.have.status(201) – это утверждение (assertion) из встроенной библиотеки Postman, которое проверяет, что код статуса ответа равен 201.

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

Добавьте этот скрипт во вкладку "Tests" вашего запроса на создание пользователя. После выполнения запроса в разделе "Test Results" вы увидите, прошел тест или нет.

В тестировании бекенда довольно частая ситуация, когда API возвращает код статуса 200 OK даже при ошибках создания ресурса, а при этом детали ошибки передаются в теле ответа. Хотя мы и должны всегда проверять тело ответа, наличие явной проверки на ожидаемый код 201 (если это предусмотрено нашей документацией), позволяет нам мгновенно выявить эту проблему. Такой же подход к тестированию кода ответа мы можем применить и к другим статус-кодам.

Ускоряем работу: Используем встроенные сниппеты Postman

Прежде чем мы начнем писать наш первый скрипт вручную, стоит упомянуть об одной из самых полезных функций Postman для начинающих — встроенных сниппетах (Snippets). Это готовые фрагменты кода для наиболее распространенных тестовых проверок, которые можно добавить в редактор тестов одним кликом.

Где их найти?

Открыв вкладку "Tests", вы увидите справа панель с заголовком SNIPPETS. Прокрутив ее, вы найдете множество заготовок для различных задач, от проверки статус-кода до извлечения переменных.

Как это упрощает жизнь начинающему тестировщику?

Использование сниппетов — это самый быстрый способ начать писать тесты, даже если вы еще не знакомы с синтаксисом JavaScript или Postman API.

1 Простота: Вам не нужно запоминать сложные конструкции. Просто найдите нужный сниппет и кликните по нему.

2 Скорость: Это экономит массу времени на написание повторяющегося кода.

3 Обучение: Анализируя код, который генерируют сниппеты, вы быстрее учитесь синтаксису и основным методам Postman API (pm.*).

Практический пример со статус-кодом:

Вместо того чтобы писать код для проверки статус-кода с нуля, найдите в списке сниппетов строку "Status code: Code is 200" и нажмите на нее.

Postman автоматически добавит в окно тестов следующий код:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

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

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

Проверка на конкретный код, например 201, — это хорошо, но что, если API в разных ситуациях может возвращать разные успешные коды? Например, 201  при успешном создания ресурса и 202 Accepted, если запрос принят в обработку, но еще не выполнен. Жесткая привязка к одному коду может сделать наш тест хрупким (brittle).

Чтобы сделать тест более гибким и соответствующим стандартам HTTP (где любой код 2xx означает успех), мы можем проверять, что код ответа находится в диапазоне успешных значений.
Давайте изменим наш тест так, чтобы он проходил успешно для любого кода от 201 до 299
JavaScript

pm.test("Status code is successful (2xx)", function () {
    pm.expect(pm.response.code).to.be.within(200, 299);
});

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

• pm.response.code — это свойство, которое содержит числовое значение HTTP-кода ответа.

• .to.be.within(200, 299) — это утверждение из библиотеки Chai, которое проверяет, что значение (pm.response.code) попадает в указанный диапазон, включая граничные значения.

Разумеется такой подход не всегда оправдан и его применение, как и все тестирование, зависит от контектса.

2. Извлечение данных из тела ответа и сохранение их в переменные

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

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

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

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

Предположим, вы отправляете POST запрос на создание нового пользователя по адресу /users, и в теле ответа получаете JSON с ID созданного пользователя: {"id": "user123"}.

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

JavaScript

const responseJson = pm.response.json();
const userId = responseJson.id;

if (userId) {
    pm.environment.set("userId", userId);
    console.log("ID пользователя извлечен:", userId);
} else {
    console.warn("ID пользователя не найден в ответе.");
}

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

• pm.response.json() – это функция Postman, которая парсит тело ответа, если оно имеет формат JSON, и возвращает JavaScript объект.

• Мы обращаемся к свойству id этого объекта, чтобы получить значение ID пользователя.

• С помощью условного оператора if мы проверяем, что ID был найден в ответе.

• Если ID найден, мы сохраняем его в переменную окружения userId с помощью функции pm.environment.set(). Теперь мы можем использовать эту переменную в других запросах как {{userId}}.

• Если ID не найден, мы выводим предупреждение в консоль.

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

После создания пользователя вы можете использовать переменную {{userId}} в последующих запросах, например, для получения информации об этом пользователе по адресу /users/{{userId}} или для его удаления.

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

3. Валидация структуры и конкретных значений в теле ответа

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

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

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

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

Предположим, вы отправляете запрос на получение информации о пользователе, и API возвращает JSON-ответ с полями id, name и email. Вы хотите убедиться, что все эти поля присутствуют, а поле name имеет определенное значение.

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

pm.test("Response body contains expected fields and values", function () {
    const responseJson = pm.response.json();

    // Проверяем наличие поля 'id'
    pm.expect(responseJson).to.have.property('id');

    // Проверяем наличие поля 'name' и его значение
    pm.expect(responseJson).to.have.property('name').that.equals('John Doe');

    // Проверяем наличие поля 'email' и его тип
    pm.expect(responseJson).to.have.property('email').that.is.a('string');
});

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

• Мы снова используем функцию pm.test() для создания тестового шага.

• pm.response.json() парсит тело ответа в JSON-объект.

• pm.expect(responseJson).to.have.property('имя_поля') – это утверждение, которое проверяет наличие указанного поля в объекте.

• .that.equals('ожидаемое_значение') – проверяет, что значение поля равно ожидаемому.

• .that.is.a('тип_данных') – проверяет тип данных поля (например, 'string', 'number', 'boolean', 'array', 'object').

Дополнительный скрипт для проверки сообщений об ошибках в ответах API (Error Message Validation). Это полезно для негативного тестирования, чтобы убедиться, что API возвращает информативные ошибки без раскрытия чувствительных данных, как рекомендует OWASP и стандарты ISTQB. Скрипт автоматизирует валидацию, избавляя от ручного анализа.

pm.test("Error message is correct and present", () => {
    let responseJson;
    try {
        responseJson = pm.response.json();  // Парсинг JSON-тела ответа
    } catch (e) {
        throw new Error("Failed to parse response as JSON");  // Обработка ошибок парсинга
    }
    
    // Проверка наличия поля 'error'
    pm.expect(responseJson).to.have.property('error');
    
    // Валидация точного сообщения об ошибке
    pm.expect(responseJson.error).to.be.a('string').that.equals("Invalid credentials");
    
    // Логирование для отладки
    console.log("Error message:", responseJson.error);
});

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

1. Создание теста: pm.test() запускает проверку после получения ответа, с descriptive названием для результатов в Postman.

2. Парсинг с try-catch: Извлекает JSON; если парсинг провалится (не-JSON или ошибка), тест фейлится с сообщением — предотвращает silent failures.

3. Проверка наличия поля: pm.expect().to.have.property() подтверждает, что 'error' существует в объекте.

4. Валидация значения: Проверяет тип (строка) и точное совпадение с ожидаемым сообщением; использует Chai для гибкости.

5. Логирование: Выводит сообщение в консоль для анализа, полезно в отладке или CI/CD.
   

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

Добавьте этот скрипт во вкладку "Tests" вашего запроса на получение информации о пользователе. После выполнения запроса вы увидите результаты проверки в разделе "Test Results". Такие автоматические проверки позволяют мгновенно выявлять проблемы с телом ответа, что значительно экономит время на исправление багов.

4. Валидация заголовков ответа

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

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

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

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

Предположим, вы ожидаете, что API вернет ответ в формате JSON, и это должно быть указано в заголовке Content-Type.

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

JavaScript

pm.test("Response has Content-Type application/json", function () {

    pm.response.to.have.header("Content-Type", "application/json");

});


// Вы также можете проверить наличие заголовка без указания его значения:

pm.test("Response has a Cache-Control header", function () {

    pm.response.to.have.header("Cache-Control");

});

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

• pm.response.to.have.header("имя_заголовка", "ожидаемое_значение") – проверяет наличие заголовка с указанным именем и значением.

• pm.response.to.have.header("имя_заголовка") – проверяет только наличие заголовка с указанным именем.

Проверка отсутствия нежелательного заголовка (для безопасности, например, отсутствие Server с версией сервера):
JavaScript

pm.test("Response does not expose Server header", function () {
    pm.expect(pm.response.headers.has("Server")).to.be.false;
});

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

Добавьте эти скрипты во вкладку "Tests" ваших запросов. После выполнения вы сможете увидеть, соответствуют ли заголовки ответа вашим ожиданиям.

В одном из проектов при тестировании API для e-commerce платформы, где безопасность была приоритетом (интеграция с платежными системами) иногда мог вернуться заголовок Server: Apache/2.4.1 в ответах, что раскрывает версию сервера и может быть использовано хакерами для targeted атак (как указано в OWASP API Security Top 10). Для оперативного выявления данной проблемы был добавлен скрипт на проверку отсутствия этого заголовка, интегрировав его в CI/CD пайплайн с Newman. В результате удалось поймать проблему на staging: разработчики забыли настроить сервер на скрытие заголовков. После фикса тесты стали частью регрессии, предотвратив подобные инциденты в production. Это сэкономило время на ручной аудит и повысило общую безопасность

5. Выполнение проверки схемы ответа (Schema Validation)

Для API с четко определенной структурой данных очень полезно проверять, соответствует ли тело ответа определенной схеме (например, JSON Schema). Это помогает обеспечить консистентность данных и быстро выявлять любые неожиданные изменения в структуре ответов API. Postman позволяет выполнять проверку схемы с помощью различных библиотек.

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

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

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

Предположим, у вас есть JSON Schema, описывающая структуру объекта пользователя. Вы можете использовать следующий скрипт для проверки того, соответствует ли ответ API этой схеме.

JavaScript

const responseJson = pm.response.json();

const schema = {

    "type": "object",

    "properties": {

        "id": {"type": "string"},

        "name": {"type": "string"},

        "email": {"type": "string", "format": "email"},

        "age": {"type": "integer", "minimum": 18}

    },

    "required": ["id", "name", "email", "age"]

};

pm.test("Response body should match schema", function () {
    pm.expect(tv4.validate(responseJson, schema)).to.be.true;
});

Примечание: В более новых версиях Postman библиотека tv4 может быть устаревшей. Возможно, вам потребуется использовать другие библиотеки, такие как ajv, или реализовать собственную логику валидации. Пример с использованием ajv (может потребоваться подключение библиотеки к коллекции):

JavaScript

const responseJson = pm.response.json();

const schema = {

    "type": "object",

    "properties": {

        "id": {"type": "string"},

        "name": {"type": "string"},

        "email": {"type": "string", "format": "email"},

        "age": {"type": "integer", "minimum": 18}

    },

    "required": ["id", "name", "email", "age"]

};

 

pm.test("Response body should match schema", function () {

    const Ajv = require('ajv');

    const ajv = new Ajv();

    const validate = ajv.compile(schema);

    pm.expect(validate(responseJson)).to.be.true;

});

Для простоты в статье для начинающих мы можем использовать пример с tv4, упомянув о возможной устарелости и альтернативах.

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

• Мы определяем JSON Schema, описывающую ожидаемую структуру ответа.

• pm.response.json() парсит тело ответа в JSON-объект.

• tv4.validate(responseJson, schema) (или аналогичная функция из другой библиотеки) проверяет, соответствует ли полученный JSON-объект определенной схеме.

• pm.expect(...).to.be.true проверяет, что результат валидации является истинным (то есть ответ соответствует схеме).

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

Создайте JSON Schema для ответов вашего API и используйте этот скрипт для автоматической проверки их соответствия.

В одном из проектов API возвращало довольно сложные структуры данных. И здесь была использована JSON Schema для описания ожидаемого формата каждого ответа. Регулярная проверка ответов на соответствие этим схемам помогла тестировщикам быстро выявлять любые несоответствия и предотвращать потенциальные проблемы на интеграции. Существует множество онлайн-инструментов, которые могут помочь вам сгенерировать JSON Schema на основе примеров JSON-ответов.

6. Установка переменных окружения условно на основе ответа

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

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

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

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

Предположим, вы отправляете запрос на авторизацию (/login), и в случае успеха API возвращает в теле ответа поле status со значением "success". Вы хотите установить переменную окружения isLoggedIn в значение "true", если авторизация прошла успешно.

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

JavaScript

const responseJson = pm.response.json();

if (responseJson.status === "success") {
    pm.environment.set("isLoggedIn", "true");
    console.log("Авторизация успешна. 'isLoggedIn' установлено в true.");
} else {
    pm.environment.set("isLoggedIn", "false");
    console.log("Авторизация не удалась. 'isLoggedIn' установлено в false.");
}

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

• Скрипт парсит JSON-тело ответа.

• С помощью условного оператора if он проверяет значение поля status.

• В зависимости от значения этого поля, он устанавливает значение переменной окружения isLoggedIn в "true" или "false".

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

В последующих запросах вы можете использовать переменную {{isLoggedIn}} в pre-request скриптах или в самом запросе, чтобы определить, нужно ли выполнять определенные действия или нет.

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

7. Логирование деталей ответа или ошибок

При тестировании, особенно при отладке или в сложных сценариях, бывает полезно выводить в консоль Postman какую-либо информацию из ответа API, например, определенные поля, сообщения об ошибках или даже весь JSON-ответ целиком. Post-request скрипты позволяют это сделать.

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

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

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

Предположим, вы хотите вывести в консоль значение определенного поля (orderId) из тела ответа.

JavaScript

const responseJson = pm.response.json();
const orderId = responseJson.orderId;

if (orderId) {
    console.log("ID заказа получен:", orderId);
} else {
    console.warn("ID заказа не найден в ответе.");
    console.log("Полный ответ:", responseJson); // Выводим весь ответ для отладки
}

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

• Скрипт парсит JSON-тело ответа.

• Получает значение поля orderId.

• С помощью console.log() выводит значение в консоль Postman. Если поле не найдено, выводится предупреждение и весь ответ целиком для анализа.

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

Используйте console.log() для вывода любой полезной информации из ответа, которая может помочь вам в понимании работы API или в отладке тестов.

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

8. Измерение времени ответа (Measuring Response Time)

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

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

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

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

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

JavaScript

pm.test("Response time is less than 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

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

• pm.response.responseTime – это встроенное свойство Postman, которое содержит время ответа в миллисекундах.

• pm.expect(...).to.be.below(500) – это утверждение, которое проверяет, что время ответа меньше 500 мс.

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

Добавьте этот тест в ваши запросы, чтобы контролировать производительность API: убедиться, что API работает достаточно быстро и не будет вызывать задержек в работе приложения.

9. Визуализация данных ответа (Visualizing Response Data)

Postman предоставляет возможность визуализировать данные ответа в различных форматах (например, в виде таблиц, графиков) с помощью вкладки "Visualize" и шаблонизатора Handlebars. Хотя код для визуализации размещается во вкладке "Tests" (post-request скрипты), это способ представить полученные данные более наглядно.

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

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

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

Предположим, ваш API возвращает массив объектов пользователей, и вы хотите отобразить их в виде таблицы.

JavaScript

const responseJson = pm.response.json();

// Следующий код необходимо разместить во вкладке "Visualize":
// ```html
// <table border="1">
//     <thead>
//         <tr>
//             <th>ID</th>
//             <th>Name</th>
//             <th>Email</th>
//         </tr>
//     </thead>
//     <tbody>
//         {{#each response}}
//             <tr>
//                 <td>{{id}}</td>
//                 <td>{{name}}</td>
//                 <td>{{email}}</td>
//             </tr>
//         {{/each}}
//     </tbody>
// </table>
// ```

// А в post-request скрипте (вкладке "Tests") нужно установить визуализатор:
pm.visualizer.set(pm.response.text(), { response: responseJson });

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

• В post-request скрипте мы получаем JSON-ответ и передаем его в функцию pm.visualizer.set().

• В шаблоне Handlebars (во вкладке "Visualize") мы описываем, как именно нужно отобразить эти данные (в данном случае – в виде HTML-таблицы).

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

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

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

10. Запуск утверждений на основе времени ответа

Мы уже рассмотрели простой тест на время ответа. Иногда может потребоваться более сложная логика проверок, основанная на времени ответа и других параметрах.

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

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

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

Предположим, вы хотите проверить, что если API возвращает код статуса 200 OK, то время ответа должно быть меньше 500 мс, а если возвращается код ошибки (например, 500), то допустимое время ответа может быть больше (например, до 1000 мс).

JavaScript

pm.test("Response time is acceptable based on status code", function () {
    if (pm.response.code === 200) {
        pm.expect(pm.response.responseTime).to.be.below(500);
    } else if (pm.response.code === 500) {
        pm.expect(pm.response.responseTime).to.be.below(1000);
    }
});

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

• Скрипт проверяет код статуса ответа.

• В зависимости от кода статуса, он выполняет разные проверки времени ответа.

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

Используйте эту технику для создания более контекстных тестов производительности.