Comments 11
Спойлеры - это очень плохой способ форматировать статьи. Можно же якорные ссылки использовать, если хотите оглавление сделать.
По мне проще сразу уже автотесты написать и в Jenkins, чем вот это все.
С автотестами согласен, но ручники их не пишут, а в Postman как-то нужно находить выход. Так что это полезные скрипты в данном контексте.
Есть куча мест когда тесты, особенно в CI просто не нужны и даже вредны:
У тебя в проекте может не быть автоматических тестов для API. Напримр, в вашей команде уровень контрактных тестов находится на стороне аццептора, а на стороне инициатора только проверка на изменение сваггера. Сответственно, писать дополнительный код, который тебе нужен, который увеличит тест-таймы в процессе разработки, и удалить его после разработки, так как не пропускает QA, только для того чтобы понять полный пайплайн какого то процесса - ну так себе.
Ты разрабатываешь какую то часть пайплайна БП. Но, в этом пайплайне есть ещё куча апишек, которые тебе надо дернуть для того чтобы утилизировать артефакты тестирования. В CI это завязано на то что на регрессе просто создается база с нуля. Но в ручном тестировании каждый раз создавать тестовое окружение с 0 это
ебудатьможнооверкиллУ тебя нет полной документации к апи, и код тебе не дают. Для исследований писать вечно зеленые тесты - ну, ой...
И ещё десяток
Это бывает для ручного тестирования полезно. Ускоряет процесс, когда надо на каких-то новых данных единичные кейсы проверить. Именно с точки зрения покрытия регресса конечно хрень
Несколько вопросов, исходя из выбранных подходов:
1. Поясните в чем смысл вашего второго примера "Настройка условных данных в зависимости от окружения (Environment)" ?
1.1 Изначально в Postman создаются окружения, и для каждого из окружений задаются переменные окружения (естественно, названия переменных между окружениями одинаковые, только разнятся значения), дальше в тестах используются переменные и вы ПРОСТО ПЕРЕКЛЮЧИВ ОКРУЖЕНИЕ и получаете переменные с нужным значением (при этом коллекция запросов естественно одна). Зачем городить что-то в пререквесте?
1.2 В этом же месте "Как отмечается в стандартах ISTQB, тестирование должно проводиться в окружениях, максимально приближенных к реальным, и этот скрипт помогает нам в этом." - ваш пререквест скрипт вообще не связан с этим пунктом из ISTQB, эта цитата говорит о качестве тестовых стендов (наборе данных на этих стендах и их поведении, которые максимально должны мимикрировать продакшен). А переключение окружений уж никак не связано с характеристиками окружений.
2. Вопрос касательно 10-го примера: "Разделение или обработка строк для параметров".
В примере якобы ситуация, где в переменную окружения productIds были сохранены ID, разделенные запятыми и чтобы это все дело извлечь и преобразовать и городится пререквест скрипт.
В связи с чем вопросы:
2.1 Почему все нужные преобразования не делаются на этапе сохранения в переменную (в данном случае productIds)
2.2 Почему подобная переменная сохранена в переменных окружения, а не как переменная коллекции?
3. Не нашел примера про отправку запроса на эндпойнт, отличный от проверяемого, для получения данных в пререквесте с использованием pm.sendRequest()-На мой скромный взгляд довольно полезная опция, которой не раз пользовался.
Добрый день! Огромное спасибо за ваши вопросы, замечания и дополнения! Это очень ценно для меня и многих читателей Хабра.
Отвечу на каждый ваш вопрос по порядку.
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}}.
Это хороший пример для дополнения статьи или для будущих материалов. Еще раз спасибо за ценное предложение!
Еще за благодарю вас за ценные замечания, вопросы и дополнения! Успехов вам! Если остались еще вопросы, задавайте: с радостью постараюсь ответить.
Спасибо за ответы!
Но все равно осталось противоречие:
В пункте 1.1 вы пишете:
Представьте, что в зависимости от окружения (dev, stage) у вас должны меняться не только URL, но и набор API-ключей, ID пользователей для тестов, и даже включаться или выключаться определенные feature flags. Скрипт на уровне коллекции позволяет собрать всю эту логику в одном месте.
А ниже в пункте 2.2:
Переменная окруженияиспользуется для данных, которыеразличаютсямежду dev, stage и prod (URL, пароли, API-ключи).
Сохранение productIds в переменной окружения было бы оправдано только в одном специфическом случае: если набор продуктов, которые мы тестируем, должен быть разным для каждого окружения.
В итоге я веду к тому, что если взять себе за правило сохранять переменные в нужном месте, то это может сильно упростить жизнь, и избавит вас от скриптов, которые казались "полезными". Ведь, как и в случае с дракой - лучший код - это код, который не нужно было писать.
Автоматизация рутины в Postman (часть 1): 10 pre-request скриптов, которые мне упростили жизнь