Проект тестування банківських доменних застосунків
Томас Гамільтон
⚡ Розумний підсумок
Тестування банківських додатків перевіряє функціональність, продуктивність та безпеку фінансового програмного забезпечення, яке обробляє конфіденційні транзакції. У цьому навчальному посібнику пояснюються знання предметної області, характеристики банківських додатків, фази тестування, зразки тестових випадків та ключові стратегії зменшення ризиків, унікальних для сектора BFSI.
Тестування банківського домену
Тестування банківського домену – це процес тестування програмного забезпечення банківського застосунку на предмет функціональності, продуктивності та безпеки. Головною метою тестування банківського застосунку є забезпечення безперебійної роботи всіх дій та функцій банківського програмного забезпечення без помилок, а також його захисту.
Сектор BFSI (банківська справа, фінансові послуги та страхування) є найбільшим споживачем ІТ-послуг. Банківські програми безпосередньо обробляють конфіденційні фінансові дані, тому обов'язково потрібно, щоб кожна дія, що виконується банківським програмним забезпеченням, працювала надійно та без помилок. Банківське програмне забезпечення виконує такі функції, як переказ та внесення коштів, запити балансу, історія транзакцій та зняття коштів. Тестування банківської програми гарантує, що ці дії не лише виконуються правильно, але й залишаються захищеними від хакерів.
Безкоштовно приєднуйтеся до нашого проекту тестування банківських послуг у прямому ефірі
Що таке домен у тестуванні?
Домен у тестуванні стосується галузі, для якої створюється проект тестування програмного забезпечення. Цей термін часто використовується під час обговорення проектів та розробки програмного забезпечення. Прикладами є сфера страхування, банківська справа, роздрібна торгівля та телекомунікації.
Під час розробкиping Для будь-якого проекту, пов'язаного з певною предметною областю, зазвичай звертаються за допомогою до експерта в предметній області. Експерти в предметній області є майстрами в своїй галузі та знають застосування досконало.
Чому знання домену важливі?
Знання предметної області є важливим для тестування будь-якого програмного продукту, оскільки воно безпосередньо покращує покриття тестами, виявлення дефектів та довіру зацікавлених сторін. Тестувальник, який розуміє банківські робочі процеси, може виявити крайні випадки, які тестувальник, який не є спеціалістом з предметної області, повністю пропускає.
Знання банківської сфери – Вступ
Концепції банківської сфери є широкими та загалом поділяються на два сектори:
- Традиційний банківський сектор
- Банківський сектор, що базується на послугах
У таблиці нижче перелічені послуги, які охоплюють ці два підсектори.
| Сектор | Послуги включені |
|---|---|
| Традиційний банківський сектор | Базовий банкінг, Корпоративний банкінг, Роздрібний банкінг |
| Банківський сектор, що базується на послугах | Базові послуги, Корпоративний банкінг, Роздрібний банкінг, Кредитування, Торговельне фінансування, Приватний банкінг, Споживче фінансування, Ісламський банкінг, Канали доставки клієнтам / Фронтенд-доставка |
Залежно від обсягу вашого проекту, вам може знадобитися протестувати одну або всі перераховані вище послуги. Перш ніж розпочати тестування, переконайтеся, що у вас достатньо знань про послугу, що тестується.
Характеристики банківської програми
Перш ніж розпочати тестування, важливо врахувати стандартні функції, які очікуються від будь-якої банківської програми, щоб ви могли спрямувати свої тестові зусилля на досягнення цих характеристик. Стандартна банківська програма повинна відповідати таким очікуванням:
- Підтримка тисяч одночасних сеансів користувачів.
- Інтеграція з багатьма іншими програмами, такими як торгові рахунки, комунальні послуги для оплати рахунків та кредитні картки.
- Обробляйте швидкі та безпечні транзакції.
- Включіть масивну систему зберігання.
- Забезпечити високий рівень аудиторських можливостей для вирішення проблем клієнтів.
- Керувати складними бізнес-процесами.
- Підтримка користувачів на різних платформах (Mac, Linux, Unix, Windows).
- Підтримка користувачів з різних місць розташування.
- Підтримка багатомовних користувачів.
- Підтримка користувачів різних платіжних систем (VISA, AMEX, MasterCard).
- Підтримка кількох секторів послуг (кредити, роздрібний банкінг тощо).
- Забезпечити надійний механізм управління стихійними лихами.
Типи банківських застосунків для тестування
Перед картоюping На етапах тестування корисно знати, які банківські програми зазвичай входять до сфери застосування:
- Базова банківська система (CBS): центральний механізм для депозитів, позик та рахунків.
- Інтернет-банкінг: веб-портал для переказів та оплати рахунків, орієнтований на клієнта.
- Мобільний банкінг: iOS і Android додатки з біометрією та сповіщеннями.
- Програмне забезпечення для банкоматів та кіосків: вбудоване програмне забезпечення на банкоматах.
- Платіжні шлюзи: обробники транзакцій карток, UPI та гаманців.
- Модулі позик та казначейства: додатки для бек-офісу з питань кредитування та обміну валют.
Етапи тестування банківських програм
Після того, як відомі сфери застосування, тестування зазвичай проходить через такі фази.
- Аналіз вимог: Виконується бізнес-аналітиком, який збирає та документує вимоги для конкретної банківської програми.
- Вимога Revось: Аналітики якості, бізнес-аналітики та керівники відділів розробки переглядають документ з вимогами та перевіряють його, щоб переконатися, що він не порушує жодного існуючого робочого процесу.
- Документація бізнес-вимог: Аналітики якості готують документи з бізнес-вимог, які охоплюють усі перевірені вимоги.
- Тестування бази даних: Найважливіша частина тестування банківських застосунків. Вона перевіряє цілісність даних, завантаження даних, міграцію даних, збережені процедури, валідацію функцій та бізнес-правила.
- Інтеграційне тестування: під Інтеграційне тестування, усі розроблені компоненти інтегровані та валідовані разом.
- Функціональне тестування: Стандартні тестові дії, такі як Тестовий випадок Підготовка, перевірка тестового випадку та виконання виконуються на цьому етапі.
- Тестування безпеки: Забезпечує відсутність недоліків безпеки програмного забезпечення. Команда контролю якості повинна враховувати як негативні, так і позитивні сценарії спроби проникнення в систему та повідомляти про вразливості, перш ніж будь-яка неавторизована сторона їх виявить. Банки також повинні забезпечувати багаторівневу перевірку доступу, таку як одноразові паролі. Інструменти автоматизації, які зазвичай використовуються для Тестування безпеки включати IBM AppScan та HP WebInspect, водночас Ручне тестування часто покладається на Proxy Sniffer, Paros Proxy та HTTP Watch.
- Тестування на зручність: Забезпечує таку ж легкість використання системою для користувачів з інвалідністю, як і для будь-якого іншого користувача, наприклад, банкомати оснащені аудіоінструкціями та клавіатурами Брайля для забезпечення доступності.
- Перевірка прийнятності користувача: Заключний етап, який виконують кінцеві користувачі, щоб підтвердити, що програма поводиться правильно в реальних сценаріях.
Зразок тестового прикладу для програми входу в систему Net Banking
Безпека є надзвичайно важливою для будь-якої банківської програми. Під час підготовки тестів команда контролю якості повинна враховувати як негативні, так і позитивні сценарії, щоб дослідити систему та повідомити про вразливості, перш ніж будь-яка неавторизована особа їх виявить. Це означає написання не лише негативних тестових випадків, а й деструктивних тестів.
У таблиці нижче наведено загальні тестові випадки для банківської програми.
| Область | Зразки тестових випадків |
|---|---|
| Адміністратор | Перевірка входу адміністратора з дійсними та недійсними даними; вхід адміністратора без даних; усі посилання на головну сторінку адміністратора; зміна пароля адміністратора з дійсними, недійсними та існуючими даними; вихід адміністратора. |
| Нова філія | Створити нову гілку з дійсними, недійсними та існуючими даними; створити без даних; скинути та скасувати; оновити гілку з дійсними, недійсними та існуючими даними; скасувати; видалити гілку з залежностями та без них; пошук у гілках. |
| Нова роль | Створити нову роль з дійсними, недійсними, існуючими даними; створити без даних; перевірити опис та типи ролі; скасувати та скинути налаштування; видалити роль із залежностями та без них; перевірити посилання на сторінці деталей ролі. |
| Клієнти та відвідувачі | Перевірте всі посилання відвідувачів та клієнтів; вхід клієнта з дійсними, недійсними або відсутніми даними; вхід банкіра з дійсними, недійсними або відсутніми даними. |
| Нові користувачі | Створити нового користувача з дійсними, недійсними та існуючими даними гілки; створити без даних; скасувати та скинути; оновити користувача з дійсними, недійсними та існуючими даними; скасувати; видалити користувача. |
Проблеми тестування банківської сфери та їх пом'якшення
Навіть за наявності надійних фаз тестування та шаблонів, тестувальники стикаються з кількома повторюваними проблемами в банківських проектах. Наведені нижче заходи пом'якшення довели свою ефективність у реальних проектах.
| Виклики | Пом'якшення |
|---|---|
| Отримати доступ до виробничих даних та відтворити їх як тестові дані складно. | Забезпечте відповідність тестових даних вимогам нормативних актів та збережіть конфіденційність за допомогою маскування даних, синтетичних тестових даних та тестування системної інтеграції. |
| Міграція зі старої банківської системи до нової, включаючи процедури, процедури та завантаження даних, є найбільшим викликом. | Виконайте тестування міграції даних та запустіть регресійні тести як на старих, так і на нових системах, порівнюючи результати, доки вони не збігатимуться. |
| Вимоги можуть бути погано задокументовані, що залишає функціональні прогалини. Нефункціональні вимоги часто недокументовані, тому тестувальники не знають, чи варто їх тестувати. | Тестери повинні брати участь, починаючи з етапу аналізу вимог, та активно переглядати бізнес-вимоги. |
| Перевірка того, що система відповідає бажаним політикам і процедурам. | Виконайте тестування відповідності та регуляторної політики. |
| Розширюються обсяг та терміни, оскільки банківські додатки інтегруються з Інтернетом та Mobile банківська справа. | Виділіть достатньо часу в плані для інтеграційного тестування, коли банківський застосунок має багато зовнішніх інтерфейсів. |
