Меню

Як перевірити додатки банківських доменів: Повний посібник з тестування BFSI

how test banking domain applications

Спробуйте Наш Інструмент Для Усунення Проблем

Повне керівництво з тестування банківської програми: Процес тестування та поради BFSI (банківська справа, фінансові послуги та страхування)

Банківські програми є одними з найскладніших програм у сучасній галузі розробки та тестування програмного забезпечення.

Що робить банківські програми настільки складними? Якого підходу слід дотримуватись для перевірки складних робочих процесів, пов'язаних з банківськими додатками?

У цій статті ми будемо висвітлювати різні етапи та методи, що беруть участь у тестуванні банківських додатків.

Як перевірити банківські програми

Що ви дізнаєтесь:

Як протестувати банківські програми?

Різні функції, які виконують банківські програми:

Функції банків

Давайте спочатку розберемося з характеристиками банківської програми:

  • Багаторівнева функціональність для підтримки тисяч одночасних сеансів користувачів
  • Широкомасштабна інтеграція: Як правило, банківська програма інтегрується з багатьма іншими програмами, такими як утиліта Bill Pay та торгові рахунки
  • Складні бізнес-процеси
  • Обробка в режимі реального часу та пакетна обробка
  • Висока швидкість транзакцій за секунди
  • Захищені транзакції
  • Надійний розділ звітування для відстеження щоденних операцій
  • Ефективний аудит для усунення проблем із клієнтами
  • Масивна система зберігання
  • Управління катастрофами / відновленням.

Перераховані вище десять пунктів - це найважливіші характеристики банківської програми.

Банківські програми мають кілька рівнів, задіяних у виконанні операції.

Наприклад , до Банківська заявка може мати:

  • Веб-сервер для взаємодії з кінцевими користувачами через браузер
  • Середній рівень для перевірки вхідних та вихідних даних веб-сервера
  • База даних для зберігання даних та процедур
  • Процесор транзакцій, який може мати великий мейнфрейм або будь-яку іншу застарілу систему для здійснення трильйонів транзакцій в секунду.

Якщо ми говоримо про тестування банківських додатків, для цього потрібно Методика наскрізного тестування, що включає безліч методів тестування програмного забезпечення, щоб забезпечити:

  • Загальне охоплення всіх банківських процесів та бізнес-вимог
  • Функціональний аспект програми
  • Аспект безпеки програми
  • Цілісність даних
  • Паралельність
  • Досвід користувача

Що робить банківські програми настільки складними?

  • Банківське програмне забезпечення в основному має справу з конфіденційними фінансовими даними, тому продуктивність програмного забезпечення повинна бути безпомилковою та безпечною.
  • Розробники воліють складний дизайн для розробки цих додатків, щоб забезпечити роботу програми в бажаному безпечному порядку.
  • Банківська справа - це світ, який постійно змінюється. Сьогодні банківська справа надається клієнтові за допомогою різних каналів, таких як цегляні відділення, банкомати, Інтернет-банкінг та обслуговування клієнтів.
  • З появою технологій багато гаманців заполонили ринки, які підключаються до банківських систем для фінансових операцій.
  • Очікується, що банківська справа також буде працювати і працюватиме 24 X 7 з високою продуктивністю. Не можна допускати, щоб оновлення програмного забезпечення, миттєві виправлення тощо впливали на цю доступність.
  • На банківський світ також сильно впливають постійні зміни, які вводить уряд у формі банківських норм. Будь-які зміни в податковій структурі впливають і на банківську систему.
  • Банківська система також повинна бути оновленою, що стосується нових технологій. Аналітика даних, така як обробка великих даних та отримання інстинктів з використання великих даних за допомогою Data Science, зростає в банківському світі.

Вищезазначені пункти роблять банківську систему складною для розробників для створення програмного додатку навколо неї.

