Тестирование банковского ПО (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. Чтобы соответствовать этим стандартам, пользователям следует предоставить средства управления доступом через представления;
Функциональное тестирование: включает в себя тестирование баз данных, которые удовлетворяют требованиям пользователя. Есть два способа добиться этого: тестирование черного ящика и тестирование белого ящика. Например, когда мы делаем онлайн-перевод денег, счет отправителя должен быть списан, а счет получателя должен быть зачислен на ту же сумму. Если транзакция завершается неудачей, вся транзакция должна быть отменена, а счет отправителя не должен дебетоваться или кредитоваться обратно;
Нефункциональное тестирование: включает в себя нагрузочное и стресс-тестирование и оптимизацию производительности. Нагрузочное тестирование помогает определить максимальное количество транзакций, которые могут выполняться одновременно, не влияя на производительность базы данных. Например, на основе результатов нагрузочного и стресс-тестирования банковские приложения могут решить добавить больше ресурсов в свое приложение в часы пик и сократить ресурсы в нерабочее время. Это помогает банку оптимально использовать ресурсы и экономить деньги.
6. Тестирование безопасности: тестирование безопасности обычно является последним этапом цикла тестирования. Обязательным условием для начала тестирования безопасности является завершение функционального и нефункционального тестирования. Тестирование безопасности является одним из основных этапов всего цикла тестирования приложений, поскольку на этом этапе обеспечивается соответствие приложения федеральным и отраслевым стандартам. Из-за характера данных, которые они несут, банковские приложения очень чувствительны и являются главной целью для хакеров и мошеннических действий. Тестирование безопасности гарантирует, что приложение не имеет таких веб-уязвимостей, которые могут раскрыть конфиденциальные данные злоумышленнику. Это также гарантирует, что приложение соответствует таким стандартам, как OWASP. На этом этапе основной задачей является сканирование всего приложения, которое выполняется с помощью различных инструментов. После завершения сканирования публикуется отчет о сканировании. В этом отчете ложные срабатывания отфильтровываются, а остальные уязвимости сообщаются команде разработчиков, чтобы они могли приступить к устранению проблем в зависимости от серьезности каждой проблемы. На этом этапе также проводится тестирование на проникновение, чтобы выявить распространение ошибок. Необходимо проводить тщательное тестирование безопасности на разных платформах, в сетях и ОС. Несколько других используемых ручных инструментов для тестирования безопасности: Paros Proxy, Http Watch, Burp Suite и Fortify. Основная цель тестирования безопасности - выявить любые уязвимости, которые могут быть в программном приложении.
Тестирование безопасности проверяет приложение на:
Любую внешнюю атаку или попытку взлома приложения со злым умыслом;
Любую лазейку в программном приложении может быть использована, что приведет к потере данных или денежных средств;
Любую уязвимость в сети, серверах или рабочих станциях, на которых размещено приложение.
Ниже приведены различные типы тестирования безопасности:
Тестирование уязвимостей (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;
Убедитесь, что отображается правильное сообщение в случае транзакции, выполненной с недостаточным балансом;
Проверьте, запрашивается ли у пользователя подтверждение перед выполнением какой-либо транзакции;
Убедитесь, что квитанции о подтверждении предоставлены для каждой успешной транзакции;
Проверьте, может ли пользователь переводить деньги на несколько счетов;
Проверьте, может ли пользователь отменить транзакцию;
Убедитесь, что данные учетной записи также отражают выполненные финансовые операции;
Убедитесь, что функция тайм-аута реализована;
Убедитесь, что в случае истечения времени сеанса пользователь должен снова войти в систему;
Убедитесь, что установлен правильный тайм-аут сеанса в случае бездействия;
Убедитесь, что при выполнении транзакции пользователь переведен в безопасный режим;
Убедитесь, что пользователь смог успешно выйти из системы;
Проверьте параметры поиска и сброса.
Источники:
Доп. материал:
Last updated
