Проектирование коллекций Postman для тестирования банковского API на примере ВТБ Онлайн

Основы работы и конфигурация переменных окружения в Postman

Представьте, что вам нужно протестировать перевод между счетами в банковском приложении на трех разных стендах: тестовом (Dev), предрелизном (Staging) и промышленном (Production). В каждом случае адрес сервера, номер карты отправителя и ключи доступа будут отличаться. Если вы пропишете эти данные вручную в теле каждого запроса, то при смене среды тестирования вам придется вручную изменять десятки, а то и сотни параметров. В банковских системах уровня ВТБ Онлайн, где количество микросервисов исчисляется сотнями, такой подход неизбежно приведет к критическим ошибкам и потере актуальности тестовой модели.

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

Анатомия банковского запроса и роль абстракции

Любой запрос к банковскому API, будь то получение баланса или создание платежного поручения, состоит из констант и переменных. Константа — это метод (например, POST) и путь ресурса (/api/v1/payments). Переменная — это базовый URL сервера, версия API, токен авторизации и идентификаторы клиента.

В контексте ВТБ Онлайн мы сталкиваемся с повышенными требованиями к безопасности и строгой типизацией данных. Банковское API часто требует передачи специфических заголовков, таких как X-MDT-Signature или X-Device-ID. Если идентификатор устройства изменится, а он зашит в 50 запросов коллекции, тестирование остановится.

Использование переменных позволяет внедрить принцип DRY (Don't Repeat Yourself — не повторяйся). Вместо того чтобы писать https://api.vtb.ru/mobile/v2/auth, мы пишем {{baseUrl}}/{{apiVersion}}/auth. Это создает гибкую систему, где один и тот же набор запросов может мгновенно переключаться между разными конфигурациями данных.

Иерархия областей видимости в Postman

Для грамотного проектирования коллекции важно понимать, где именно хранить данные. В Postman существует пять уровней областей видимости (scopes). Чем уже область видимости, тем выше её приоритет. Если переменная с одним и тем же именем объявлена на разных уровнях, Postman выберет ту, что находится «ближе» к запросу.

Global (Глобальные переменные). Доступны во всех коллекциях и окружениях внутри одного рабочего пространства (Workspace). Обычно здесь хранят общие настройки, не привязанные к конкретному проекту.

Collection (Переменные коллекции). Живут внутри конкретной папки-коллекции. Идеально подходят для данных, которые специфичны для ВТБ Онлайн, но не меняются при смене серверов (например, тайм-ауты или общие форматы дат).

Environment (Окружения). Это ключевой инструмент для банковского тестирования. Вы создаете отдельный файл окружения для «VTB-Test» и «VTB-Preprod». Переключая их в выпадающем списке, вы меняете значения всех переменных разом.

Data (Данные из внешних файлов). Используются при запуске коллекций через Runner или Newman (например, при загрузке списка из 1000 номеров карт из CSV-файла).

Local (Локальные переменные). Существуют только во время выполнения конкретного скрипта или запроса.

В банковской практике чаще всего используется связка Environment + Collection. В окружение выносятся параметры инфраструктуры (хосты, порты), а в коллекцию — логические параметры сценариев.

Настройка окружения для ВТБ Онлайн

Рассмотрим практический процесс создания окружения. В интерфейсе Postman это делается через вкладку «Environments» в левой панели. При создании нового окружения (назовем его VTB_Stage_1) мы заполняем таблицу с тремя колонками: Variable, Initial Value и Current Value.

Различие между Initial Value и Current Value критически важно для безопасности: * Initial Value (Исходное значение): Синхронизируется с облаком Postman. Его увидят ваши коллеги по команде. Сюда нельзя вносить реальные пароли, пин-коды или секретные ключи банковских карт. * Current Value (Текущее значение): Хранится только локально на вашем компьютере. Именно это значение используется при отправке запроса. Здесь мы храним временные сессионные токены и персональные данные.

Базовый набор переменных для старта

Для работы с API ВТБ Онлайн на начальном этапе нам понадобятся следующие переменные:

| Переменная | Пример значения | Описание | | :--- | :--- | :--- | | baseUrl | https://gate-stage.vtb.ru | Адрес шлюза API | | apiVersion | v1 | Текущая версия протокола | | clientId | VTB-MOB-ANDROID-4.2 | Идентификатор типа клиента | | deviceId | 550e8400-e29b-41d4-a716 | Уникальный ID устройства (UUID) |

После того как переменные созданы, их можно вызвать в любом поле запроса (URL, Headers, Body) с помощью двойных фигурных скобок: {{variable_name}}.

Динамические переменные и генерация данных

Банковские системы часто блокируют повторные запросы с идентичными параметрами (защита от дублирования транзакций или replay-атак). Для тестирования нам нужно каждый раз генерировать уникальные значения, например, номер транзакции или идентификатор устройства.

Postman имеет встроенную библиотеку динамических переменных, которые начинаются со знака guid}} — генерирует уникальный идентификатор (UUID v4). Идеально подходит для заголовка X-Request-ID. * {{randomInt}} — случайное целое число.