Важливість тестування банківської програми

  • Тестування банківської програми гарантує, що всі заходи не тільки виконуються якісно, ​​але й залишаються захищеними та захищеними.
  • Банківське програмне забезпечення складне з тисячами залежностей, процес тестування вимагає більше часу, ресурсів та постійного моніторингу.
  • Оскільки тут задіяні фінанси, слід неухильно дотримуватися вказівок. І тестери, і розробники повинні володіти хорошими знаннями домену.
  • Найголовніше, слід забезпечити належне виконання законів та нормативних актів у фінансових операціях. Це можна забезпечити лише за допомогою тестування.
  • Важливо також переконатися, що програма та інфраструктура, на якій було розгорнуто додаток, здатні обробляти навантаження, особливо в пікові години роботи, не викликаючи жодних збоїв. Цього можна забезпечити, виконавши тестування продуктивності.
  • У сучасному цифровому світі єдине, що стосується всіх, це безпека. Банківські програми та фінансові операції, що виконуються в ній, повинні бути захищені від будь-якої спроби проникнення. Цього можна забезпечити, провівши перевірку безпеки. Тестування безпеки допомагає застосовувати галузеві стандарти для забезпечення фінансових операцій.
  • Важливо також забезпечити належну інтеграцію різних модулів банківської програми та досягнення цілей клієнта. Тестування системної інтеграції допомагає досягти цього завдання.

Банківський робочий процес тестування додатків

Типові етапи тестування банківських додатків показані в наведеному нижче робочому процесі. Ми будемо обговорювати кожен етап окремо.

Це модель Waterfall для тестування програми.

Тестування банківських додатків

# 1) Збір вимог

Вимоги Фаза збору передбачає документальне оформлення вимог як функціональних специфікацій, так і як випадків використання. Вимоги збираються відповідно до потреб клієнтів та документуються банківськими експертами або бізнес-аналітиком.

Збір вимог

Експерти беруть участь у написанні вимог з більш ніж однієї теми, оскільки саме банківське обслуговування має декілька субдоменів, і одна повноцінна банківська програма буде інтеграцією всіх цих доменів.

Наприклад, Банківська програма може мати окремі модулі для переказів, кредитних карток, звітів, кредитних рахунків, платежів за рахунками, торгівлі тощо.

# 2) Перегляд вимог

Результат збору вимог переглядається всіма зацікавленими сторонами, такими як інженери з контролю якості, лідери розвитку та аналітики рівних підприємств.

Перегляд вимог

Вони переконують, що не порушено ні існуючий робочий процес, ні нові робочі процеси. Усі вимоги перевірені та підтверджені. Подальші дії та перегляд вимог виконуються на їх основі.

# 3) Підготовка бізнес-сценарію

На цьому етапі інженери з контролю якості виводять бізнес-сценарії на основі документів про вимоги (специфікації функцій або випадки використання); Бізнес-сценарії складені таким чином, що охоплюються всі бізнес-вимоги. Бізнес-сценарії - це сценарії високого рівня без детальних кроків.

Крім того, ці бізнес-сценарії переглядаються бізнес-аналітиками, щоб переконатися, що всі бізнес-вимоги виконуються. Базовим спеціалістам легше переглядати сценарії високого рівня, а не детальні тестові випадки низького рівня.

Наприклад , клієнт, що відкриває фіксований депозит на цифровому банківському інтерфейсі, може бути бізнес-сценарієм. Подібним чином ми можемо мати різні бізнес-сценарії, пов’язані із створенням банківських рахунків у мережі, депозитами в Інтернеті, онлайн-переказами тощо

# 4) Функціональне тестування

На цьому етапі виконується функціональне тестування та виконуються звичайні дії з тестування програмного забезпечення, такі як:

Підготовка тестового кейсу: На цьому етапі тестові випадки походять із бізнес-сценаріїв, один бізнес-сценарій призводить до кількох позитивних і негативних тестових випадків. Як правило, на цьому етапі використовуються інструменти Microsoft Excel, директор тестування або Центр якості.

Огляд тестового кейсу: Відгуки інженерів з контролю якості

Тестовий кейс Виконання: Виконання тестових кейсів може бути як ручним, так і автоматичним за допомогою таких інструментів, як QC, QTP тощо.

Функціональне тестування банківської програми значно відрізняється від звичайного тестування програмного забезпечення. Оскільки ці програми працюють із грошима клієнта та конфіденційними фінансовими даними, їх потрібно ретельно перевірити. Жоден важливий бізнес-сценарій не повинен залишатися для висвітлення.

