Меня зовут Максим Кирилов и я - главный инженер в блоке обеспечения и контроля качества выпуска изменений в «РСХБ-Интех» (IT-компании АО «Россельхозбанка»). Наше подразделение специализируется на ЕСПП (Единой Системе Приёма Платежей), а непосредственно моя команда занимается тестированием. В этой статье я расскажу о том, как автоматизация помогла нам оптимизировать рабочие процессы и какие именно инструменты мы для этого использовали.
Что такое ЕСПП
Для начала немного поясню, в чем заключается специфика нашей работы. ЕСПП - это масштабный платежный хаб который нацелен на обработку запросов от фронтальных систем для создания платежных операций с последующим формированием бухгалтерских проводок в автоматизированную банковскую систему (АБС). ЕСПП хранит в себе динамическую базу данных услуг, которые распределяются по точкам обслуживания, предоставляя клиентам широкий спектр возможностей, например, оплачивать мобильную связь, ЖКХ или перечислять средства в другие банки (в том числе и через СБП).
По сути мы – посредник между фронтальными системами, поставщиками услуг и АБС. Таким образом, нам приходится иметь дело с самыми разнообразными схемами инфообмена, а при тестировании функциональности создания платежных операций мы работаем со всеми возможными точками обслуживания клиентов: интернет-банк, касса, банкомат, мобильные приложения (Россельхозбанк, РСХБ QR, СБПэй) и набирающее обороты решение «Единый Фронт РСХБ», которое разработано для организации комплексного банковского обслуживания физических лиц в наших офисах. Одновременно для проверки механизма формирования бухгалтерских проводок мы координируемся уже с АБС.
Много реципиентов – значит много способов взаимодействия с ними. Так, нам необходимо проверять инфообмен по HTTP/JSON, HTTP/XML и MQ/XML. И вот тут нам и требуется оптимизация: количество информационных потоков со временем лишь растет, а для проверки отдельных функций по-прежнему приходится вручную проводить операции. В итоге было решено реализовать возможность быстрой проверки ключевых модулей на тестовом контуре, выработать механизмы по автоматическому созданию операций и оптимизировать
работу с логами сервисов.
Postman: швейцарский нож от мира API-платформ
Так как большинство сервисов взаимодействовали по HTTP, было принято решение взять на вооружение Postman. В первую очередь в нем нас привлекла возможность создавать коллекции необходимых запросов и хранить их в отдельных коллекциях, формируя по сути базу знаний с моментальным доступом.
Со временем, освоившись с новым инструментом, поверх имеющихся запросов мы добавили необходимые нам проверки в секцию для тестов. Так как запросов было много, то тесты описывались в корневом элементе коллекции: так мы немного теряли в скорости выполнения запросов и проверок, однако существенно сокращали время на внесение изменений в тесты при получении нового релиза или добавлении новых тем запросов. Буквально спустя считанные месяцы с момента пользования Postman'ом, мы получили возможность не только проводить Smoke по всем имеющимся в нашем распоряжении сервисам, но и получать актуальную информацию по состоянию тестового контура в целом.
Приятной неожиданностью для нас стало удобство, которое обеспечивается при тестировании взаимодействий по протоколу eKassir V3 через Postman: с помощью простых скриптов в секции для тестов мы могли извлекать из ответов на запросы необходимую нам информацию и подставлять её в следующие запросы. Это позволило выстраивать сложные цепочки, которые значительно расширили нашу тестовую модель в рамках автоматического тестирования.
Вот как мы работали, к примеру, при реализации услуги по приёму переводов денежных средств C2B. Для этой операции покупателю через СБП требовалось авторизоваться в приложении банка с телефона, выбрать способ оплаты через QR-код, затем отсканировать QR-код и подтвердить оплату. При тестировании мы сначала проверили корректность получения информации по QR-коду, а затем занялись самим механизмом оплаты.
В мире до Postman’а мы бы для начала создали QR-код через фронт (а значит прошли как минимум 3 ступени – от поиска нужного юридического лица на специализированном портале до определения конкретного предприятия, где будет осуществляться покупка и генерации QR-кода). Всё это занимает от двух до трёх минут – не так уж много, но не в том случае, когда требуется ежедневно регистрировать по 100 QR-кодов. При регистрации QR-кода через API, нам требовалось только выполнить два POST-запроса через Postman, получить токен и выполнить запрос на регистрацию QR. Если учесть, что Postman у нас был открыт всегда, то выполнение запроса и формирование QR-кода занимало 2-3 секунды. Уже существенная экономия.
После успешной проверки создания операции по QR-кодам, нам нужно было протестировать бухгалтерский учет, а именно – проверить, что все проводки по операциям формировались корректно и отправлялись в АБС. Раньше мы бы прошли все этапы как пользователь: зашли в мобильное приложение, выбрали оплату по QR-коду, заполнили форму и подтвердили платеж. В Postman’е мы этот процесс автоматизировали по протоколу eKassir V3. В итоге весь процесс укладывался в пару секунд.
Это оказалось настолько эффективно, что со временем на рельсы автоматизации мы поставили бОльшую часть функциональности, которая нам требовалась в повседневной работе.
Selenium IDE для проверки фронта
Фронтальную часть сервисов мы тестируем не так часто, однако, когда речь идет о функционале для C2B, время от времени проверка работы интерфейса требуется.
И если в части API покрытие тестами у нас было полное (в рамках разумного), то со стороны фронта всё ещё приходилось вручную проверять валидацию полей и другие моменты. А значит автоматизация не помешала бы. Решение для этой части мы нашли в процессе перекрёстного обучения между отделами, в рамках которых мы традиционно обмениваемся опытом с коллегами. Именно на такой встрече мы и открыли для себя простое, но эффективное расширение Selenium IDE. Инструмент не идеальный, но для наших задач подходящий.
Здесь мы просто составили список необходимых для проверок элементов, расписали по ним сценарии и 'прощёлкали' их через расширение. В результате получили необходимые автотесты, которые перекрывали UI часть наших сервисов.
Укрощая логи: WindowsForms для VisualStudio
Логи – это дар и проклятье тестировщика. Добрую половину рабочего времени мы тратим на их чтение, чтобы убедиться, что система отработала именно так, как ожидается. И среди всех бестселлером является лог, содержащий в себе информацию по взаимодействию между точками обслуживания и платёжным сервером. Инфообмен здесь проводится по протоколу eKassir V3, который содержит в себе множество методов и команд.
Как правило, нам не требуется проверять сразу всё. В рамках тестирования определённой функциональности, мы отслеживаем только определённые запросы. Конечно, тут можно просто прибегнуть к помощи стандартного поиска в текстовых редакторах, однако нам требовалась оптимизация. И для этого в VisualStudio мы написали парсер лога на WindowsForms. Писалось всё на C#, и работа парсера была предельно проста, но очень эффективна.
И вот как это работает. Приложение подключается к папке с логами, получает информацию обо всех файлах лога за каждый час. После выбора файла за необходимый временной период, приложение парсит лог и делит его на события. Затем каждое событие обрабатывается, и на основе результатов информация о нем вносится в элемент ListView. При выборе необходимого события запрос форматируется в более приличный для XML вид и отображается в RichTextBox'е.
В результате мы получили инструмент, благодаря которому могли практически в режиме реального времени отслеживать необходимые нам запросы.
В ходе экспериментов над приложением появилась идея реализовать возможность создания платежных операций с помощью нажатия одной кнопки. И здесь мы уже работающее в Postman решение (которое я описал выше) улучшили при помощи созданного парсера, добавив возможность выбора тестового контура.
При создании платежной операции для нас самое важное – на основе какой схемы бухгалтерского учета будут формироваться бухгалтерские проводки. Поэтому названия вышли достаточно лаконичными. При нажатии на нужную нам схему вызывалась функция по отправке запросов на сервер с использованием данных, которые были предустановлены ранее. Как итог мы получили инструмент, позволяющий более оперативно создавать необходимые операции.
Крупнокалиберная автоматизация
Все описанные ранее инструменты могут быть применены в небольших командах или даже отдельным разработчиком для упрощения процессов, но мы – часть крупной структуры, где большое значение имеет строгое соблюдение стандартов отчётности. О том, какой стек актуален для таких случаев, поговорим в этом разделе.
Мы тесно сотрудничаем с командой разработчиков из отдела автоматизации тестирования, которые ведут проект по выполнению API-запросов (взаимодействие с eKassir V3) и валидации приходящих ответов, а также занимаются тестированием UI-системы АТМ-Банкомат. Развертывание, настройка и запуск этих проектов происходит достаточно оперативно благодаря использованию модульного подхода и наличию ядра тестирования. Стек технологий здесь следующий: для модулей тестирования Java 12, Spring Framework и JUnit4/TestNG, BDD подход написания автотестов - Cucumber, система генерации отчетов - Allure Framework. Для отправки запросов в большинстве случаев применяется библиотека REST Assured, но мы обращались к Apache HttpComponents. Для тестирования UI-интерфейса используется многим знакомый Selenium Web Driver. Каждый проект поставлен на рельсы CI/CD посредством Jenkins для непрерывной интеграции, развертывания и запуска.
И все это интегрировано в систему управления тестирования - Test IT, которая не только позволяет хранить тест-кейсы, составлять тест-планы и по мере необходимости оперативно их актуализировать, но и запускать тесты прямо из Test IT, что существенно экономит наши ресурсы.
Результат
В процессе реализации всех выше описанных решений, мы имеем:
Значительное сокращение затрат человеческих ресурсов на выполнение рутинных задач (вроде генерации QR-кодов).
Postman не забыт, используется в Smoke и Sanity тестировании, когда прогнать кейсы надо срочно.
Selenium IDE закрывает фронт, который не проверить по API.
Парсер развивается и читать логи с каждым днём становится всё комфортнее.
Можем отгружать красивые и еще более достоверные метрики.
Весь этот опыт позволил нам несколько иначе взглянуть на построение процессов при тестировании ПО. Теперь, получая на руки документацию по очередной бизнес-инициативе, мы не только составляем тест-план, но и продумываем способы оптимизировать, а в идеале и автоматизировать всю доступную функциональность. Более того, стремимся распространить разработанные механизмы на будущие задачи.
Надеюсь, что наш опыт вам тоже будет полезен.