company_banner

Как (авто)тестировать Монстра

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


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



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



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


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

Comments 14

    0
    Вполне оправданый отказ от тестирования через фронтенд. Так как вы через веб-API цепляетесь у вас максимально возможный охват слоев ( за исключением фронта). Конечно же бизнес процессы и целостность данных в таком приложени на первом месте. Но совсем про фронтенд забывать все-таки не стоит. А то придет беда, откуда не ждали :)

    Сколько времени вам понадобилось, чтобы прийти к нынешнему решению?
      0
      Чуть больше года назад начали, прошлым летом. Пару пилотов провели, не взлетело. Окончательно фреймворк в текущем виде сформировался в марте 2020.
      С фронтендом пока у нас вопрос открытый. Сейчас его ручным тестированием только покрывают.
    • UFO just landed and posted this here
        0
        АБС ЦФТ-Банк — монстр, который должен умереть.
          0
          Вопрос в альтернативах.

          А вообще, пусть поживет. У нас еще миграция на него даже не завершилась.
          0

          Для тестирования PL/SQL API могу ещё порекомендовать utPLSQL: есть компараторы коллекций, курсоров, объектов, иерархии тестов, автооткаты, оценка code coverage (через DBMS_PROFILER), умеет выдавать тестовые отчёты в формате JUnit/TeamCity. Для тестов с большими наборами данных покажет более высокую эффективность, так как данные не покинут пределы экземпляра Oracle.


          Есть нюансы:


          • тесты нужно писать на PL/SQL и деплоить на схему;
          • движок построен на аннотациях, что может потребовать периодического сканирования спецификаций всех пакетов схемы, исключая системные пакеты — на схемах с большим количеством объектов будет тормозить на старте (обходится расширением списка исключений в ядре utPLSQL или использованием триггера для инкрементальных обновлений кэша аннотаций).
            0
            Слышал про этот инструмент, сходу не смог придумать, как его к ЦФТшным реалиям можно применить.
            Но, надо присмотреться плотнее. Спасибо.
            • UFO just landed and posted this here
          • UFO just landed and posted this here
              0
              Мне известно 4 разных решения для тестирования от вендора. Вы имеете в виду машину тестирования? Можно подробнее чем не устроила? Тестирует тоже без «фронтенда».

              Да, я про МТ. Очень сложная в изучении и сопровождении система. Для ее работы нужно минимум два стенда, на которые «нельзя дышать». Найти автоматизаторов на работу с ней на рынке — не реально. Ну и плюс это все в дистрибутиве, под лицензией — под себя не докрутить.
              А про какие другие решения от вендора вы говорите? Вы именно про ЦФТ?

              Названия пакетов с этими процедурами могут содержать id и отличаться на разных схемах. Как решен этот вопрос? Что будете делать после отказа от Oracle?

              Id в имени процедуры появляется, если название исходной операции длинное. Эти Id (и следом названия пакетов) статичные, кроме расширений. Больше проблем доставляют id параметров на формах операций, которые могут меняться после пересоздания формы. Но, и то и то достается select'ом из таблиц methods, method_parameters…
              Мы при формировании http-запроса динамически достаем требуемые id.

              Не боитесь изменения API?

              Опасаемся, да. Будем подстраиваться. Вряд ли тут будут единомоментные кардинальные изменения.

              А как вы его выполняете если отправляете http запросы?

              Наш фреймворк позволяет использовать и http-запросы, и выполнение select'ов в произвольном порядке. Commit там идет по большей части после OK в операциях. Затруднения может вызывать PLPCALL внутри операций — с ним надо индивидуально смотреть что происходит внутри конкретной операции.

              Это как-то медленно, какая степень параллельности?
              У вендора есть несколько решений для записи юнит-тестов на языке pl+, пробовали эти инструменты?

              Это в один поток.
              Есть ссылки на описания инструментов?
              • UFO just landed and posted this here
                  0
                  Да, я про МТ. Очень сложная в изучении и сопровождении система. Для ее работы нужно минимум два стенда, на которые «нельзя дышать».

                  Да, в этом проблема была. Но с появлением Oracle Multitenant, стало гораздо удобнее пользоваться МТ. Создал себе копию и ломаешь ее сколько угодно.

                  Хоть инструмент и массивный, но со своей функцией очень даже справляется. Если разработать набор правил по работе с МТ и придерживаться их, то она много раз спасет от багов в проде. Плюс, можно накрутить функционал «сверху», под себя.

                  У нас она встроена в CI. Перед установкой на бой каждое хранилище ставится на PDB МТ с прогоном всех тесты.

                  Что будете делать после отказа от Oracle?

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

                  Спасибо за статью! Очень интересно узнать, как другие банки решают те же проблемы.
                  И учитывая практически полное отсутствие информации по работе с ИБСО за рамками банка.
                    0
                    Что будете делать после отказа от Oracle?

                    Будем решать проблему по мере поступления. Вряд ли это произойдет в ближайшей перспективе.
                    А статья о решении конкретной насущной задачи.
                0
                del

                Only users with full accounts can post comments. Log in, please.