Також ресурс контролю якості, який тестує додаток, повинен мати базові знання про банківський домен.

# 5) Тестування бази даних

Банківський додаток передбачає складні транзакції, які виконуються як на рівні інтерфейсу користувача, так і на рівні бази даних, тому тестування бази даних так само важливо, як і функціональне тестування. База даних є складною і цілком окремим рівнем програми, тому її тестування проводиться спеціалістами баз даних. Він використовує такі методи, як:

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

Основна мета тестування баз даних полягає в тому, щоб:

  • Додаток може зберігати та отримувати дані з бази даних без втрати даних.
  • Завершені транзакції слід фіксувати, а перервані транзакції повертати назад, щоб уникнути невідповідності збережених даних.
  • Лише авторизовані програми та користувачі можуть отримати доступ до бази даних та таблиць, що лежать в основі.

Існує насамперед три способи тестування баз даних:

  • Структурні випробування
  • Функціональне тестування
  • Нефункціональне тестування

Структурні випробування

Він включає тестування об’єктів бази даних, таких як бази даних, схеми, таблиці, подання, тригери, засоби керування доступом тощо. Забезпечення синхронізації типів даних у таблицях із відповідними змінними в додатку. Перевірка даних та цілісності посилань у таблицях.

Наприклад, Поле суми в додатку повинно мати в таблиці тип даних десяткового / плаваючого.

- Для дотримання стандартів користувачам слід надавати контроль доступу через перегляди.

Функціональне тестування

Він включає тестування баз даних, які задовольняють потреби користувачів. Є два шляхи досягнення: тестування чорної скриньки та тестування білої скриньки.

Наприклад, Коли ми здійснюємо онлайн-переказ грошей, рахунок відправника повинен бути списаний, а рахунок одержувача повинен бути зарахований точно такою ж сумою. Якщо транзакція не вдається, цілі транзакції слід скасувати, а рахунок відправника не слід списати чи повернути назад.

Нефункціональне тестування

Він включає навантаження та стрес-тестування та оптимізацію продуктивності. Тестування навантаження допомагає визначити найбільшу кількість транзакцій, які можна виконувати одночасно, не впливаючи на продуктивність бази даних.

Наприклад, На основі даних навантажувального та стрес-тестування банківські програми можуть вирішити додати більше ресурсів до своїх додатків у піковий робочий час та зменшити ресурси в неробочий час. Це допомагає банку оптимально використовувати ресурси та економити гроші.

# 6) Тестування безпеки

Тестування на безпеку, як правило, є останнім етапом циклу тестування. Обов’язковою умовою початку тестування безпеки є завершення функціонального та нефункціонального тестування. Тестування безпеки є одним з основних етапів усього циклу тестування додатків, оскільки цей етап забезпечує відповідність програми федеральним та галузевим стандартам.

Через характер даних, які вони несуть, банківські програми є дуже чутливими і є основною метою для хакерів та шахрайської діяльності. Тестування безпеки гарантує, що програма не має такої веб-вразливості, яка може відкрити конфіденційні дані зловмиснику чи зловмиснику. Він також гарантує, що програма відповідає таким стандартам, як OWASP.

На цьому етапі головним завданням є сканування всього додатка, яке виконується за допомогою таких інструментів, як IBM AppScan або HP WebInspect (це найпопулярніші інструменти).

Після завершення сканування публікується звіт про сканування. У цьому звіті помилкові спрацьовування фільтруються, а решта вразливостей повідомляються команді розробників, щоб вони почали виправляти проблеми залежно від серйозності кожної проблеми.

На цьому етапі також проводиться тестування на проникнення, щоб виявити поширення помилок. Суворе тестування безпеки слід проводити на платформах, мережах та ОС.

Деякі інші Ручні інструменти для перевірки безпеки використовуються є Проксі-сервер Paros , Http Watch , Люкс відрижки , і Укріпити.

Основна мета тестування безпеки полягає у визначенні будь-яких уразливих місць, які може мати програма.