Пример использования в теле запроса (JSON):

Здесь deviceId берется из настроенного окружения, а requestId и clientTimestamp генерируются «на лету» для каждого клика по кнопке Send.

Работа с секретами и безопасность данных

В банковской сфере безопасность — это не опция, а фундамент. При работе с Postman существует риск случайной утечки чувствительных данных. Например, если вы добавите в Initial Value реальный токен доступа к счету и нажмете «Save», этот токен улетит на серверы Postman.

Правила «гигиены» при работе с банковскими API:

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

Никогда не заполняйте Initial Value для паролей. Оставляйте это поле пустым. При импорте коллекции коллега сам впишет свой тестовый пароль в Current Value.

Очистка переменных. Если вы используете скрипты для автоматического получения токена, убедитесь, что они записывают данные в Current Value.

Отладка и мониторинг переменных

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

Инструмент 1: Quick Look (Глаз)

В правом верхнем углу окна Postman есть иконка глаза. Нажав на неё, вы увидите список всех активных переменных окружения и глобальных переменных с их текущими значениями. Если переменная подсвечена красным цветом в URL запроса — значит, она не определена в текущем выбранном окружении.

Инструмент 2: Postman Console

Это «черный ящик» вашего тестирования. Нажмите Ctrl + Alt + C (или Cmd + Option + C на Mac), чтобы открыть консоль. Здесь отображается реальный сформированный запрос. Если вы отправили {{baseUrl}}/login, в консоли вы увидите https://api.vtb.ru/login. Консоль — это первый пункт назначения, если сервер вернул ошибку 404 (неверный URL) или 401 (ошибка авторизации из-за неверного токена).

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

Для закрепления материала настроим окружение для гипотетического API ВТБ Онлайн.

Создайте окружение VTB_Sandbox.

Добавьте переменную host со значением https://api-sandbox.vtb.ru.

В коллекции создайте новый GET-запрос: {{host}}/info/status.

Перейдите на вкладку Headers и добавьте заголовок X-App-ID. В качестве значения укажите {{$guid}}. Это позволит банку отслеживать каждый ваш запрос как уникальный.

Выберите созданное окружение в выпадающем списке справа сверху.

Нажмите Send.

Если все настроено верно, Postman заменит {{host}} на реальный адрес, сгенерирует уникальный ID приложения и отправит запрос. В консоли вы увидите чистый HTTP-трафик без фигурных скобок.

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

Механизмы банковской авторизации и реализация первого входа в систему

Представьте, что вы пытаетесь войти в хранилище банка. У вас есть ключ, но охранник на входе требует не только его, но и паспорт, подтверждение личности через СМС, а затем выдает временный пропуск, который нужно прикладывать к каждому турникету внутри здания. В мире банковских API этот процесс называется многофакторной аутентификацией (MFA), и он значительно сложнее, чем простая связка «логин-пароль», к которой мы привыкли в социальных сетях. Ошибка в проектировании хотя бы одного шага в Postman приведет к тому, что вся ваша коллекция тестов превратится в набор нерабочих запросов, как только истечет время жизни сессии.

Архитектура безопасности: почему нельзя просто войти

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

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

> Токен — это цифровой эквивалент временного пропуска. Он имеет ограниченный срок жизни и строго определенные права доступа. > > RFC 6749 - The OAuth 2.0 Authorization Framework

Для тестировщика это означает, что цепочка авторизации становится «фундаментом» коллекции. Если вы не автоматизируете получение и обновление токена, вам придется каждые 15–20 минут вручную перехватывать данные из мобильного приложения или браузера и вставлять их в переменные Postman.

Этапы «рукопожатия» в банковском API

Процесс входа в ВТБ Онлайн можно разделить на три критических этапа. Каждый из них требует специфических заголовков и параметров в теле запроса.

1. Идентификация и проверка устройства

Прежде чем спросить пароль, банк должен убедиться, что запрос идет от доверенного приложения. На этом этапе проверяются такие параметры, как deviceId, client_id и версия операционной системы. Сервер анализирует «отпечаток» (fingerprint) устройства. Если вы используете Postman, вам необходимо имитировать эти данные в заголовках, иначе сервер вернет ошибку 403 Forbidden еще до начала авторизации.

2. Первичная аутентификация (Login)

Здесь передаются учетные данные пользователя. В банковской сфере пароль редко передается в открытом виде. Часто используется предварительное шифрование на стороне клиента или передача через защищенный туннель. Результатом успешного выполнения этого запроса не является доступ к счету. Банк лишь подтверждает: «Да, такой пользователь существует, и пароль верный. Теперь докажите, что это вы, через второй фактор».

