Здравствуй, уважаемый читатель.
Сфера 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 часа.
Стабильность тоже на высоте. Проблемы возникают зачастую из-за отсутствия нужных тестовых данных на тестовом стенде. Подготовка данных для сквозных сценариев – отдельная, не тривиальная задача, над которой мы только начали работать.
Впереди еще много вызовов от Монстра, главное – найти подходящий инструмент для каждой задачи.
Будет интересно, если вы поделитесь своим опытом тестирования ЦФТ-Банк.
Твой ход, @другойбанк
