Тестирование банковских и финансовых систем

Почему банковское ПО требует максимальной строгости тестирования #

Банковская сфера и финансы — один из самых требовательных доменов для тестирования ПО. Один баг может привести к финансовым потерям тысяч клиентов, регуляторным штрафам в миллионы или полной потере доверия клиентов. В отличие от приложения соцсети, где баг вызывает лёгкое неудобство, банковский баг может означать реальные деньги, исчезающие с реальных счетов.

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

Терминология домена, которую нужно знать #

Прежде чем тестировать банковское ПО, нужно говорить на языке домена:

• Книга учёта (Ledger): Центральный реестр всех финансовых транзакций
• Расчёт (Settlement): Фактический перевод средств между сторонами
• Сверка (Reconciliation): Проверка соответствия записей между системами
• Клиринг (Clearing): Процесс передачи и подтверждения платёжных поручений между банками
• Float: Деньги в процессе перевода между счетами
• T+1, T+2: Сроки расчётов — один или два рабочих дня после даты сделки
• KYC: Know Your Customer — требования по верификации личности

Вызовы финансового тестирования #

Десятичная точность: ловушка плавающей точки #

Самый фундаментальный вызов финансового тестирования — числовая точность. Стандартная арифметика с плавающей точкой создаёт ошибки, невидимые в большинстве доменов, но катастрофические в финансах:

# Это падает в стандартной плавающей точке
assert 0.1 + 0.2 == 0.3  # False! Результат: 0.30000000000000004

# Финансовые системы должны использовать точные десятичные типы
from decimal import Decimal
assert Decimal('0.1') + Decimal('0.2') == Decimal('0.3')  # True

Тест-кейсы должны проверять, что система использует точную десятичную арифметику на всём пути — от ввода пользователя, через вычисления, до хранения и отображения.

Конвертация валют и мультивалютность #

Тестирование валютных операций добавляет сложности:

• У валют разное количество десятичных знаков: USD (2), JPY (0), BHD (3)
• Курсы обмена постоянно меняются и должны иметь метку времени
• Правила округления различаются по валюте и юрисдикции
• Кросс-валютные транзакции включают несколько шагов конвертации

Атомарность транзакций и конкурентный доступ #

Финансовые транзакции должны быть атомарными — они либо завершаются полностью, либо не выполняются вовсе. Рассмотрим сценарий:

Счёт A: $1,000
Перевод $500 с A на B
Перевод $700 с A на C (отправлен одновременно)

Без надлежащего контроля конкурентного доступа оба перевода могут прочитать баланс $1,000 и выполниться успешно, что приведёт к отрицательному балансу. Тестирование должно проверять, что система корректно обрабатывает одновременный доступ.

Обработка конца дня (EOD) #

Банки запускают пакетные процессы в конце дня для расчёта процентов, обработки постоянных поручений, генерации выписок и сверки счетов. Тестирование EOD должно проверять:

• Расчёты процентов по всем типам счетов
• Корректную обработку границ часовых поясов
• Обработку неудавшихся транзакций
• Точность генерации выписок
• Доступность системы во время и после пакетной обработки

Тестирование регуляторного соответствия #

Финансовое ПО работает в рамках строгих регуляторных фреймворков, которые напрямую формируют стратегию тестирования.

PCI DSS (Payment Card Industry Data Security Standard) #

PCI DSS регулирует хранение, обработку и передачу данных держателей карт:

• Номера карт должны быть замаскированы во всех отображениях и логах (показывать только последние 4 цифры)
• Данные должны быть зашифрованы при передаче (TLS 1.2+) и хранении (AES-256)
• Контроль доступа должен ограничивать данные карт только авторизованным сотрудникам
• Аудиторские следы должны логировать каждый доступ к данным карт

SOX (закон Сарбейнса-Оксли) #

SOX требует, чтобы системы финансовой отчётности имели надлежащие внутренние контроли:

• Все изменения в финансовых системах должны быть аудируемыми
• Разделение обязанностей — тот, кто пишет код, не может деплоить его в продакшен
• Проверки целостности данных в финансовых отчётах

