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

[fedorro]

Спойлеры - это очень плохой способ форматировать статьи. Можно же якорные ссылки использовать, если хотите оглавление сделать.

[egusinets]

А а мне наоборот кажется, что так удобно. Каждый выберет себе тот скрипт который ему нужен. Конкретно в этой ситуации по-моему оптимальное решение. Хотя и вы тоже правы, ну я не умею якорные ссылки делать.

[fedorro]

Хабр и так узкий, а спойлеры ещё места отъедают. А ещё кликать надо постоянно, чтобы, всё посмотреть. Ну люди же тут как-то их делают. Или Вы в принципе не знакомы с якорными ссылками? Просто странно слышать это от человека, который знаком с пре-скриптами постмана)

[Odnokletochnoe]

По мне проще сразу уже автотесты написать и в Jenkins, чем вот это все.

[egusinets]

С автотестами согласен, но ручники их не пишут, а в Postman как-то нужно находить выход. Так что это полезные скрипты в данном контексте.

[Odnokletochnoe]

А кто их пишет ?)

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

[grant7]

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

[Odnokletochnoe]

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

[grant7]

Ещё раз прочтите, что вам ответили- "ручники их не пишут", это означает, что ручной тестировщик не пишет автотесты на ЯП и не использует автоматизированных средств их запуска, вы же продолжаете упорствовать.

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

Про радость написано "из вежливости", не обольщайтесь.

[Odnokletochnoe]

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

[grant7]

Успокаивать себя- это верный путь.

Статья не о том как упростить, а о том как можно воспользоваться конкретным инструментом. Стоит упираться в конкретные инструменты или не стоит и в какие- это вопрос десятый и просто "не твоё дело". Хочешь заявить- напиши свою статью, а не учи людей как правильно работать и каким специалистом быть.

Тебе дали понять, что данный кейс такой- "1.Автотесты не пишутся, 2.Используется Postman", это кейс, который имеет место быть в реальности и рассматривается только он. Что тут непонятного?

[Odnokletochnoe]

Непонятно мне то, что ты с чего-то взял на себя роль указывать, что кому нужно делать, а я лишь озвучил как я бы поступил, но тебе видимо нечем заняться, раз так, то продолжим.

Как я и написал в своем первом комментарии, по мне лучше написать автотесты невзирая на все доводы против. Я нигде не писал, что мой метод лучше и что всем нужно его использовать, тут ты уже придумываешь это из воздуха тк тебе не за что зацепиться, а зацепиться надо, не проходить же мимо. Нужно кому-то объяснить, что это не его дело. Лол.

[grant7]

Вот твои слова 1 и 2:

1. "Вроде никто не мешает самому написать их, чтобы упростить себе жизнь, даже если на вашем проекте это никому неинтересно."

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

Ты и в первом, и втором утверждении ошибаешься.

С чего ты решил что "никто не мешает самому написать"?

"можно начать их писать" - кому можно? А если нельзя, то что, тот не тестировщик, или менее ценен, чем тот кто пишет?

"Посыл очень прост, не стоит упираться в один инструмент." - а этим ты указываешь всем как быть. Ты задачи знаешь которые решаются, в каких условиях, и за какие сроки? И причём здесь "быть более ценным специалистом", ведь обсуждается конкретный инструмент и решаемые задачи, даже без условий?

[Odnokletochnoe]

Я на такой бред даже отвечать не буду.

[aavezel]

Есть куча мест когда тесты, особенно в CI просто не нужны и даже вредны:

1. У тебя в проекте может не быть автоматических тестов для API. Напримр, в вашей команде уровень контрактных тестов находится на стороне аццептора, а на стороне инициатора только проверка на изменение сваггера. Сответственно, писать дополнительный код, который тебе нужен, который увеличит тест-таймы в процессе разработки, и удалить его после разработки, так как не пропускает QA, только для того чтобы понять полный пайплайн какого то процесса - ну так себе.

2. Ты разрабатываешь какую то часть пайплайна БП. Но, в этом пайплайне есть ещё куча апишек, которые тебе надо дернуть для того чтобы утилизировать артефакты тестирования. В CI это завязано на то что на регрессе просто создается база с нуля. Но в ручном тестировании каждый раз создавать тестовое окружение с 0 это ебудатьможно оверкилл

3. У тебя нет полной документации к апи, и код тебе не дают. Для исследований писать вечно зеленые тесты - ну, ой...

4. И ещё десяток

[ilinataly]

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

[Paczuk]

Несколько вопросов, исходя из выбранных подходов:

1. Поясните в чем смысл вашего второго примера "Настройка условных данных в зависимости от окружения (Environment)" ?

1.1 Изначально в Postman создаются окружения, и для каждого из окружений задаются переменные окружения (естественно, названия переменных между окружениями одинаковые, только разнятся значения), дальше в тестах используются переменные и вы ПРОСТО ПЕРЕКЛЮЧИВ ОКРУЖЕНИЕ и получаете переменные с нужным значением (при этом коллекция запросов естественно одна). Зачем городить что-то в пререквесте?

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

2. Вопрос касательно 10-го примера: "Разделение или обработка строк для параметров".
В примере якобы ситуация, где в переменную окружения productIds были сохранены ID, разделенные запятыми и чтобы это все дело извлечь и преобразовать и городится пререквест скрипт.
В связи с чем вопросы:

