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


Сфера 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 часа.



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



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


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