Переоценить важность тестирования сложно, особенно когда речь заходит об интеграционной платформе для взаимодействия систем кредитного конвейера. В этом материале мы хотим рассказать о том, как наша команда сначала спроектировала такую шину, а потом запустила для нее автотесты.
Что такое интеграционная платформа и для чего она нужна?
В крупных корпоративных системах часто возникают проблемы взаимодействия между внутренними подсистемами. Из-за бесконечных связей и запросов такой клубок с течением времени всё больше запутывается и усложняется. Его становится тяжело
У каждой подсистемы свой релизный цикл: какая-то обновляется раз в год, а какая-то – раз в неделю. Эти изменения также надо учитывать и интегрировать в общую системную канву. Для этого необходим посредник, который осуществляет обмен данными между всеми подсистемами компании. Этот посредник и есть интеграционная платформа.
В поисках исполнителя для ее разработки заказчик подготовил тестовое задание, которое необходимо было реализовать и защитить. Это было достаточно простое описание задачи с несколькими выбранными системами: база данных, сервис, файловые каталоги и т.д. В течение недели нужно было создать и продемонстрировать отказоустойчивое решение, а также описать платформу разработки. В реализации таких проектов у нас накопился приличный опыт, и по результатам защиты нас выбрали исполнителем.
В то время у заказчика в большинстве случаев использовалась схема интеграции «точка-точка»: каждая система интегрировалась с другой. Это было неудобно и сложно поддерживать. Перед нами поставили три задачи:
- заменить существующую интеграцию через интеграционную платформу;
- интегрировать новые системы банка;
- автоматизировать процессы обмена данными между ними.
После успешного прохождения тестового задания мы приступили к проекту. Его этапность для себя определили таким образом:
- провести аудит;
- найти сотрудников заказчика, которые понимают целевое состояние бизнес-процессов (а не только текущее);
- сформировать требования бизнеса к ИТ-системам и предоставить дорожную карту перехода в целевое состояние бизнес-процессов.
Реализация
Для реализации выбрали модульную интеграционную платформу Red Hat JBoss Fuse.
Архитектура JBoss Fuse
Немного подробнее про основные инструменты, которые есть «из коробки»:
Apache Camel, построенный на корпоративных шаблонах интеграции (EIP), обеспечивает маршрутизации сообщений, имеет большое количество готовых адаптеров для работы с внешними системами: базами данных, файлами, брокерами сообщений, службой каталогов, почтой и пр.
Apache ActiveMQ, который организует обмен сообщениями, а также обеспечивает их передачу и хранение до тех пор, пока подписчик не заберет их.
Сам интеграционный процесс (flow) представляет собой набор последовательных действий. Например: принять сообщение от системы-источника через разработанный/существующий адаптер, преобразовать данные сообщения, дополнить, отфильтровать, передать далее системам-приемникам через их адаптеры.
Интеграционный процесс
При этом попутно должна обеспечивается проверка данных, их гарантированная доставка, обработка ошибок с предоставлением возможности сбора системой мониторинга, информирование ответственных исполнителей об ошибках и пр.
Пример
Возьмем процесс выдачи кредитов в банке. Клиент в интернет-банке заполняет заявку, отправляет данные с формы и ждет результата. Что при этом происходит внутри: через rest api, предоставленный интернет-банку, шина принимает запрос с основными данными. Далее, он запрашивает через soap-интерфейс в MDM-системе дополнительную информацию о клиенте, объединяет полученное в общий набор и передает через выделенную очередь ActiveMQ системе RTDM для формирования предложения в рамках существующих кредитных продуктов. Далее результат от RTDM возвращается в ответную очередь, и шина транслирует предложение для клиента обратно в интернет-банк.
Тестирование
Когда интеграционная шина перешла к тестировщикам, изначально вопрос с тестированием продукта решался вручную. Однако в процессе было принято решение автоматизировать весь процесс и создать тестовую платформу.
Мы написали эмуляторы для всех систем банка. Доступ для тестирования на рабочих данных и системах заказчики предоставляют не всегда и не сразу, поэтому эмуляторы разрабатывались для каждого проекта отдельно. По трудоемкости эта работа сравнима с разработкой самого интеграционного решения. Перед тестовой платформой стояла задача: собрать, развернуть, прогнать тест и отправить результаты в TestRail.
Мы сделали два набора сценариев, которые прогонялись при каждой сборке (CI/CD). По коммиту у нас инициировалась сборка и разворачивалась на стенд. После процедуры деплоя прогонялся короткий сценарий (smoke test), который давал нам понять, что никакие интеграционные взаимодействия не сломаны.
У нас гонялся расширенный сценарий по ночным сборкам, который нам давал полноценный ответ на вопрос: что с шиной и как происходит ее взаимодействие с внешними системами? В утреннем отчете мы видели успешные прохождения тестов или появившиеся проблемы. Однако мы не стали автоматизировать тестирование интеграционной платформы с внешними системами, так как верифицировать результаты подобного тестирования очень сложно. Поэтому оставили ручное тестирование: сотрудники заказчика выполняли приемочные испытания своих систем, а наш специалист проверял по логам, верно ли проходит информация.
В итоге удалось достичь 100% автоматизации тестирования на эмуляторах. При обновлении одной из внешних систем задачу сохранить работоспособности бизнес-процесса брала на себя шина, соответственно, изменения вносились прямо в нее. Это позволяло быстро тестировать любые изменения.
Вместо заключения
После всех пройденных этапов наша команда построила быстрые и прозрачные процессы с контрагентами и заказчиками, и дальнейшие процессы разработки, тестирования, внедрения и поддержки пошли просто. В итоге было автоматизировано 12 бизнес-процессов, которые в своей сущности объединили работу основных систем банка: АБС, MDM, процессинга, RTDM и пр. В таких проектах мы всегда стараемся силами только автоматизированного тестирования, практически не привлекая функциональных тестировщиков. Это снижает конечную стоимость разработки и интеграции проекта, снижает time to market и нивелирует человеческий фактор.
Александр Садыков, Заместитель руководителя отдела тестирования, Центр программных решений, «Инфосистемы Джет»
Павел Иванов, Руководитель группы разработки, Центр программных решений, «Инфосистемы Джет»