2.1 Почему все нужные преобразования не делаются на этапе сохранения в переменную (в данном случае productIds)

2.2 Почему подобная переменная сохранена в переменных окружения, а не как переменная коллекции?

3. Не нашел примера про отправку запроса на эндпойнт, отличный от проверяемого, для получения данных в пререквесте с использованием pm.sendRequest()-На мой скромный взгляд довольно полезная опция, которой не раз пользовался.

[egusinets]

Добрый день! Огромное спасибо за ваши вопросы, замечания и дополнения! Это очень ценно для меня и многих читателей Хабра.

Отвечу на каждый ваш вопрос по порядку.
1.1. Зачем нужен скрипт, если есть нативное переключение окружений?

Ответ:
Вы совершенно правы: для простого переключения базового URL (baseUrl) или одного-двух параметров между стендами стандартный механизм окружений Postman — это самый правильный и предпочтительный способ. В этом случае скрипт действительно будет избыточным.

Однако, предложенный в статье скрипт решает более сложные, "нестандартные" задачи, которые часто возникают в реальных проектах:

• Централизация сложной логики: Представьте, что в зависимости от окружения (dev, stage) у вас должны меняться не только URL, но и набор API-ключей, ID пользователей для тестов, и даже включаться или выключаться определенные feature flags. Скрипт на уровне коллекции позволяет собрать всю эту логику в одном месте. Это делает коллекцию более читаемой и самодокументируемой. Новый человек в команде сразу видит всю логику конфигурации, а не ищет переменные по разным окружениям.

• Производные и дефолтные значения: Скрипт позволяет задавать значения по умолчанию. Например, если переменная environment не задана, он автоматически выберет dev, предотвращая случайные запросы на prod. Также он позволяет создавать производные переменные: например, reportsUrl может быть динамически сформирован как {{baseUrl}}/reports.

  
  1.2. О связи с цитатой из ISTQB

Здесь я также должен с вами полностью согласиться. Вы абсолютно точно интерпретировали посыл ISTQB: стандарт говорит о качестве самого тестового стенда — его данных, конфигурации, производительности, которые должны быть максимально приближены к production.

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

2.1. Почему бы не сохранять данные сразу в правильном формате?

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

Как вы правильно заметили, скрипт №10 описывает именно такой случай. Откуда может взяться такая строка, как "123,456,789"? В "примере ихз практики" к этому скрипту как раз и дан ответ:

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

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

2.2. Почему environment, а не collection?

Здесь вы абсолютно правы, в большинстве случаев такая переменная, как productIds, должна храниться на уровне коллекции (collection variable).

• Переменная коллекции используется для данных, которые относятся ко всей коллекции в целом и не меняются от стенда к стенду (например, userId для тестового сценария, productIds для проверки конкретного набора товаров).

• Переменная окружения используется для данных, которые различаются между dev, stage и prod (URL, пароли, API-ключи).

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

3 Не нашел примера про отправку запроса на эндпойнт, отличный от проверяемого, для получения данных в пререквесте с использованием pm.sendRequest()"

Ответ:

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

Этот подход незаменим, когда для выполнения основного запроса (например, создание заказа) нам нужны данные, которые нужно сперва получить из другого эндпоинта (например, ID клиента или актуальный promoCode).

Вот как мог бы выглядеть такой скрипт:

Пример: Получение ID клиента перед созданием заказа

Предположим, для создания заказа (POST /orders) нам нужен customerId. Мы можем получить его из эндпоинта GET /customers.

Pre-request скрипт для запроса POST /orders:

JavaScript

// Проверяем, есть ли у нас уже ID клиента, чтобы не делать лишних запросов
if (!pm.collectionVariables.get("customerId")) {
    console.log("ID клиента не найден, запрашиваю...");

    pm.sendRequest({
        url: '{{baseUrl}}/customers?limit=1', // Запрашиваем первого попавшегося клиента
        method: 'GET',
        header: {
            'Authorization': 'Bearer {{accessToken}}'
        }
    }, function (err, response) {
        if (err || response.code !== 200) {
            console.error("Не удалось получить клиента:", err || response.status);
        } else {
            const customer = response.json()[0]; // Берем первый объект из массива
            if (customer && customer.id) {
                pm.collectionVariables.set("customerId", customer.id);
                console.log(`ID клиента ${customer.id} получен и сохранен.`);
            }
        }
    });
} else {
    console.log(`Используется существующий ID клиента: ${pm.collectionVariables.get("customerId")}`);
}

После выполнения этого скрипта, в теле основного запроса POST /orders мы можем смело использовать переменную {{customerId}}.

Это хороший пример для дополнения статьи или для будущих материалов. Еще раз спасибо за ценное предложение!

Еще за благодарю вас за ценные замечания, вопросы и дополнения! Успехов вам! Если остались еще вопросы, задавайте: с радостью постараюсь ответить.

[Paczuk]

Спасибо за ответы!
Но все равно осталось противоречие:

В пункте 1.1 вы пишете:

Представьте, что в зависимости от окружения (dev, stage) у вас должны меняться не только URL, но и набор API-ключей, ID пользователей для тестов, и даже включаться или выключаться определенные feature flags. Скрипт на уровне коллекции позволяет собрать всю эту логику в одном месте.

А ниже в пункте 2.2:

• Переменная окружения используется для данных, которые различаются между dev, stage и prod (URL, пароли, API-ключи).

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

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