3. Второй фактор и получение Access Token

После ввода пароля система генерирует СМС-код или Push-уведомление. Только после отправки этого кода на специальный эндпоинт (например, /auth/confirm), сервер выдает заветную пару токенов:

Access Token: короткоживущий ключ (от 5 до 30 минут), который вставляется в заголовок Authorization: Bearer <token>.

Refresh Token: долгоживущий ключ, который нужен только для того, чтобы получить новый Access Token без повторного ввода пароля и СМС.

Реализация цепочки запросов в Postman

Для автоматизации этого процесса нам понадобится создать три последовательных запроса в коллекции. Главная задача — сделать так, чтобы данные из ответа первого запроса автоматически подставлялись в параметры второго.

Шаг 1: Запрос на инициацию сессии (POST /auth/init)

В теле запроса (Body) мы передаем идентификатор пользователя. Важно использовать переменные, созданные на предыдущем этапе обучения.

В разделе Tests этого запроса мы должны «поймать» идентификатор сессии (processId), который банк создает для отслеживания процесса входа. Без этого processId следующий запрос с паролем будет отклонен.

Шаг 2: Передача пароля (POST /auth/login)

Теперь мы отправляем пароль, привязывая его к полученному processId. На этом этапе банк обычно возвращает статус, указывающий на необходимость ввода СМС.

Шаг 3: Подтверждение (POST /auth/confirm)

Это финальная точка. Мы отправляем код из СМС (в тестовых средах это обычно статичная комбинация вроде 0000 или 1111). В ответ мы получаем объект:

Здесь кроется самый важный момент автоматизации. Чтобы не копировать access_token вручную во все остальные 50 запросов коллекции, мы пишем скрипт в закладке Tests:

Работа с Bearer Token и заголовками

После того как accessToken сохранен в переменную окружения, его нужно правильно использовать. В банковских API ВТБ чаще всего используется стандарт Bearer Authentication.

В Postman не нужно прописывать заголовок Authorization вручную в каждом запросе. Правильнее настроить это на уровне всей коллекции:

Нажмите правой кнопкой на папку коллекции.

Выберите Edit -> Authorization.

Выберите тип Bearer Token.

В поле Token впишите {{accessToken}}.

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

Нюансы безопасности и типичные ошибки

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

Истечение срока действия (Token Expiry)

Если вы получили ошибку 401 Unauthorized, значит, ваш access_token «протух». В реальном приложении в этот момент срабатывает механизм Refresh. В Postman для этого стоит создать отдельный запрос POST /auth/refresh, который берет refreshToken и получает новую пару ключей.

Привязка к IP и Fingerprint

Банковские системы безопасности крайне подозрительны. Если вы авторизовались с одного IP-адреса, а затем ваш VPN переключился на другую страну, сервер может аннулировать сессию. Аналогично, если в запросе на получение баланса вы укажете deviceId, отличный от того, что был при входе, вы получите ошибку безопасности.

Обработка ошибок в скриптах

Частая ошибка новичков — скрипт в Tests падает, если сервер вернул не JSON, а ошибку (например, 502 Bad Gateway). Чтобы ваша коллекция не «ломалась» при сбоях сервера, всегда добавляйте проверку статуса:

Отладка через Postman Console

Когда цепочка авторизации не срабатывает, «Quick Look» (глазок в верхнем правом углу) не всегда дает полную картину. Используйте Postman Console (Ctrl+Alt+C). Там вы увидите:

Какие именно заголовки ушли на сервер (был ли там Bearer?).

Что именно ответил сервер в сыром виде (Raw Response).

Ошибки выполнения ваших JavaScript-скриптов.

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

Математическая модель оценки безопасности (Entropy)

Банки предъявляют строгие требования к сложности паролей и токенов. С точки зрения теории информации, безопасность токена определяется его энтропией. Если — длина алфавита символов, а — длина токена, то количество возможных комбинаций вычисляется как:

Для банковских токенов используется алфавит Base64 (), а длина токена часто превышает . Это делает подбор токена невозможным за разумное время. Однако для тестировщика важно понимать, что даже самый сложный токен бесполезен, если он передается через незащищенное соединение или логируется в открытом виде в системе мониторинга.

Завершение настройки первого входа

Реализация первого входа — это создание «живого» механизма. Теперь, когда у вас есть три запроса, связанных через переменные окружения, вы можете запустить их по очереди. Первый запрос создаст сессию, второй передаст пароль, третий подтвердит вход и сохранит токен. Все последующие тесты — проверка баланса, выписка по карте, перевод между счетами — будут просто использовать переменную {{accessToken}}.

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