Введение

Не всегда, приходя на крупный новый или старый проект, новый тестировщик знает с какой стороны подойти к началу процесса тестирования. Иногда нет куратора, иногда не настроен процесс коммуникации. И вы можете хоть сто раз плюнуть в компанию и пойти искать новую, благо рынок сейчас в дефиците. Но гораздо интереснее будет получить бесценный опыт становления вас как самостоятельного и понимающего члена команды. Данная статья будет посвящена теории тестирования реализаций системы антифрод в одном из крупнейших банков РФ. О чем мы поговорим в этой статье? Об особенностях архитектуры 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, Тимлид, Техлид), который может обрисовать технологический стек и постарайтесь накидать для себя схему архитектуры сами. Потом, показывая картинку, легче понимать передвижение потоков данных и разговаривать с остальными членами команды на одном языке.

Пример состава тестового контура:

1. Шина данных. Очень часто в корпоративном секторе используется какой-то сервис очередей - tibco, kafka, RabbitMQ. 

2. Ядро антифрод системы (+ web интерфейс к ней для настройки политик).

3. БД с данными транзакций, клиентов и другими, для корректных расчетов системы антифрод и применения политик скоринга.

4. Остальные смежные системы, требуемые для тестирования

Смежные системы общаются с шиной посредством коннекторов. Для каждого коннектора на шине пишется отдельный сервис, который конвертирует данные из формата, понятного системе-источнику, в формат понятный шине. Чаще всего это xml.

После этого документ помещается в очередь, из которой шина отправляет данные в систему-приемник. В нашем частном случае это была антифрод-система.

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

Процессы тестирования

Процессы тестирования делятся на два вида - отдельно тестирование нового микросервиса и end-2-end тестирование. Каждый из этих видов включает несколько этапов со стороны команды тестирования.

Тестирование нового микросервиса включает в себя следующие этапы:

• Анализ технического задания на микросервис (разрабатывается заказчиком совместно с аналитиком);

• Декомпозиция требований и составление матрицы соответствия требований;

• Написание тест-плана для согласования с заказчиком. Можно найти шаблон в интернет-пространстве, если такового не имеется в наличие;

• Написание тест-кейсов согласно матрице. Используется любая система управления тестированием. В корпоративном секторе сейчас распространена TFS(Azure DevOps Server)

• Собственно, прохождение тест-кейсов и заведение дефектов;

• Отчетность по результатам тестирования - протоколы, артефакты и т.п. (опционально по согласованию с заказчиком)

В корпоративном секторе роль заказчика часто принадлежит внутреннему бизнес-подразделению и лицом принимающим решение со стороны бизнеса является его руководитель. Он же ставит бизнес-задачу на разработку интеграционного взаимодействия. Например, руководитель департамента МСБ (малый-средний бизнес). Тестовые данные в данном случае могут предоставлять сотрудники подразделения-заказчика.

Бизнес-задачи для системы антифрод может звучать так:

“Требуется, чтобы все платежи от юридических лиц проверялись в системе и отправлялись на ручную проверку\блокировались при значении скорингового балла более 60”.

“Требуется блокировать все запросы от ИП с просрочкой более 1 месяца”

End-2-end тестирование отличается тем, что к обычному процессу добавляется этап согласования тест-плана не только с заказчиком, но и с командой тестирования сервиса-источника. А также в процессе прохождения тест-кейсов все тестовые данные(запросы) генерируются ролями в системах-источниках. У каждой информационной банковской системы есть своя команда(внутренняя или внешний интегратор), разрабатывающая новые функции, и также имеет своих разработчиков и тестировщиков. E2E проводится совместно с ними.

Например: Тестировщик Диасофт от роли “Оператор” отправляет платеж по карте мир от одного юрлица к другому.  

Команда взаимодействия

Тестировщики системы взаимодействуют в работе со следующими ключевыми сотрудниками:

1. Проектный менеджер

2. Менеджер технологической инфраструктуры (возможно DevOps)

3. Аналитик со стороны разработки

4. Аналитик со стороны заказчика (опционально)

5. Разработчик со стороны сервиса-источника

6. Разработчик со стороны антифрод

7. Разработчик со стороны шины

8. Автотестировщик, Архитектор, Поддержка, Скрам-мастер и прочие невиданные звери - опционально, но скорее нет.

   Набор ролей соответствует стандартному набору ролей в жизненном цикле ПО по любой методологии.

Базовый сценарий тестирования

После того, как заказчик прислал требования и набор политик для антифрод, аналитики или служба поддержки настраивают их на тестовом контуре в веб-интерфейсе.

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

Вывод

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