Тестирование банковского ПО (Banking domain applications/BFSI)

Банковские приложения (Сектор BFSI или Banking, Financial Services, and Insurance - банковские, финансовые услуги и страхование) являются одними из самых сложных приложений в современной индустрии разработки и тестирования программного обеспечения. Что делает банковские приложения такими сложными? Какой подход следует использовать для тестирования сложных рабочих процессов, связанных с банковскими приложениями? Банковские приложения напрямую связаны с конфиденциальными финансовыми данными. Все операции, выполняемые банковским программным обеспечением, должны выполняться без сбоев и ошибок. Банковское ПО выполняет различные функции, такие как перевод и внесение средств, запрос баланса, история транзакций, вывод средств и так далее. Тестирование банковского приложения гарантирует, что эти действия не только хорошо выполняются, но и остаются защищенными от хакеров.

Давайте сначала разберемся с характеристиками банковского приложения:

Многоуровневая функциональность для поддержки тысяч одновременных пользовательских сеансов;
Крупномасштабная интеграция. Как правило, банковское приложение интегрируется с множеством других приложений;
Сложные бизнес-процессы;
Обработка в режиме реального времени и пакетная обработка (Real-Time and Batch processing);
Высокая скорость транзакций в секунду;
Безопасные транзакции;
Надежный раздел отчетности для отслеживания повседневных транзакций;
Строгий аудит для устранения проблем клиентов;
Массивная система хранения;
Управление аварийными ситуациями/восстановлениями.

Что делает банковские приложения такими сложными?

Банковское программное обеспечение в основном имеет дело с конфиденциальными финансовыми данными, поэтому работа программного обеспечения должна быть безошибочной и безопасной;
Разработчики предпочитают сложный дизайн для разработки этих приложений, чтобы гарантировать, что приложение работает безопасным образом;
Банковское дело - это постоянно меняющийся мир. Банковское дело сегодня доступно для клиентов с использованием различных каналов, таких как обычные отделения, банкоматы, онлайн-банкинг и обслуживание клиентов;
С появлением технологий многие кошельки наводнили рынки, которые подключаются к банковским системам для финансовых транзакций;
Ожидается, что банковские услуги будут работать 24*7 с высокой производительностью. Обновления программного обеспечения, мгновенные исправления и т. д. не должны повлиять на эту доступность;
На банковский мир также сильно влияют постоянные изменения, вносимые правительством в виде банковских правил. Любые изменения в структуре налогообложения повлияют и на банковскую систему;
Банковская система также должна быть современной в том, что касается новых технологий. Аналитика данных, такая как обработка больших данных, и получение информации из больших данных с помощью науки о данных (Data Science), становятся все более популярными в банковском мире.

Когда мы говорим о тестировании банковских приложений, требуется методология сквозного тестирования (End to End Testing methodology), включающая несколько методов тестирования программного обеспечения, чтобы гарантировать:

Полный охват всех банковских рабочих процессов (banking workflows) и бизнес-требований (Business Requirements);
Функциональный аспект приложения;
Аспект безопасности приложения;
Целостность данных (Data Integrity);
Параллелизм (Concurrency);
Пользовательский опыт.

Banking App Testing Workflow

Типичные этапы тестирования банковских приложений показаны в приведенном ниже рабочем процессе. Мы обсудим каждый этап индивидуально. Это модель Waterfall для тестирования приложения.

1. Сбор требований: этап сбора требований включает в себя документирование требований либо в виде функциональных спецификаций (Functional Specifications), либо в виде вариантов использования (Use Cases). Требования собираются в соответствии с потребностями клиентов и документируются банковскими экспертами или бизнес-аналитиками. Эксперты участвуют в написании требований по более чем одной теме, поскольку банковское дело само по себе имеет несколько поддоменов, и одно полноценное банковское приложение будет интегрировать все эти домены. Например, банковское приложение может иметь отдельные модули для переводов, кредитных карт, отчетов, ссудных счетов, оплаты счетов, торговли и т. д.;

2. Обзор требований: результаты сбора требований проверяются всеми заинтересованными сторонами, такими как QA, руководители разработки и бизнес-аналитики. Они перепроверяют, чтобы ни существующие бизнес-процессы, ни новые рабочие процессы не нарушались. Все требования проверены и утверждены. Последующие действия и пересмотры документов требований выполняются на основе того же;