Тестування безпеки перевіряє програму на:

  • Будь-яка зовнішня атака або спроба зламати програму зі зловмисними намірами.
  • Будь-яка лазівка ​​в програмному додатку може бути використана, що спричинить втрату даних або грошові витрати.
  • Будь-яка уразливість у мережі, серверах та робочих станціях, на яких розміщено додаток.

Нижче наведено різні типи тестування безпеки:

Тестування вразливості: Автоматизована програма розробляється і виконується для перевірки різних вразливостей.

Сканування безпеки: Цей варіант обертається на вивченні мережевих та системних вразливостей, пропонує рішення для зменшення пов'язаного з ними ризику.

Випробування на проникнення: Цей варіант тестування безпеки імітує спробу злому вразливих місць та лазівки, які в іншому випадку могли б отримати доступ до бази даних або даних програми.

Аудит безпеки: Він включає аудит програми та пов'язаних з нею мереж на наявність будь-яких порушень безпеки.

Оцінка ризику: Цей варіант проводить аналіз для оцінки рівня ризику у випадку, коли вразливість або лазівка ​​використовується для зловмисних намірів. Такий ризик можна класифікувати на низький, середній та високий. Виходячи з рівня ризику, команда тестування рекомендує належні заходи для зменшення або запобігання ризику.

Етичний злом: Це виконує організація в своїх системах, щоб виявити прогалини, які можуть бути використані в її застосунку або мережі. Мета такого злому не полягає в крадіжці або заподіянні шкоди програмі чи мережі.

Оцінка постави: Це загальна оцінка, що включає перевірку безпеки, оцінку ризиків та етичні злому.

Введення SQL: SQL Injection можна використовувати для отримання доступу до бази даних сервера. Тестування проводиться для того, щоб переконатися, що код працює коректно, які виконують запити в базі даних на основі наступних даних користувача:

  • Кронштейни
  • Апострофи
  • Коми
  • Лапки

Інші етапи тестування програми BFSI

Окрім вищезазначених основних етапів, можуть бути задіяні різні етапи, такі як тестування інтеграції, тестування зручності використання, тестування прийнятності користувачами та тестування продуктивності.

Давайте коротко поговоримо і про ці етапи:

Інтеграційне тестування

Як ви знаєте, що в банківській програмі може бути кілька різних модулів, таких як перекази, платежі за рахунками, депозити тощо. І отже, існує багато розроблених компонентів. При інтеграційному тестуванні всі компоненти інтегровані разом та перевірені.

Тестування юзабіліті

Тестування юзабіліті

Банківська програма обслуговує найрізноманітніших клієнтів. Деяким із цих клієнтів може бракувати навичок та обізнаності, необхідних для виконання банківських завдань за допомогою програми.

Таким чином, банківська програма повинна бути перевірена на простий та ефективний дизайн, щоб зробити її придатною для різних груп клієнтів. Чим простіший і простіший у використанні інтерфейс, тим більша кількість клієнтів отримає вигоду від банківської програми.

Йдеться про вивчення рівня простоти, який мають бізнес-користувачі чи клієнти банку при використанні програми. Це тестування не проводиться розробником або тестувальником, а проводиться діловими користувачами.

Наприклад, Сьогодні всі користуються мобільними додатками. Додаток для банківських послуг повинен бути зручним для користувача та простим для розуміння та використання кінцевим користувачем.

Види тестування юзабіліті

Порівняльне тестування зручності використання: Це тестування на основі порівняння, де простота використання одного веб-сайту чи програми з іншим. Завданням такого тестування є забезпечення найкращого досвіду для користувачів.

Дослідницьке тестування зручності використання: Мета цього тестування - визначити, якими функціями повинна володіти нова програма або програмне забезпечення, щоб задовольнити вимоги клієнтів банку.

Нижче наведено переваги та недоліки тестування зручності використання

найкращий безкоштовний інструмент для ремонту Windows 7 -

Переваги:

  • Кінцеві користувачі програми, як правило, беруть участь у тестуванні, отже отримують відгуки з перших рук.
  • Замість того, щоб витрачати час на аналіз та обговорення особливостей, які продукт повинен мати чи ні, краще отримувати дані безпосередньо від кінцевого користувача.
  • Ми можемо заздалегідь виявити будь-які потенційні проблеми.

