Здравствуй, уважаемый читатель.

Сфера IT в банках весьма обширна. И, думаю, сообщество банковских IT-шников представлено на Хабре достаточно широко. В этой статье затронем тему тестирования специфического банковского ПО. Из-за некоторой закрытости такого рода организаций информации о происходящем внутри просачивается довольно мало. Давайте приоткроем завесу тайны.

Итак, позвольте представиться. Меня зовут Алексей, и я алк… тестирую АБС ЦФТ-Банк.

Что за Монстр

ЦФТ-Банк – автоматизированная банковская система (АБС) разработки ООО «Центр
финансовых технологий». Это ядро IT-экосистемы Банка. И, де-факто, ЦФТ-Банк – стандарт АБС среди российских банков.

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

Наша АБС сейчас – это:

• 20.000 таблиц с прикладными данными в СУБД Oracle.
• 30.000 различных пользовательских операций. (Здесь же нужно учитывать всевозможные вариативные цепочки операций, зависящие от конкретного кейса).
• 19.000 активных зарегистрированных пользователей.
• 35 TB данных в СУБД. (Подготовка копий БД для тестовых стендов – тема для отдельного разговора).

Тестируй меня полностью

Монстр – живой. Круглосуточно. Круглогодично. Все возможные праздничные дни и новогодние каникулы – на вес золота. Это время, когда можно вкатывать большие изменения, импортировать новые филиалы, проводить регламентные работы.

Кроме таких больших обновлений есть и еженедельные релизы, ведь Банк должен постоянно улучшать свои продукты. А сколько «веселья» добавила работа во время активности всем известного вируса… эти срочные «ковидные» поставки будут долго сниться нашим разработчикам и тестировщикам.

Важно понимать, что у системы достаточно высокая связанность – по данным, управлению, содержимому. Зачастую очень сложно или даже невозможно предугадать степень влияния, казалось бы, минорного изменения на различные процессы в АБС.

В связи с этим все изменения проходят многоступенчатое тестирование – модульное, функциональное, интеграционное. И его финальная часть – регрессионное. О нем и поговорим.

А можно всех посмотреть?

Ввиду ограниченности ресурсов, как серверных, так и человеческих, на еженедельных релизах приходится проводить строгий «кастинг» тест-кейсов. Тест-менеджеры отобрали и согласовали список из 1.500 тест-кейсов. Один кейс занимает от 5 минут у опытного тестировщика. А иногда требуется и повторный прогон.

И тут, определенно, нужна автоматизация.

Но – система весьма специфичная и закрытая, и готовых открытых инструментов для ее тестирования просто нет.

У вас роботы не той системы

Различных подходов к автоматизации тестирования ЦФТ-Банк достаточное количество.
Но, все «не без греха».

• В некоторых банках пытаются реализовать UI-тестирование. Проблема в том, что тут нативный desktop-клиент, совершенно не дружественный к автоматизаторам.

Например, науке известны случаи применения TestComplete. Но для этого приходится много костылить и использовать недокументированные фичи приложения. В итоге такие тесты получаются медленными и хрупкими.

• Отдельные компании-интеграторы предлагают свои варианты. Здесь разброс от применения HP UFT до полностью самостоятельных разработок. Некоторые динамичные компании даже научились неплохо тестировать UI. Но тут свои сложности с пересаживанием на иглу другого поставщика (если понимаете, о чем я).
• Есть даже решение от самого вендора системы. Но Монстр породил Монстра – этот инструмент весьма ресурсоемкий и чрезмерно требовательный к ресурсам для обработки результатов тестирования.

Мы пойдем своим путем

После проведения исследований и пользуясь преимуществом знания внутреннего устройства системы, решили есть Монстра по частям и использовать при этом подходящие инструменты:

• Есть в системе функционал, вся реализация которого зашита в отдельных процедурах Oracle. Никакой логики на клиенте, только кнопка «Запуск». Будем вызывать процедуры напрямую!
• Есть проверка продуктовых настроек – не изменило ли очередное обновление данные в таблицах, которые не должны меняться. Выполняем select и сверяем с эталонным результатом!
• Есть use case с запуском нескольких операций подряд. Будем эмулировать запросы клиента! Тут нам помогает трехуровневая архитектура – между нативным десктопом и СУБД есть http сервер приложений. Немного наблюдательности и становится возможным отправлять запросы по http, идентичные клиентскому приложению.

При этом мы исключили из тестирования само клиентское приложение. Но считаем это допустимым ввиду его редких и несущественных изменений. Зато в плюсах – высокая скорость работы тестов и их стабильность.

Остается добавить динамическое вычисление некоторых параметров в запросах, подготовку данных для тестов, анализ результатов работы вызываемых операций… Здесь становится критичным знание внутренностей Монстра – в каких полях каких таблиц отслеживать результат.

Монстр любит разнообразие

Применение такого диверсифицированного подхода к автоматизации тест-кейсов существенно упрощает автоматизацию и позволяет увеличивать долю автоматизированных тестов в регрессе.
На данный момент мы достигли показателя в 30% автоматизации критичных кейсов. И теперь наращиваем темп.

Заметным плюсом отказа от автоматизации через GUI стала скорость работы автотестов. Имеющийся набор из 491 теста проходит в среднем за 32 минуты. Для сравнения, ручной проход этих тест-кейсов занимал суммарно 34 часа.

Стабильность тоже на высоте. Проблемы возникают зачастую из-за отсутствия нужных тестовых данных на тестовом стенде. Подготовка данных для сквозных сценариев – отдельная, не тривиальная задача, над которой мы только начали работать.

Впереди еще много вызовов от Монстра, главное – найти подходящий инструмент для каждой задачи.

Будет интересно, если вы поделитесь своим опытом тестирования ЦФТ-Банк.
Твой ход, @другойбанк