3. Подготовка бизнес-сценария: на этом этапе QA составляют бизнес-сценарии (Business Scenarios) из документов с требованиями (requirement documents - Functions Specs or Use Cases); Бизнес-сценарии разработаны таким образом, что охватывают все бизнес-требования. Бизнес-сценарии - это сценарии высокого уровня без каких-либо подробных шагов. Кроме того, эти бизнес-сценарии проверяются бизнес-аналитиками, чтобы убедиться, что все бизнес-требования выполнены. BA легче просматривать сценарии высокого уровня, чем просматривать подробные тестовые случаи низкого уровня. Например, клиент, открывающий срочный депозит в интерфейсе цифрового банкинга, может быть бизнес-сценарием. Точно так же у нас есть различные бизнес-сценарии, связанные с созданием банковского счета, онлайн-депозитами, онлайн-переводами и т. д.;

4. Функциональное тестирование: на этом этапе выполняется функциональное тестирование и выполняются обычные действия по тестированию программного обеспечения, такие как:

Подготовка тестовых случаев (Test Case Preparation): на этом этапе тестовые случаи создаются на основе бизнес-сценариев, один бизнес-сценарий приводит к нескольким положительным и отрицательным тестовым случаям;
Обзор тестовых случаев (Test Case Review): обзоры, сделанные коллегами-инженерами по обеспечению качества;
Выполнение тестовых случаев (Test Case Execution): выполнение тестового набора.

Функциональное тестирование банковского приложения сильно отличается от обычного тестирования программного обеспечения. Поскольку эти приложения работают с деньгами клиентов и конфиденциальными финансовыми данными, их необходимо тщательно протестировать. Ни один важный бизнес-сценарий не должен оставаться незамеченным. Кроме того, ресурс QA, который тестирует приложение, должен иметь базовые знания в банковской области.

5. Тестирование баз данных: банковское приложение включает в себя сложные транзакции, которые выполняются как на уровне пользовательского интерфейса, так и на уровне базы данных, поэтому тестирование базы данных так же важно, как и функциональное тестирование. База данных сложна и представляет собой совершенно отдельный слой в приложении, поэтому ее тестирование проводится специалистами по базам данных. Оно использует такие методы, как:

Загрузка данных;
Миграция базы данных;
Тестирование схемы БД и типов данных;
Тестирование правил;
Тестирование хранимых процедур и функций;
Тестирование триггеров;
Целостность данных.

Основная цель тестирования базы данных состоит в том, чтобы убедиться, что:

Приложение может хранить и извлекать данные из базы данных без потери данных;
Завершенные транзакции должны быть зафиксированы, а прерванные транзакции должны быть возвращены обратно, чтобы избежать любых несоответствий в сохраненных данных;
Доступ к базе данных и базовым таблицам разрешен только авторизованным приложениям и пользователям.

В основном существует три способа тестирования базы данных:

Структурное тестирование: включает в себя тестирование объектов базы данных, таких как базы данных, схемы, таблицы, представления, триггеры, элементы управления доступом и т. д. Обеспечение синхронизации типов данных в таблицах с соответствующими переменными в приложении. Проверка данных и ссылочной целостности в таблицах. Например, поле суммы в приложении должно иметь в таблице тип данных decimal/float. Чтобы соответствовать этим стандартам, пользователям следует предоставить средства управления доступом через представления;
Функциональное тестирование: включает в себя тестирование баз данных, которые удовлетворяют требованиям пользователя. Есть два способа добиться этого: тестирование черного ящика и тестирование белого ящика. Например, когда мы делаем онлайн-перевод денег, счет отправителя должен быть списан, а счет получателя должен быть зачислен на ту же сумму. Если транзакция завершается неудачей, вся транзакция должна быть отменена, а счет отправителя не должен дебетоваться или кредитоваться обратно;
Нефункциональное тестирование: включает в себя нагрузочное и стресс-тестирование и оптимизацию производительности. Нагрузочное тестирование помогает определить максимальное количество транзакций, которые могут выполняться одновременно, не влияя на производительность базы данных. Например, на основе результатов нагрузочного и стресс-тестирования банковские приложения могут решить добавить больше ресурсов в свое приложение в часы пик и сократить ресурсы в нерабочее время. Это помогает банку оптимально использовать ресурсы и экономить деньги.