Недоліки:

  • Оскільки в тестуванні беруть участь декілька кінцевих користувачів, їх думки, якщо не точні, можуть вплинути на вимогу.
  • На стрічку кінцевих користувачів можуть вплинути.

Тестування продуктивності

Деякі періоди часу, такі як зарплата, кінець фінансового року, святкові сезони, можуть спричинити зміни або збільшити звичний трафік програми. Отже, слід провести ретельне тестування продуктивності, щоб клієнти не постраждали від збоїв в роботі.

Вагомим прикладом минулого, коли клієнти банків зазнали персональних наслідків через збої в роботі, - це відключення ІТ-технологій NatWest та RBS у понеділок, коли клієнти мали дебетову та кредитну картки, через які відхиляли транзакції в магазинах країни.

Тестування прийняття користувача

Це робиться шляхом залучення кінцевих користувачів, щоб переконатися, що додаток відповідає реальним сценаріям і буде прийнятий користувачами, якщо з’явиться в режимі оновлення.

У сьогоднішньому сценарії використовується більшість банківських проектів : Методології Agile / Scrum, RUP та Безперервна інтеграція, а також пакети інструментів, такі як Microsoft VSTS та Rational Tools.

Як ми вже згадували про RUP, RUP розшифровується як Rational Unified Process, що є ітеративною методологією розробки програмного забезпечення, запровадженою IBM, яка складається з чотирьох фаз, на яких здійснюється діяльність з розробки та тестування.

Чотири фази
i) Початок
ii) Співпраця
iii) Будівництво та
iv) Перехід

RUP широко використовує інструменти IBM Rational.

Зразки тестових випадків для банківської заяви

Тестові кейси для New Branch

  • Створіть нову гілку з дійсними та недійсними тестовими даними.
  • Створіть нову гілку без даних.
  • Створіть нову гілку з наявними даними гілки.
  • Перевірте параметри скидання та скасування.
  • Оновіть деталі гілок дійсними та недійсними даними тесту.
  • Оновіть дані про гілки існуючими даними тестування гілок
  • Перевірте, чи можна зберегти нову гілку.
  • Переконайтеся, що параметр скасування працює.
  • Перевірте видалення гілки з залежностями та без них.
  • Перевірте, чи працює параметр пошуку гілки.

Тестові випадки для нової ролі

  • Створіть нову роль із дійсними та недійсними тестовими даними.
  • Створіть нову роль без даних.
  • Переконайтеся, що нову роль можна створити з наявними тестовими даними.
  • Перевірте опис ролі та типи ролей.
  • Перевірте, чи працює опція скасування та скидання.
  • Перевірте процес видалення ролі з залежністю та без неї.
  • Перевірте посилання на сторінці деталей ролі.
  • Перевірте логін адміністратора без даних тесту.
  • Перевірте всі домашні посилання на роль адміністратора.
  • Переконайтеся, що адміністратор може змінити пароль із дійсними та недійсними тестовими даними.
  • Перевірте успішний вихід адміністратора.

Тестові кейси для Клієнта та Банкіра

  • Перевірте, чи всі посилання для відвідувачів та клієнтів працюють належним чином.
  • Перевірте логін клієнта за допомогою дійсних та недійсних даних тесту.
  • Підтвердьте логін клієнта без будь-яких даних.
  • Підтвердьте логін банкіра без будь-яких даних.
  • Перевірте логін банкіра дійсними або недійсними тестовими даними.
  • Переконайтеся, що клієнт або банкір можуть успішно вийти з системи.

Тестові кейси для нових користувачів

  • Перевірте, чи можна створити нового користувача з дійсними та недійсними тестовими даними.
  • Створіть нового користувача з наявними даними тестування гілок
  • Перевірте, чи параметр скасування та скидання працює належним чином.
  • Оновіть дані про користувача дійсними та недійсними тестовими даними.
  • Перевірте видалення нового користувача.
  • перевірити, чи можна перевірити нового користувача.
  • Перевірте обов’язкові вхідні параметри.
  • Перевірте додаткові вхідні параметри.
  • Перевірте, чи можна створити користувача без додаткових параметрів.

