Пять примечательных функций Postman, которые мы используем в тестировании банковских систем

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

Есть у 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 других команд
Просматриваем API других команд

Например, можно позаимствовать хороший скрипт из API Twitter и адаптировать его под собственные наработки. Разумеется, есть stack overflow, который забит различными кейсами и решениями к нему. В общем, возникающие проблемные ситуации можно решить с помощью коллективного сознания интернета.

Немного про возможности Postman

Мы проводим тесты API не только по архитектурному стилю REST, но и по кастомным протоколам. Например, по протоколу eKassir v3 от нашего вендора eKassir.

Краткая информация по eKassir V3
Краткая информация по eKassir V3

В качестве транспортного протокола используется HTTP, в теле запроса содержится xml-документ, который формируется по xsd-схеме. Аутентификация происходит по паролю в заголовке запроса. Протокол не имеет пакетного режима. Запрос выполняет только одну операцию, таким образом нам надо постоянно парсить xml-ответы, извлекать параметры, валидировать и подставлять в последующие запросы, и уже из них строить цепочку. Все это Postman умеет делать, и на практике получается отлично. 

Мы используем не все функции Postman, но некоторые из них могут пригодится на других проектах или в командах. Например:

  • возможность работать не только с HTTP-протоколом, но и с gRPC и WebSocket;

  • установка заглушек, если продукт не до конца разработан и часть сервера не доступна;

  • мониторинг системы с запуском сценариев по расписанию.

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

Создание сложных структур запросов

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

Коллекция для тестирования СБП-C2B
Коллекция для тестирования СБП-C2B

Собственно, это основные причины, почему мы остановились на Postman. Теперь перейдем к практике.

Коллекция «из коробки»

Начнем с формирования коллекции из коробки. Смысл в том, чтобы пользователь с минимальным набором знаний мог взять коллекцию и пользоваться ей.

Простой пример из жизни: в пятницу вечером позвонил коллега и сказал, что срочно нужен тестовый QR-код для оплаты услуги по СБП для C2B. Я был в дороге и мог помочь только советом. Просто сказал, в какой сетевой папке лежит коллекция, как надо ее импортировать и указал номера запросов, которые надо поочередно выполнить. Все это заняло пару минут. В итоге коллега, который был не особо знаком с Postman, смог выполнить эту не самую простую операцию по взаимодействию с «Национальной Системой Платежных Карт» и зарегистрировать QR-код.

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

На просторах Сети чаще всего встречаются кейсы с использованием переменных окружения. Их можно использовать, но они таят одну проблему – при импорте и экспорте коллекции требуется оперировать двумя файлами – самой коллекцией и файлом с переменными. Мы работаем внутри DMZ-сети и не можем выполнять совместную работу в Postman в онлайн-режиме, потому делимся коллекциями через внутренний мессенджер. Случается, в процессе работы забываешь импортировать переменные или переключить окружение и потом долгое время разбираешься в причинах. Это, разумеется, тратит драгоценное время, поэтому мы перешли на использование переменных коллекций. Они назначаются внутри самой коллекции, чем и хороши.

Интерфейс Postman для назначения переменных коллекций
Интерфейс Postman для назначения переменных коллекций

Со временем мы пришли к выводу, что лучше их выносить в секцию Pre-request Script на уровне коллекции в корневой элемент.

Переменные коллекции в секции Pre-request Script
Переменные коллекции в секции Pre-request Script

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

Все это обернуто в оператор if с условием срабатывания только на первый запрос в коллекцию, чтобы у незнакомого с Postman человека могли объявиться все переменные.

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

Централизованный скрипт

Если в секцию в Pre-request Script можно смело выносить переменные, то в секцию Tests –  все необходимые скрипты, тесты, проверки, костыли. Удобнее держать это в одной области, чем распределять по разным кейсам. Иначе, если коллекция разрастается нескольких сотен запросов, хаос неизбежен. Также, если скрипты будут храниться децентрализовано, при изменении коллекции придется вносить правки в каждый отдельный запрос. С централизованным подходом мы осуществляем конфигурацию в рамках одной рабочей области.

Функции по проверке параметров
Функции по проверке параметров

