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