PSD2 и Open Banking #

Директива ЕС о платёжных услугах требует от банков открыть свои API сторонним провайдерам:

• Строгая аутентификация клиента (SCA) должна быть протестирована
• Безопасность API и ограничение частоты запросов
• Управление согласиями и контроль обмена данными

Требования KYC/AML #

Требования Know Your Customer и Anti-Money Laundering предполагают:

• Процессы верификации личности
• Мониторинг транзакций на подозрительные паттерны
• Проверку по спискам санкций
• Отчётность по крупным или необычным транзакциям

Продвинутые техники банковского тестирования #

Тестирование интеграции платёжных шлюзов #

Платёжные шлюзы связывают мерчантов с карточными сетями. Тестирование должно покрывать:

• Множество типов карт (Visa, Mastercard, Amex) с разными правилами процессинга
• Потоки аутентификации 3D Secure (challenge и frictionless)
• Частичные списания, возвраты и чарджбэки
• Failover шлюза — что происходит при недоступности основного шлюза?
• Идемпотентность — дублирующие запросы не должны создавать двойные списания

Тестирование сообщений SWIFT и SEPA #

Международные переводы используют стандартизированные форматы сообщений:

• Сообщения SWIFT MT (MT103 для клиентских переводов, MT202 для межбанковских)
• Кредитные переводы SEPA и прямые дебеты для платежей в ЕС
• Валидация сообщений по схеме и бизнес-правилам
• End-to-end отслеживание через несколько банков-корреспондентов

Валовой расчёт в реальном времени (RTGS) #

Высокостоимостные переводы проводятся индивидуально и в реальном времени:

• Тестирование окончательности расчёта — после проведения транзакция не может быть отменена
• Управление ликвидностью — проверка наличия достаточных средств на расчётном счёте банка
• Обработка тайм-аутов для неподтверждённых расчётов

Disaster Recovery для финансовых систем #

Финансовые системы имеют почти нулевую толерантность к простою:

• Recovery Point Objective (RPO): сколько данных можно потерять? (обычно ноль для транзакций)
• Recovery Time Objective (RTO): как быстро система должна восстановиться?
• Тестирование failover на резервные дата-центры с проверкой живых транзакций

Практическое задание #

Спроектируйте тест-план для функции банковского перевода онлайн. Покройте эти области:

1. Happy path: Перевод $100 с текущего счёта на сберегательный, проверка обновления обоих балансов
2. Граничные значения: Нулевая сумма, один цент ($0.01), максимальный лимит перевода, один цент выше максимума
3. Кросс-валютный: Перевод USD на счёт в EUR, проверка применения курса обмена и округления
4. Конкурентные переводы: Два перевода с одного счёта отправлены одновременно — проверка отсутствия овердрафта
5. Соответствие PCI DSS: Проверка маскирования номеров счетов в подтверждении, логах и уведомлениях

Советы из практики #

1. Никогда не используйте плавающую точку для денег в тестовых данных — используйте точные десятичные типы или целые копейки
2. Тестируйте правила округления явно — банковское округление (round half to even) отличается от стандартного
3. Всегда тестируйте с несколькими валютами, включая те, что с 0 десятичных (JPY), 2 (USD) и 3 (BHD)
4. Проверяйте, что аудиторские следы логируют каждую деталь транзакции: кто, что, когда, откуда и состояние до/после
5. Тестируйте пакетную обработку конца дня с реалистичными объёмами данных, а не на горстке тестовых счетов

Ключевые выводы #

1. Финансовое ПО требует математической точности — никогда не используйте плавающую точку для расчётов с деньгами
2. Регуляторное соответствие (PCI DSS, SOX, PSD2) не является опциональным и формирует всю стратегию тестирования
3. Тестирование конкурентного доступа и сверки — две самые критичные области в банковском QA
4. Аудиторские следы должны быть полными и защищёнными от подделки — тестируйте их полноту и точность