Тестирование безопасности проверяет приложение на:

Любую внешнюю атаку или попытку взлома приложения со злым умыслом;
Любую лазейку в программном приложении может быть использована, что приведет к потере данных или денежных средств;
Любую уязвимость в сети, серверах или рабочих станциях, на которых размещено приложение.

Ниже приведены различные типы тестирования безопасности:

Тестирование уязвимостей (Vulnerability Testing): разрабатывается и выполняется автоматизированная программа для проверки на наличие различных уязвимостей;
Сканирование безопасности (Security Scanning): этот вариант вращается вокруг исследования уязвимостей сети и системы, тем самым предоставляя решения для снижения связанного с этим риска;
Тестирование на проникновение (Penetration Testing): этот вариант тестирования безопасности имитирует попытку взлома для захвата уязвимостей и лазеек, которые могли бы дать хакеру доступ к базе данных или данным приложения;
Аудит безопасности (Security Audit): это включает в себя аудит приложения и связанных сетей на предмет любых нарушений безопасности;
Оценка риска (Risk Assessment): выполняется анализ для оценки уровня риска в случае, если уязвимость или лазейка используются со злым умыслом. Такой риск можно разделить на низкий, средний и высокий. В зависимости от уровня риска группа тестирования рекомендует надлежащие меры для снижения или предотвращения риска;
Этический взлом (Ethical Hacking): выполняется организацией в своих системах для выявления лазеек, которые могут быть использованы в ее приложении или сети. Цель этого вида взлома не состоит в том, чтобы украсть или нанести ущерб приложению или сети;
Оценка состояния (Posture Assessment): это комплексная оценка, включающая сканирование безопасности, оценку рисков и взлом с соблюдением этических норм;
SQL-инъекция: SQL-инъекция может использоваться для получения доступа к базе данных сервера. Тестирование выполняется, чтобы убедиться, что код работает правильно, выполняя запросы в базе данных на основе следующих входных данных от пользователя: Скобки, Апострофы, Запятые, Кавычки.

Другие этапы тестирования BFSI приложений

Помимо вышеуказанных основных этапов, могут быть задействованы различные этапы, такие как интеграционное тестирование, тестирование удобства использования, пользовательское приемочное тестирование и тестирование производительности.

Примеры тестов для банковского приложения