Тестові кейси для створення нового облікового запису

  • Створіть новий обліковий запис із дійсними та недійсними даними користувачів.
  • Перевірте, чи можна оновити дані користувача.
  • Перевірте, чи можна зберегти нового користувача.
  • Створіть новий обліковий запис із даними існуючого користувача.
  • Переконайтеся, що користувач може внести суму на новостворений рахунок (і оновити баланс).
  • Переконайтеся, що користувач може зняти суму з нового рахунку (після депозиту та оновлення балансу).
  • Що стосується заробітної плати, обліковий запис підтверджує назву компанії та інші дані надаються користувачем.
  • Перевірте, чи вказано номер первинного рахунку у випадку вторинного рахунку.
  • Перевірте дані користувача, надані у випадках поточного рахунку.
  • Перевірте надані докази для спільного рахунку у разі спільного рахунку.
  • Перевірте, чи вдається вести нульовий баланс на рахунку зарплати.
  • Перевірте, чи вдається підтримувати нульовий баланс чи мінімальний баланс на рахунку, який не має заробітної плати.
  • Переконайтеся, що новий користувач може успішно вийти з системи.

Тестові випадки для застосування мережевих банківських послуг

  • Перевірте, чи може користувач відкрити сайт банку.
  • Перевірте, чи всі посилання на сайті працюють.
  • Перевірте, чи зможе користувач створити новий обліковий запис.
  • Перевірте, чи зможе користувач увійти за допомогою дійсного та недійсного імені користувача та пароля.
  • Переконайтеся, що під час входу в систему не вказано жодне ім’я користувача чи пароль, користувачеві не слід дозволяти входити в систему та відображається попереджувальне повідомлення.
  • Перевірте, чи дозволено користувачеві змінювати пароль.
  • Якщо введено невірний користувач або пароль, відображається відповідне повідомлення про помилку.
  • Користувачам з недійсним паролем не можна дозволяти входити.
  • Переконайтеся, що після неодноразових спроб входу з неправильним паролем користувачеві повинно бути показано повідомлення про помилку та заблоковано.
  • Перевірте, чи може користувач виконувати деякі основні операції.
  • Переконайтеся, що користувач може додати бенефіціара з дійсними та недійсними даними.
  • Перевірте, чи може користувач видалити бенефіціара.
  • Переконайтеся, що користувач може здійснювати транзакції з нещодавно доданим бенефіціаром.
  • Після транзакції перевірте, чи оновлені облікові записи користувача та бенефіціара.
  • Перевірте, чи зможе користувач ввести суму в десятковому числі.
  • Переконайтеся, що користувач не може ввести від’ємні числа в поле суми.
  • Перевірте, чи дозволено користувачеві робити транзакції з мінімальним балансом або без нього.
  • Переконайтеся, що користувач може зробити новий RD.
  • Переконайтеся, що відображається належне повідомлення у випадку транзакції, здійсненої з недостатнім балансом.
  • Перевірте, чи запитується у користувача підтвердження до того, як буде здійснено будь-яку транзакцію.
  • Перевірте, чи надається квитанція про підтвердження кожної успішної транзакції.
  • Переконайтеся, що користувач може переказувати гроші на кілька рахунків.
  • перевірити, чи може користувач скасувати транзакцію.
  • Переконайтеся, що деталі рахунку відображають також здійснені фінансові операції.
  • Переконайтеся, що функція тайм-ауту реалізована.
  • переконайтеся, що у випадку таймауту сеансу користувач повинен увійти ще раз.
  • переконайтеся, що належний тайм-аут сеансу виконано на випадок бездіяльності.
  • переконайтеся, що під час транзакції користувач переведений у захищений режим.
  • Перевірте, чи може користувач успішно вийти з системи.
  • Перевірте параметри пошуку та скидання.

Висновок

У цій статті ми обговорювали наскільки складною може бути банківська програма і що таке типові етапи, що беруть участь у тестуванні заявки . Окрім цього, ми також обговорили сучасні тенденції, за якими стежать ІТ-галузі, включаючи методології та інструменти розробки програмного забезпечення.

Не соромтеся поділитися своїм досвідом або запитаннями з цієї теми!

Рекомендована література

^