Скрипт содержит функции для проверки статус-кода, назначение переменных коллекции, проверку параметров в ответе. Отдельно вынесены проверки пользовательских ошибок. Для того чтобы скрипт понимал, когда и какую проверку запускать, достаточно воспользоваться конструкцией switch/case, на скриншоте выше она начинается с 44-й строчки, в которой оператор switch будет сравнивать имя текущего выполняющегося запроса со списком всех запросов, которые мы указали в case-ах. Таким образом, когда в коллекции выполняется определенный запрос, скрипт распознает его и запускает набор нужных функций. Такой подход помогает более эффективно вносить изменения в коллекцию.

Некоторые коллекции живут и пополняются годами
Некоторые коллекции живут и пополняются годами

Пример из практики – это частые изменения в законодательстве. Если бы нам приходилось на ежемесячной основе вносить корректировки в разрозненные наборы сценариев, то с каждой итерацией временные затраты на это увеличивались, создавая эффект снежного кома. Сейчас мы экономим на этом примерно 10 человеко-часов в месяц, что неплохо!

Автотесты в Postman

Теперь про автотесты в Postman в разрезе ручного тестирования. Автотесты нужны для быстрого выявления дефектов или аномалий в новой версии объекта тестирования. Вот как выглядит процесс, когда мы получаем от разработчиков самую первую версию ПО. 

Упрощённый процесс по ручному тестированию
Упрощённый процесс по ручному тестированию

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

Упрощённый процесс по ручному тестированию на последующих итерациях
Упрощённый процесс по ручному тестированию на последующих итерациях

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

Вот так выглядят проверки.

один запрос - один pm.test
один запрос - один pm.test

Их можно формировать по принципу один тест – одна проверка (один pm.test – один pm.expect). Но мы пришли к мнению, что удобнее все проверки упаковывать в один test, чтобы по результатам отправки запроса появилась информация – провалился тест или нет. Реализация проверки по отдельным «тестам» не освобождает от необходимости анализировать конечный запрос в поисках причин для локализации дефекта и более того, требует необоснованно больше времени. Данный подход помогает проводить раннее тестирование новых версий ПО, что значительно улучшает взаимодействие с командой разработки.

Пользовательские сценарии в Postman

Это структурированные цепочки запросов для воспроизведения проверяемой бизнес-логики. Раньше, когда требовалось создать какую-либо банковскую операцию, мы шли на «фронт» – в кассу, банкомат, банк и повторяли сценарий, который выполняет пользователь. Операция занимает всего 2-3 минуты, однако каждый сотрудник каждый день должен выполнять по сотне таких операций. В сумме это несколько часов безудержного веселья и ковыряния во всевозможных параметрах. И это надо было как-то исправлять.

Мы пришли к мнению, что надо составить в Postman несколько цепочек запросов, которые будут полностью эмулировать работу «фронта». Для примера возьмем регистрацию QR-кода для оплаты в рамках СБП по направлению C2B и создание операции по нему. Цепочка состоит из четырех запросов, где первый – получение токена с авторизационного сервера. Обычный POST-запрос по архитектурному стилю REST.

Оплата по QR-коду в виде сценария
Оплата по QR-коду в виде сценария

В ответ на запрос получаем параметр с 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, так и людям, которые только присматриваются к нему.

Источник: https://habr.com/ru/company/rshb/blog/715304/


Интересные статьи

Интересные статьи

Уже больше двух лет мы разрабатываем Bastion Security Platform. В прошлой статье мы рассказали, как научились создавать дешевые сетевые ловушки в больших количествах. Но ловушки — всего лишь базовый к...
Портативность электронного оборудования — ценнейшее качество, как для компаний, так и обычных пользователей. Чем меньше места занимает оборудование, тем эффективнее использование полезного пространс...
Привет, Хабр! Обращаем ваше внимание еще на одну новинку, доступную у нас в предзаказе — книгу о юнит-тестировании. Автор сегодняшней публикации кратко и доступно рассказывает о...
В конце ноября у нас стартует новый поток курса Разработчик игр на Unity и C#, и специально к нему мы делимся подборкой игр на тему Хеллоуина. Все они создавались на соревнованиях вроде L...
(с) Среди ученых ходит байка о нетривиальном способе сделать свой доклад интересным и увлекательным. Во время выступления нужно выбрать в зале самого недоумевающего, самого потер...