Для нового филиала (?New Branch):
- Создайте новый филиал с допустимыми и недействительными тестовыми данными;
- Создайте новый филиал без данных;
- Создайте новый филиал с существующими данными;
- Проверьте параметры сброса и отмены;
- Обновите сведения о филиале с допустимыми и недействительными тестовыми данными;
- Обновите сведения о филиале с помощью существующих тестовых данных;
- Проверьте, можно ли сохранить новый филиал;
- Убедитесь, что опция отмены работает;
- Проверьте удаление филиала с зависимостями и без них;
- Проверьте, работает ли опция поиска филиалов.
Для новой роли:
- Создайте новую роль с допустимыми и недействительными тестовыми данными;
- Создайте новую роль без данных;
- Проверьте, можно ли создать новую роль с существующими тестовыми данными;
- Проверьте описание роли и тип роли;
- Убедитесь, что опция отмены и сброса работает;
- Проверьте процесс удаления роли с зависимостью и без нее;
- Проверьте ссылки на странице сведений о роли.;
- Проверьте вход администратора без тестовых данных;
- Проверьте все домашние ссылки для роли администратора;
- Убедитесь, что администратор может изменить пароль с допустимыми и недействительными тестовыми данными;
- Убедитесь, что администратор успешно вышел из системы.
Для Клиента и Банкира:
- Убедитесь, что все ссылки посетителей и клиентов работают правильно;
- Проверьте вход клиента с действительными и недействительными тестовыми данными;
- Проверьте логин клиента без каких-либо данных;
- Проверьте логин банкира без каких-либо данных;
- Проверьте логин банкира с действительными или недействительными тестовыми данными%
- Проверьте, смог ли клиент и банкир успешно выйти из системы.
Для новых пользователей:
- Проверьте, можно ли создать нового пользователя с допустимыми и недействительными тестовыми данными;
- Создайте нового пользователя с существующими тестовыми данными филиала;
- Убедитесь, что опция отмены и сброса работает правильно;
- Обновите сведения о пользователе, указав действительные и недействительные тестовые данные;
- Проверьте удаление нового пользователя;
- Проверьте, можно ли верифицировать нового пользователя;
- Проверьте обязательные входные параметры;
- Проверьте дополнительные входные параметры;
- Проверьте, можно ли создать пользователя без необязательных параметров.
Для создания новой учетной записи:
- Создайте новую учетную запись с действительными и недействительными данными пользователя;
- Убедитесь, что сведения о пользователе могут быть обновлены;
- Проверьте, можно ли сохранить нового пользователя;
- Создайте новую учетную запись с существующими данными пользователя;
- Убедитесь, что пользователь может внести сумму во вновь созданную учетную запись (и обновить баланс);
- Проверьте, может ли пользователь снять сумму с новой учетной записи (после внесения депозита и обновления баланса);
- В случае заработной платы учетная запись проверяет название компании и другие данные, предоставленные пользователем;
- Проверьте, указан ли номер основной учетной записи в случае дополнительной учетной записи;
- Проверьте данные пользователя, указанные в случае текущей учетной записи;
- Проверьте предоставленное доказательство для совместного счета в случае совместного счета;
- Проверьте, можете ли вы поддерживать нулевой баланс на вашем счете заработной платы;
- Проверьте, можете ли вы поддерживать нулевой баланс или минимальный баланс для счета, не связанного с зарплатой;
- Убедитесь, что новый пользователь смог успешно выйти из системы.
Для сетевого банковского приложения (Net Banking Application):
- пользователь может открыть сайт банка;
- все ссылки на сайте работают;
- пользователь может создать новую учетную запись;
- Проверьте, может ли пользователь войти в систему с допустимым и недействительным именем пользователя и паролем.
- Проверьте, что если имя пользователя или пароль пусты при входе в систему, пользователю не должно быть разрешено войти в систему, и должно отображаться предупреждающее сообщение;
- Проверьте, разрешено ли пользователю изменять пароль;
- Если введено неверное имя пользователя или пароль, будет показано соответствующее сообщение об ошибке;
- Пользователям с неверным паролем не разрешается входить в систему;
- Убедитесь, что после неоднократных попыток входа с неправильным паролем пользователю должно быть показано сообщение об ошибке и он заблокирован;
- Проверьте, может ли пользователь выполнять некоторые основные транзакции;
- Убедитесь, что пользователь может добавить получателя с допустимыми и недействительными данными;
- Проверьте, может ли пользователь удалить получателя;
- Убедитесь, что пользователь может совершать транзакции для вновь добавленного получателя;
- После транзакции проверьте, были ли обновлены учетные записи пользователя и получателя;
- Проверьте, может ли пользователь ввести сумму в десятичном виде (4.50);
- Убедитесь, что пользователь не может вводить отрицательные числа в поле суммы;
- Проверьте, разрешено ли пользователю совершать транзакции с минимальным балансом или без него;
- Проверьте, может ли пользователь создать новый RD;
- Убедитесь, что отображается правильное сообщение в случае транзакции, выполненной с недостаточным балансом;
- Проверьте, запрашивается ли у пользователя подтверждение перед выполнением какой-либо транзакции;
- Убедитесь, что квитанции о подтверждении предоставлены для каждой успешной транзакции;
- Проверьте, может ли пользователь переводить деньги на несколько счетов;
- Проверьте, может ли пользователь отменить транзакцию;
- Убедитесь, что данные учетной записи также отражают выполненные финансовые операции;
- Убедитесь, что функция тайм-аута реализована;
- Убедитесь, что в случае истечения времени сеанса пользователь должен снова войти в систему;
- Убедитесь, что установлен правильный тайм-аут сеанса в случае бездействия;
- Убедитесь, что при выполнении транзакции пользователь переведен в безопасный режим;
- Убедитесь, что пользователь смог успешно выйти из системы;
- Проверьте параметры поиска и сброса.

Источники:

Доп. материал:

PreviousТестирование систем розничной торговли (POS - Point Of Sale)NextТестирование страхового ПО (Insurance)

Last updated 3 years ago

Was this helpful?