Есть у Postman несколько полезных функций, которые помогают нам экономить десятки, а в некоторых случаях и сотни человеко‑часов в месяц. Тут нет каких‑то больших секретов или магии, но рассказ про них может для кого‑то послужить началом долгого и продуктивного использования. В этом посте я пробегусь по пяти функциям и приемам для Postman, которые мы используем для тестирования систем, связанных с банковскими операциями в сегменте C2B — теми самыми, которые весь мир ежедневно проводит через всевозможные кассовые аппараты, банкоматы, терминалы и QR‑коды.
Я Максим Кирилов — QA‑инженер в «РСХБ‑Интех». Одна «л» в фамилии — не опечатка, а неотловленный пару столетий назад баг какого‑то канцелярского работника. Впрочем, рассказывать буду не про себя, а про то, как мы используем Postman в рамках ручного интеграционно‑функционального тестирования. Возможно, кто‑то найдет в нашем опыте несколько полезных для себя моментов или просто будет знать, как работают те парни, которые отвечают за тесты платежных операций в техдочке большого банка.
О чем пойдет речь в посте
1. почему мы взяли именно Postman, и как он помог нам оптимизировать рабочие процессы;
2. о принципе построения коллекции методом «из коробки», который предполагает, что пользователь с минимальным набором знаний о Postman сможет полноценно использовать данные из коллекции;
3. про централизованный подход к написанию скриптов, при котором скрипты пишутся не в разнобой по разным запросам, а держатся в одном рабочем пространстве в корневом элементе секции на уровне коллекции;
4. про автотесты в Postman, как мы используем их при ручном тестировании, как они туда поместились и как помогают взаимодействовать с командой разработчиков;
5. про внедрение пользовательских сценариев в рабочие процессы. Речь про структурированные цепочки запросов, которые выполняют ту или иную бизнес‑логику — проведение платежа, подписка на сервисы и т. д.
Но сначала пару слов о «Единой Системе Приема Платежей» (ЕСПП), и почему работая с ней мы проводим тесты именно через Postman.
Как устроена наша «Единая Система Приема Платежей»
ЕСПП — это один большой платежный хаб, в задачи которого входит обработка запросов с фронтальных систем банка, точек обслуживания, кассового ПО, банкоматов, терминалов, мобильных приложений, интернет‑банков — с любых устройств, с которых клиент может совершить оплату. Чуть подробнее про нее я писал в предыдущей статье, а тут расскажу лишь про тестируемые процессы.
На основе этих запросов создаются платежные операции, объекты которых содержат структурированную информацию о платеже. Сотрудник банка в любой момент через специальное ПО может зайти и проверить операции, которые кажутся ему подозрительными, или провести корректировки при необходимости. По платежным операциям формируются бухгалтерские проводки: тип проводки, дата, время, счет дебета, счет кредита. Затем проводки отправляются в автоматизированную банковскую систему, где происходит «магия», которая моего отдела уже не касается. Мы будем говорить лишь про тестирование API, относящееся к первому этапу — обработке запросов с фронтальных систем.
Со всех точек обслуживания к нам прилетают запросы. Большинство — по протоколу HTTP. Раньше мы проводили тестирование тем инструментом, который был удобен каждому отдельному сотруднику. Кто‑то тестировал через Postman, кто‑то через SoapUI, кто‑то плагинами в Chrome, кто‑то через решения от вендора. Разумеется, у нас возникли проблемы с таким подходом — и это та самая причина, почему нам потребовался единый инструмент для тестирования API.
Во‑первых — для эффективного обмена наработками между коллегами. Приведу простой пример. У нас шесть разных систем, которые работают по одной схеме инфообмена. Тестируют их разные сотрудники через разные инструменты. Если один сотрудник уходит в отпуск, то задача переходит его коллеге. Если коллега работает на другом инструменте, то перенос наработок приносит сложности. Единый инструмент решает эту проблему — коллекции просто перекидываются другому сотруднику, который продолжает над ними работать.
Во‑вторых, единый инструмент понадобился для улучшения процесса обучения новых сотрудников. Когда приходит новый человек — ему надо изучить, как работают наши сервисы. Раньше приходилось штудировать широкий стек инструментов. Теперь мы даем ему в руки Postman, все необходимые коллекции, и в короткий срок он встраивается во все рабочие процессы.
Почему именно Postman?
Тут низкий порог входа, понятный интерфейс, и он достаточно давно на рынке — более 10 лет. Интернет набит гайдами, статьями и видеороликами о том, как работать в Postman. Кроме того, на большинстве курсов по подготовке тестировщиков при тестировании API учат работать именно с Postman, а по тому же SoapUI дают лишь общую теорию.
Еще одна причина — встроенная возможность просмотра коллекций, которые пользователи выкладывают в открытый доступ.
Например, можно позаимствовать хороший скрипт из API Twitter и адаптировать его под собственные наработки. Разумеется, есть stack overflow, который забит различными кейсами и решениями к нему. В общем, возникающие проблемные ситуации можно решить с помощью коллективного сознания интернета.
Немного про возможности Postman
Мы проводим тесты API не только по архитектурному стилю REST, но и по кастомным протоколам. Например, по протоколу eKassir v3 от нашего вендора eKassir.
В качестве транспортного протокола используется HTTP, в теле запроса содержится xml-документ, который формируется по xsd-схеме. Аутентификация происходит по паролю в заголовке запроса. Протокол не имеет пакетного режима. Запрос выполняет только одну операцию, таким образом нам надо постоянно парсить xml-ответы, извлекать параметры, валидировать и подставлять в последующие запросы, и уже из них строить цепочку. Все это Postman умеет делать, и на практике получается отлично.
Мы используем не все функции Postman, но некоторые из них могут пригодится на других проектах или в командах. Например:
возможность работать не только с HTTP-протоколом, но и с gRPC и WebSocket;
установка заглушек, если продукт не до конца разработан и часть сервера не доступна;
мониторинг системы с запуском сценариев по расписанию.
Из прочего – в последней версии была добавлена возможность визуализации цепочки запросов, которую мы возьмем на вооружение в ближайшее время.
Создание сложных структур запросов
Мы часто сталкиваемся с массивными API, для работы с которыми требуется создавать многоуровневую иерархическую структуру, распределяя запросы по областям тестирования в соответствии с проверяемой бизнес-логикой. Postman великолепно справляется с задачей, предоставляя на выходе элегантное и функциональное решение. Более гибкой системы распределения запросов мне увидеть пока не довелось, хотя поиск продолжаю.
Собственно, это основные причины, почему мы остановились на Postman. Теперь перейдем к практике.
Коллекция «из коробки»
Начнем с формирования коллекции из коробки. Смысл в том, чтобы пользователь с минимальным набором знаний мог взять коллекцию и пользоваться ей.
Простой пример из жизни: в пятницу вечером позвонил коллега и сказал, что срочно нужен тестовый QR-код для оплаты услуги по СБП для C2B. Я был в дороге и мог помочь только советом. Просто сказал, в какой сетевой папке лежит коллекция, как надо ее импортировать и указал номера запросов, которые надо поочередно выполнить. Все это заняло пару минут. В итоге коллега, который был не особо знаком с Postman, смог выполнить эту не самую простую операцию по взаимодействию с «Национальной Системой Платежных Карт» и зарегистрировать QR-код.
Ключевым функционалом для создания такой коллекции является пространство переменных. В Postman имеется несколько таких пространств, которые работают на разных уровнях: глобальные переменные, переменные окружения, переменные коллекции, локальные переменные и переменные уровня данных. Остановимся на двух из них.
На просторах Сети чаще всего встречаются кейсы с использованием переменных окружения. Их можно использовать, но они таят одну проблему – при импорте и экспорте коллекции требуется оперировать двумя файлами – самой коллекцией и файлом с переменными. Мы работаем внутри DMZ-сети и не можем выполнять совместную работу в Postman в онлайн-режиме, потому делимся коллекциями через внутренний мессенджер. Случается, в процессе работы забываешь импортировать переменные или переключить окружение и потом долгое время разбираешься в причинах. Это, разумеется, тратит драгоценное время, поэтому мы перешли на использование переменных коллекций. Они назначаются внутри самой коллекции, чем и хороши.
Со временем мы пришли к выводу, что лучше их выносить в секцию Pre-request Script на уровне коллекции в корневой элемент.
Таким образом можно четко структурировать переменные путем добавления комментариев. Мы разделяем их на несколько блоков: есть переменные для URL, для авторизации и всевозможные тестовые данные, разбитые на логические подгруппы.
Все это обернуто в оператор if с условием срабатывания только на первый запрос в коллекцию, чтобы у незнакомого с Postman человека могли объявиться все переменные.
В итоге: при пересылке коллекции мы передаем только один файл, что очень удобно, и можем создавать более гибкие структуры. Кроме того, такие коллекции готовы к работе сразу после их импорта в Postman и не требуют дополнительной конфигурации.
Централизованный скрипт
Если в секцию в Pre-request Script можно смело выносить переменные, то в секцию Tests – все необходимые скрипты, тесты, проверки, костыли. Удобнее держать это в одной области, чем распределять по разным кейсам. Иначе, если коллекция разрастается нескольких сотен запросов, хаос неизбежен. Также, если скрипты будут храниться децентрализовано, при изменении коллекции придется вносить правки в каждый отдельный запрос. С централизованным подходом мы осуществляем конфигурацию в рамках одной рабочей области.
Скрипт содержит функции для проверки статус-кода, назначение переменных коллекции, проверку параметров в ответе. Отдельно вынесены проверки пользовательских ошибок. Для того чтобы скрипт понимал, когда и какую проверку запускать, достаточно воспользоваться конструкцией switch/case, на скриншоте выше она начинается с 44-й строчки, в которой оператор switch будет сравнивать имя текущего выполняющегося запроса со списком всех запросов, которые мы указали в case-ах. Таким образом, когда в коллекции выполняется определенный запрос, скрипт распознает его и запускает набор нужных функций. Такой подход помогает более эффективно вносить изменения в коллекцию.
Пример из практики – это частые изменения в законодательстве. Если бы нам приходилось на ежемесячной основе вносить корректировки в разрозненные наборы сценариев, то с каждой итерацией временные затраты на это увеличивались, создавая эффект снежного кома. Сейчас мы экономим на этом примерно 10 человеко-часов в месяц, что неплохо!
Автотесты в Postman
Теперь про автотесты в Postman в разрезе ручного тестирования. Автотесты нужны для быстрого выявления дефектов или аномалий в новой версии объекта тестирования. Вот как выглядит процесс, когда мы получаем от разработчиков самую первую версию ПО.
Мы проводим ручное тестирование, регистрацию дефектов и формируем коллекцию в Postman с прописыванием всех необходимых тестов. Во второй и последующих итерациях процесс немного меняется.
Получаем новую версию ПО, за пару минут прогоняем нашу коллекцию в раннере Postman и получаем результаты, где видны самые явные дефекты. Например, ошибки синтаксиса. Сами разработчики от этого в восторге, когда они отдают нам новую версию, и мы уже через семь минут регистрируем два-три дефекта. После идет полноценное ручное тестирование. Итерация повторяется до тех пор, пока продукт не будет готов к релизу.
Вот так выглядят проверки.
Их можно формировать по принципу один тест – одна проверка (один pm.test – один pm.expect). Но мы пришли к мнению, что удобнее все проверки упаковывать в один test, чтобы по результатам отправки запроса появилась информация – провалился тест или нет. Реализация проверки по отдельным «тестам» не освобождает от необходимости анализировать конечный запрос в поисках причин для локализации дефекта и более того, требует необоснованно больше времени. Данный подход помогает проводить раннее тестирование новых версий ПО, что значительно улучшает взаимодействие с командой разработки.
Пользовательские сценарии в Postman
Это структурированные цепочки запросов для воспроизведения проверяемой бизнес-логики. Раньше, когда требовалось создать какую-либо банковскую операцию, мы шли на «фронт» – в кассу, банкомат, банк и повторяли сценарий, который выполняет пользователь. Операция занимает всего 2-3 минуты, однако каждый сотрудник каждый день должен выполнять по сотне таких операций. В сумме это несколько часов безудержного веселья и ковыряния во всевозможных параметрах. И это надо было как-то исправлять.
Мы пришли к мнению, что надо составить в Postman несколько цепочек запросов, которые будут полностью эмулировать работу «фронта». Для примера возьмем регистрацию QR-кода для оплаты в рамках СБП по направлению C2B и создание операции по нему. Цепочка состоит из четырех запросов, где первый – получение токена с авторизационного сервера. Обычный POST-запрос по архитектурному стилю REST.
В ответ на запрос получаем параметр с access-токеном. Этот токен записываем в переменную коллекции. Далее направляем следующий запрос – регистрации QR-кода. В секцию authorization добавляем полученный токен, а в теле у нас заранее прописаны все необходимые параметры для регистрации. Далее в рамках этой же цепочки резко перескакиваем с REST на EKS-протокол. В тело запроса помещаем идентификатор QR-кода и отправляем его. В ответе из xml парсим клиентскую сессию, сохраняем ее в переменной коллекции и передаем в следующий запрос – создания платежной операции. Отправляем его, и операция готова.
Вся эта цепочка отрабатывает в Postman за 2-3 секунды. Т.е. мы теперь создаем операции практически мгновенно, что в сравнении с предыдущим подходом экономит нам существенное количество времени – сотни и сотни человеко-часов. Если раньше мы создавали операции по мере необходимости, то сейчас иногда даем жару по принципу: «давай 50 операций, они бесплатные».
Что в итоге
Все эти подходы помогли нам упростить обмен наработками с коллегами, ускорить процесс внесения изменений в тестовую модель, улучшить взаимодействие с командой разработки, сэкономить время при выполнении рутинных операций. Т.е. один простой выбор, сделанный нами когда-то, помог значительно улучшить рабочие процессы.
Разумеется, Postman не идеален и не суперуниверсален. Да, через него можно провести нагрузочное тестирование. Но через Jmeter оно выполняется намного эффективнее.
Postman через Newman и Jenkins можно встроить в CI. Но на связке RestAssured+Spring+Jenkins, как и на многих других, это будет работать эффективнее.
В Postmane можно тестировать как REST, так и SOAP. Но в SoapUI для этих задач реализовано больше функционала.
Можно ли использовать Postman в тестировании банковского и всего прочего ПО? Однозначно можно. Если вам нужно работать с протоколом HTTP, периодически давать нагрузку на систему, четко структурировать масштабный набор запросов, изредка запускать сценарии на проверку стабильности системы, то Postman окажется неплохим вариантом. Особенно если в вашей команде будут стажеры или джуны, которым проще разобраться с Postman, чем с его аналогами.
Впрочем, главную роль играет не инструмент тестирования, а подходы, которые были применены при его использовании. Надеюсь, что подходы, о которых я рассказал, помогут оптимизировать рабочие процессы как пользователям Postman, так и людям, которые только присматриваются к нему.
