Введение
Не всегда, приходя на крупный новый или старый проект, новый тестировщик знает с какой стороны подойти к началу процесса тестирования. Иногда нет куратора, иногда не настроен процесс коммуникации. И вы можете хоть сто раз плюнуть в компанию и пойти искать новую, благо рынок сейчас в дефиците. Но гораздо интереснее будет получить бесценный опыт становления вас как самостоятельного и понимающего члена команды. Данная статья будет посвящена теории тестирования реализаций системы антифрод в одном из крупнейших банков РФ. О чем мы поговорим в этой статье? Об особенностях архитектуры enterprise. Про основной инструментарий и про советы тем, кто захочет прийти в сферу интеграционного тестирования бэкэнда в крупную компанию.
Примеры будут браться из работ по интеграции антифрод-системы.
Инструментарий для тестирования
На собеседованиях на данную позицию кроме основных обязательных знаний по теории тестирования и работы с базовым инструментарием тестировщика также требуется набор знаний, нужных для понимания работы протоколов по которому это взаимодействие происходит. А также набор инструментов. Что в этот набор входит:
SOAP (состав xml сообщений);
REST (часть взаимодействий идет через OpenAPI), JSON;
SoapUI и Postman (по желанию, какой инструмент удобен, тем и пользовались). Из практики, если очередь работает с XML - используем SoapUI. Если основа REST - Postman. Было замечено, что SoapUI не всегда корректно отрабатывает ошибки RestAPI.
принципы ssl шифрования. Шины любят общаться безопасно, поэтому требуются знания по генерации ключей;
putty + bash + linux. На некоторых сложных интеграциях нельзя слать сообщения напрямую из системы-источника (речь о way4 и транзакциях процессинга). Поэтому, дружба с linux приветствовалась на уровне “знаю как подключаться по ssh и запустить модуль с параметрами”. Для генерации ssl, кстати, тоже надо будет это знать;
SQL на уровне простых запросов до join. Теория реляционных БД желательно. Умение работать с любой РСУБД - MS SQL Developer, PL\SQL Developer. Второй даже поддерживает Test Runner для простых проверок;
Понимание клиент-серверной архитектуры и OSI на базовом уровне.
Не обязательна практика работы, но всегда хочется, чтобы кандидат был вовлечен. Любой Pet-проект подойдет чтобы рассказать о практике работы со всем вышеназванным. Связка virtualBox + http сервер + проект Postman. Или озвучивание сервисов с открытым API.
Архитектура
Встречается различный подход к документации на проектах. Кто-то требует документировать свою работу, кто-то работает по гибким методологиям и не ставит составление документации в приоритет. В общем, документация может быть, а может и не быть. И если вы не уточнили про наличие оной на собеседовании, то не удивляйтесь. Найдите сотрудника (PM, Тимлид, Техлид), который может обрисовать технологический стек и постарайтесь накидать для себя схему архитектуры сами. Потом, показывая картинку, легче понимать передвижение потоков данных и разговаривать с остальными членами команды на одном языке.
Пример состава тестового контура:
Шина данных. Очень часто в корпоративном секторе используется какой-то сервис очередей - tibco, kafka, RabbitMQ.
Ядро антифрод системы (+ web интерфейс к ней для настройки политик).
БД с данными транзакций, клиентов и другими, для корректных расчетов системы антифрод и применения политик скоринга.
Остальные смежные системы, требуемые для тестирования
Смежные системы общаются с шиной посредством коннекторов. Для каждого коннектора на шине пишется отдельный сервис, который конвертирует данные из формата, понятного системе-источнику, в формат понятный шине. Чаще всего это xml.
После этого документ помещается в очередь, из которой шина отправляет данные в систему-приемник. В нашем частном случае это была антифрод-система.
Для приема и корректной обработки данных из каждой системы-источника на стороне сервера антифрод пишется отдельный микросервис. Микросервисы выполняют атомарные функции доставки данных в ядро и передачу скоринговых баллов из ядра с вердиктом антифрода обратно в шину. Также могу валидировать входящие и исходящие данные в соответствии с ТЗ. При этом результаты опционально, по согласованию с заказчиком, логируются в базу данных для последующего анализа.
Процессы тестирования
Процессы тестирования делятся на два вида - отдельно тестирование нового микросервиса и end-2-end тестирование. Каждый из этих видов включает несколько этапов со стороны команды тестирования.
Тестирование нового микросервиса включает в себя следующие этапы:
Анализ технического задания на микросервис (разрабатывается заказчиком совместно с аналитиком);
Декомпозиция требований и составление матрицы соответствия требований;
Написание тест-плана для согласования с заказчиком. Можно найти шаблон в интернет-пространстве, если такового не имеется в наличие;
Написание тест-кейсов согласно матрице. Используется любая система управления тестированием. В корпоративном секторе сейчас распространена TFS(Azure DevOps Server)
Собственно, прохождение тест-кейсов и заведение дефектов;
Отчетность по результатам тестирования - протоколы, артефакты и т.п. (опционально по согласованию с заказчиком)
В корпоративном секторе роль заказчика часто принадлежит внутреннему бизнес-подразделению и лицом принимающим решение со стороны бизнеса является его руководитель. Он же ставит бизнес-задачу на разработку интеграционного взаимодействия. Например, руководитель департамента МСБ (малый-средний бизнес). Тестовые данные в данном случае могут предоставлять сотрудники подразделения-заказчика.
Бизнес-задачи для системы антифрод может звучать так:
“Требуется, чтобы все платежи от юридических лиц проверялись в системе и отправлялись на ручную проверку\блокировались при значении скорингового балла более 60”.
“Требуется блокировать все запросы от ИП с просрочкой более 1 месяца”
End-2-end тестирование отличается тем, что к обычному процессу добавляется этап согласования тест-плана не только с заказчиком, но и с командой тестирования сервиса-источника. А также в процессе прохождения тест-кейсов все тестовые данные(запросы) генерируются ролями в системах-источниках. У каждой информационной банковской системы есть своя команда(внутренняя или внешний интегратор), разрабатывающая новые функции, и также имеет своих разработчиков и тестировщиков. E2E проводится совместно с ними.
Например: Тестировщик Диасофт от роли “Оператор” отправляет платеж по карте мир от одного юрлица к другому.
Команда взаимодействия
Тестировщики системы взаимодействуют в работе со следующими ключевыми сотрудниками:
Проектный менеджер
Менеджер технологической инфраструктуры (возможно DevOps)
Аналитик со стороны разработки
Аналитик со стороны заказчика (опционально)
Разработчик со стороны сервиса-источника
Разработчик со стороны антифрод
Разработчик со стороны шины
Автотестировщик, Архитектор, Поддержка, Скрам-мастер и прочие невиданные звери - опционально, но скорее нет.
Набор ролей соответствует стандартному набору ролей в жизненном цикле ПО по любой методологии.
Базовый сценарий тестирования
После того, как заказчик прислал требования и набор политик для антифрод, аналитики или служба поддержки настраивают их на тестовом контуре в веб-интерфейсе.
В обязанности команды тестирования входит подготовка тестовых данных согласно требованиям и политикам, и создание проекта SoapUI для пересылки этих данных в соответствующий микросервис. После написания каждого нового микросервиса заново выгружается wsdl файл, который потом грузится в SoapUI.
Под тестовыми данными я подразумеваю xml-файлы, набор полей в которых соответствовал требованиям, при которых политики срабатывали корректно или отдавали соответствующий код ответа, согласно документации.
Пример: При осуществлении платежа от ИП Васечкин к ИП Петечкину платеж должен быть не более 1 млн.руб. Если больше, то антифрод возвращает ответ DECLINE и транзакция блокируется.
Код ответа может меняться, так же, как и состав политик.
Более сложный пример: При пересылке от ИП Васечкин 1 млн.руб требуется запросить наличие просроченных кредитов у данного ИП через смежную систему. При наличие просрочки, увеличить скоринговый бал у Васечкина на 50ед за каждую просрочку. При превышении скорингового балла 100ед, отправить платеж на проверку менеджеру в ручном режиме. При этом антифрод должен прислать в теле ответа код ALLOW WAIT и скоринговый бал.
Позитивные сценарии.
Для всех позитивных сценариев составляются xml с нужными данными по клиенту(id, наименование, инн) и нужной суммой в теле запроса. Запрос отправляется в микросервис и в SoapUI создаются ассерты для проверки корректности ответа.
Типовой состав
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns="http://www.endeca.com/endeca-server/control/1/0">
<soapenv:Header/>
<soapenv:Body>
<ns:createDataStore>
<ns:dataStoreConfig>
<ns:name>books</ns:name>
<ns:dataFiles>c:\endeca\apps\books</ns:dataFiles>
<ns:wsPort>8000</ns:wsPort>
<ns:bulkLoadPort>8001</ns:bulkLoadPort>
<ns:startupTimeoutSeconds>90</ns:startupTimeoutSeconds>
<ns:shutdownTimeoutSeconds>120</ns:shutdownTimeoutSeconds>
<ns:arg>--threads</ns:arg>
<ns:arg>6</ns:arg>
</ns:dataStoreConfig>
</ns:createDataStore>
</soapenv:Body>
</soapenv:Envelope>Привел его для примера. Тестировщику желательно знать ключевые элементы схемы XML
Негативные сценарии.
Для всех негативных сценариев в ключевых полях изменяются наборы данных. Применяются различные техники тест-дизайна, чтобы проверить корректность ответа системы антифрод. Если есть требования к типам и длинне данных, надо проверять и реакцию фронта и реакцию баз данных на выход за границы значений. Желательно обрабатывать ошибки на сервере приложений, не пуская ошибочные данные в базу.
После отправки запроса в микросервис, и проверки корректности ответа с помощью ассертов также надо проверить корректность логирования в базе антифрода и отправку ответа в шину.
Логирование работы каждого сервиса всегда происходит в отдельную таблицу БД антифрода, если заказчик не указал иное. Проверка происходит ручным составлением запроса в БД или добавлением проверки данных из БД с помощью SoapUI - JDBC request.
Проверка логов шины данных тоже включается в процесс тестирования микросервиса. Микросервис должен принять ответ от ядра, сформировать ответ для шины в нужном формате и отправить его в шину по соответствующему протоколу. Шина логирует входящие сообщения от сервисов и делает запись в соответствующий лог. На данном этапе проверяется состав полей ответа, соответствие с ТЗ заказчика.
Замечание. При end-2-end тестировании особое значение уделяется проверкам по составу входящих и исходящих сообщений в шину данных. Состав, наименования и структура json и xml полей, соответствие типов данных и т.д. Если типы данных или имена полей не согласуются, то мы получает 100% вероятность дефекта при записи в БД или при обработке документа соответствующим коннектором или микросервисом, как в системе приемнике, так и в системе-источнике.
Вывод
Антифрод-система в банках сейчас является одним из важнейших модулей в инфраструктуре и некорректная работа данной системы может сильно повлиять на надежность и безопасность обслуживания. Тестирование данной системы также имеет высокий приоритет для департамента финансового мониторинга. Спецификой работы над таким проектом является глубокое погружение команды тестирования в предметную область банковских операций. Взаимодействие с множеством сотрудников различных систем-источников требуют высоких аналитических навыков, ведь время погружение в задачу и предметную область диктуется релизными рамками.
