how test banking domain applications
Пълно ръководство за тестване на банково приложение: Процес и съвети за тестване на BFSI (банково дело, финансови услуги и застраховане)
Банковите приложения са едно от най-сложните приложения в съвременната индустрия за разработка и тестване на софтуер.
Какво прави приложенията за банкиране толкова сложни? Какъв подход трябва да се следва, за да се тестват сложните работни процеси, свързани с банковите приложения?
В тази статия ще подчертаем различни етапи и техники, участващи в тестването на банкови приложения.
Какво ще научите:
- Как да тествате банкови приложения?
- Значение на тестването на банковото приложение
- Работен поток за тестване на приложения за банкиране
- Примерни тестови случаи за банково приложение
- Заключение
Как да тествате банкови приложения?
Различни функции, изпълнявани от банковите приложения, са:
Нека първо разберем характеристиките на банковото приложение:
- Многостепенна функционалност за поддържане на хиляди едновременни потребителски сесии
- Мащабна интеграция: Обикновено банковото приложение се интегрира с много други приложения, като например помощна програма за плащане на сметки и търговски сметки
- Сложни бизнес процеси
- Обработка в реално време и партида
- Високият процент на транзакции в секунди
- Сигурни транзакции
- Силна секция за отчитане, за да следите ежедневните транзакции
- Силен одит за отстраняване на проблеми с клиенти
- Масивна система за съхранение
- Управление при бедствия / възстановяване.
Гореизброените десет точки са най-важните характеристики на банковото приложение.
Банковите приложения имат множество нива, участващи в извършването на операция.
Например , да се Банковото приложение може да има:
- Уеб сървър за взаимодействие с крайни потребители чрез браузър
- Средно ниво за проверка на входа и изхода за уеб сървъра
- DataBase за съхраняване на данни и процедури
- Процесор за транзакции, който може да бъде с голям капацитет Mainframe или друга наследствена система за извършване на трилиони транзакции в секунда.
Ако говорим за тестване на банкови приложения, това изисква Методология за тестване от край до край, включваща множество техники за тестване на софтуера, за да се гарантира:
- Общо покритие на всички банкови работни процеси и бизнес изисквания
- Функционалният аспект на приложението
- Аспектът на сигурност на приложението
- Целостта на данните
- Съвпадение
- Потребителски опит
Какво прави приложенията за банкиране толкова сложни?
- Банковият софтуер се занимава главно с поверителни финансови данни, така че работата на софтуера трябва да бъде без грешки и сигурна.
- Разработчиците предпочитат сложен дизайн за разработване на тези приложения, за да гарантират, че приложението работи по желания сигурен начин.
- Банкирането е постоянно променящ се свят. Днес банковото обслужване се предоставя на клиентите чрез различни канали като тухлени клонове, банкомати, онлайн банкиране и обслужване на клиенти.
- С появата на технологиите много портфейли наводниха пазарите, които се свързват с банковите системи за финансови транзакции.
- Очаква се банковото дело също да работи и работи 24 X 7 с висока производителност. Не може да се позволи софтуерни надстройки, незабавни поправки и др. Да повлияят на тази наличност.
- Банковият свят също е силно повлиян от постоянните промени, въведени от правителството под формата на банкови разпоредби. Всички промени в данъчната структура засягат и банковата система.
- Банковата система също трябва да бъде актуална, що се отнася до новите технологии. Анализът на данни като обработка на големи данни и извличане на инстинкти от големи данни с помощта на Data Science нараства сцеплението в банковия свят.
Горепосочените точки правят банковата система сложна за разработчиците да създават около нея софтуерно приложение.
Значение на тестването на банковото приложение
- Тестването на приложението за банкиране гарантира, че всички дейности не само се изпълняват добре, но и остават защитени и защитени.
- Банковият софтуер е сложен с хиляди зависимости, процесът на тестване изисква повече време, ресурси и непрекъснато наблюдение.
- Тъй като тук са включени финанси, трябва да се спазват стриктно указанията. И тестерите, и разработчиците трябва да имат добри познания за домейна.
- Най-важното е, че трябва да се гарантира, че законите и разпоредбите се прилагат правилно при финансовите транзакции. Това може да се гарантира само с тестване.
- Също така е важно да се гарантира, че приложението и инфраструктурата, на която е разположено приложението, могат да се справят с товара, особено по време на пиковите работни часове, без да причиняват смущения. Това може да се осигури чрез извършване на тестване на производителността.
- В днешния цифров свят единственото, което засяга всички, е сигурността. Банковите приложения и финансовите транзакции, които се извършват в него, трябва да бъдат защитени от всеки опит за проникване. Това може да се осигури чрез извършване на тестове за сигурност. Тестването на сигурността помага за налагане на индустриалните стандарти за осигуряване на финансови транзакции.
- Също така е важно да се гарантира, че различните модули на банковото приложение и са интегрирани правилно и да се постигне целта на клиента. Тестването на системна интеграция помага за постигането на тази задача.
Работен поток за тестване на приложения за банкиране
Типични етапи, участващи в тестване на банкови приложения са показани в работния процес по-долу. Ще обсъждаме всеки етап поотделно.
Това е модел на водопад за тестване на приложение.
# 1) Събиране на изисквания
Изискване Фаза на събиране включва документиране на изискванията или като функционални спецификации, или като случаи на употреба. Изискванията се събират според нуждите на клиентите и се документират от банкови експерти или бизнес анализатори.
Експертите участват в писането на изисквания по повече от един предмет, тъй като самото банкиране има множество поддомейни и едно пълноценно банково приложение ще бъде интеграцията на всички тези домейни.
Например, Банковото приложение може да има отделни модули за преводи, кредитни карти, отчети, сметки за заем, плащания по сметки, търговия и др.
# 2) Преглед на изискванията
Резултатът от събирането на изисквания се преглежда от всички заинтересовани страни като QA инженери, разработчици и партньорски бизнес анализатори.
Те проверяват, че нито съществуващите работни потоци, нито новите работни процеси са нарушени. Всички изисквания са проверени и валидирани. Последващи действия и ревизии на документи с изисквания се извършват въз основа на същите.
# 3) Подготовка на бизнес сценарий
На този етап QA инженерите извличат бизнес сценарии от документите за изисквания (спецификации за функции или случаи на употреба); Бизнес сценариите са извлечени по такъв начин, че да бъдат обхванати всички бизнес изисквания. Бизнес сценариите са сценарии на високо ниво без никакви подробни стъпки.
Освен това тези бизнес сценарии се преглеждат от бизнес анализаторите, за да се гарантира, че са спазени всички бизнес изисквания. По-лесно е за BA да преглеждат сценарии от високо ниво, вместо да преглеждат подробни тестови случаи на ниско ниво.
Например , клиент, отварящ фиксиран депозит в интерфейса за цифрово банкиране, може да бъде бизнес сценарий. По същия начин можем да имаме различни бизнес сценарии, свързани със създаването на нетна банкова сметка, онлайн депозити, онлайн преводи и т.н.
# 4) Функционално тестване
На този етап се извършва функционално тестване и се извършват обичайните дейности за тестване на софтуер като:
Подготовка на тестовия случай: На този етап тестовите случаи се извличат от бизнес сценарии, един бизнес сценарий води до няколко положителни и отрицателни тестови случаи. Като цяло инструментите, използвани на този етап, са Microsoft Excel, Директор на тестове или Център за качество.
Преглед на тестовия случай: Отзиви от партньори QA инженери
Тестов случай Екзекуция: Изпълнението на тестови случаи може да бъде ръчно или автоматично, включващо инструменти като QC, QTP и др.
Функционалното тестване на банково приложение е доста различно от обикновеното тестване на софтуер. Тъй като тези приложения работят с пари на клиента и чувствителни финансови данни, те трябва да бъдат тествани щателно. Не трябва да се оставя нито един важен бизнес сценарий, който да бъде покрит.
Също така, QA ресурсът, който тества приложението, трябва да притежава основните познания за банковия домейн.
# 5) Тестване на база данни
Приложението за банкиране включва сложна транзакция, която се извършва както на ниво потребителски интерфейс, така и на ниво база данни, следователно тестването на база данни е също толкова важно, колкото и функционалното тестване. Базата данни е сложна и изцяло отделен слой в приложението и по този начин нейното тестване се извършва от специалисти по бази данни. Той използва техники като:
- Зареждане на данни
- Миграция на база данни
- Тестване на DB схема и типове данни
- Тестване на правила
- Тестване на съхранени процедури и функции
- Тестване на задействания
- Целостта на данните
Основната цел на тестването на базата данни е да гарантира, че:
- Приложението може да съхранява и извлича данни от базата данни без загуба на данни.
- Завършените транзакции трябва да бъдат ангажирани и прекратените транзакции се връщат обратно, за да се избегне несъответствие в съхранените данни.
- Само оторизирани приложения и потребители имат достъп до базата данни и основните таблици.
Има основно три начина за тестване на база данни:
- Структурно изпитване
- Функционално тестване
- Нефункционално тестване
Структурно изпитване
Включва тестване на обекти на базата данни като бази данни, схема, таблици, изгледи, задействания, контроли за достъп и др. Гарантиране, че типовете данни в таблици са синхронизирани със съответните променливи в приложението. Проверка на данни и референтна цялост в таблиците.
Например, Полето за сума в приложението трябва да съдържа тип данни с десетична / плаваща стойност в таблицата.
- За да се съобразят със стандартите, потребителите трябва да получат контрол на достъпа чрез изгледи.
Функционално тестване
Включва тестване на базите данни, които отговарят на изискванията на потребителите. Има два начина за постигане: тестване на черна кутия и тестване на бяла кутия.
Например, Когато извършваме онлайн паричен превод, сметката на подателя трябва да бъде дебитирана и сметката на получателя трябва да бъде кредитирана с точно същата сума. Ако транзакцията се провали, тогава цели транзакции трябва да бъдат върнати обратно и акаунтът на подателя не трябва да бъде дебитиран или кредитиран обратно.
Нефункционално тестване
Включва тестване на натоварване и стрес и оптимизиране на работата. Тестването на натоварването помага при идентифицирането на най-голям брой транзакции, които могат да се извършват едновременно, без това да повлияе на производителността на базата данни.
Например, Въз основа на данните от натоварването и стрес тестването банковите приложения могат да решат да добавят повече ресурси към приложението си в пиковите работни часове и да намалят ресурсите по време на извънработно време. Това помага на банката да използва оптимално ресурсите и да спести пари.
# 6) Тестване на сигурността
Тестването на сигурността обикновено е последният етап от цикъла на тестване. Предпоставка за започване на тестване за сигурност е завършването на функционално и нефункционално тестване. Тестването на сигурността е един от основните етапи в целия цикъл на тестване на приложенията, тъй като този етап гарантира, че приложението отговаря на федералните и индустриалните стандарти.
Поради естеството на данните, които носят, банковите приложения са много чувствителни и са основна цел за хакери и измамни дейности. Тестването на сигурността гарантира, че приложението няма такава уеб уязвимост, която може да изложи чувствителни данни на нарушител или нападател. Той също така гарантира, че приложението отговаря на стандарти като OWASP.
На този етап основната задача е сканирането на цялото приложение, което се извършва с помощта на инструменти като IBM AppScan или HP WebInspect (това са най-популярните инструменти).
След като сканирането приключи, отчетът за сканиране се публикува. В този доклад фалшивите положителни резултати се филтрират, а останалите уязвимости се докладват на екипа за разработка, за да започнат да отстраняват проблемите в зависимост от тежестта на всеки проблем.
Тестът за проникване също се прави на тази стъпка, за да се разкрие разпространението на грешки. Строги тестове за сигурност трябва да се извършват на различни платформи, мрежи и операционни системи.
Някой друг Ръчни инструменти за тестване на сигурността използвани са Прокси Paros , Http Гледайте , Супер суит , и Укрепване.
Основната цел на тестването на сигурността е да определи всички уязвимости, които софтуерното приложение може да има.
Тестът за сигурност тества приложението срещу:
- Всяка външна атака или опит за хакване на приложението със злонамерено намерение.
- Всяка вратичка в софтуерното приложение може да бъде използвана, причинявайки данни или парична загуба.
- Всяка уязвимост в мрежата, сървърите и работните станции, която хоства приложението.
Следват различните видове тестване на сигурността:
Тестване на уязвимост: Разработва се и се изпълнява автоматизирана програма за проверка на различни уязвимости.
Сканиране за сигурност: Този вариант се върти около проучване на уязвимости на мрежата и системата, предоставя решения за намаляване на свързания риск.
Изпитване за проникване: Този вариант на тестване на сигурността имитира опит за хакерство за улавяне на уязвимости и вратички, които иначе биха могли да получат достъп до базата данни или данните на приложението.
Одит на сигурността: Включва одит на приложението и свързаните с него мрежи за пропуски в сигурността.
Оценка на риска: Този вариант прави анализ за оценка на нивото на риска в случай, когато уязвимост или вратичка се използва за злонамерено намерение. Такъв риск може да бъде категоризиран като нисък, среден и висок. Въз основа на нивото на риска, тестващият екип препоръчва правилни мерки за намаляване или предотвратяване на риска.
Етично хакване: Това се извършва от организация в нейните системи, за да идентифицира вратички, които могат да бъдат използвани в нейното приложение или мрежа. Целта на този вид хакерство не е да открадне или да причини щети на приложението или мрежата.
Оценка на позата: Това е оценка на чадъра, включваща сканиране за сигурност, оценки на риска и етично хакване.
SQL инжекция: SQL Injection може да се използва за получаване на достъп до сървърната база данни. Тестването се извършва, за да се гарантира, че кодът работи правилно, които изпълняват заявки в базата данни въз основа на следните данни от потребителя:
- Скоби
- Апострофи
- Запетаи
- Кавички
Други етапи при тестване на приложението BFSI
Освен горните основни етапи, може да има различни етапи, като например тестване на интеграция, тестване на използваемост, тестване за приемане от потребителя и тестване на производителността.
Нека поговорим накратко и за тези етапи:
Интеграционно тестване
Както знаете, че в банковото приложение може да има няколко различни модула като преводи, плащания на сметки, депозити и т.н. И по този начин има много разработени компоненти. При интеграционното тестване всички компоненти са интегрирани заедно и валидирани.
Тестване на използваемостта
Банковото приложение обслужва голямо разнообразие от клиенти. На някои от тези клиенти може да им липсват уменията и осведомеността, необходими за изпълнение на банковите задачи в приложението.
По този начин банковото приложение трябва да бъде тествано за опростен и ефективен дизайн, за да стане годно за използване в различни групи клиенти. Колкото по-опростен и лесен за използване интерфейс е, толкова по-голям брой клиенти ще се възползват от банковото приложение.
Става въпрос за изследване на нивото на лекота, което бизнес потребителите или банковите клиенти имат при използването на приложението. Това тестване не се извършва от разработчика или тестера, а се извършва от бизнес потребителите.
Например, В днешно време всички използват мобилни приложения. Приложението за банкиране трябва да бъде удобно за потребителя и лесно за разбиране и използване от крайния потребител.
Видове тестове за използваемост
Сравнително тестване на използваемостта: Това е базирано на сравнение тестване, при което лекотата на използваемост на един уебсайт или приложение с друг. Целта на такова тестване е да осигури най-доброто потребителско изживяване.
Изследователско тестване на използваемостта: Целта на това тестване е да идентифицира какви функции трябва да притежава новото приложение или софтуер, за да отговори на изискванията на клиентите на банката.
Следват предимства и недостатъци на тестването на използваемост
как да гледате аниме онлайн безплатно
Предимства:
- Крайните потребители на приложението обикновено участват в тестването, поради което се получава обратна връзка от първа ръка.
- Вместо да отделяте време за анализ и обсъждане на характеристика, която даден продукт трябва да има или не, по-добре е да получавате входящите данни от крайния потребител директно.
- Предварително можем да засечем всички потенциални проблеми.
Недостатъци:
- Тъй като в тестването участват множество крайни потребители, техните мнения, ако не са точни, могат да повлияят на изискването.
- Емисията от крайните потребители може да бъде повлияна.
Тестване на производителността
Определени периоди от време като заплата, край на финансовата година, празнични сезони могат да доведат до промяна или скок в обичайния трафик в приложението. Следователно трябва да се направи задълбочено тестване на производителността, така че клиентите да не бъдат засегнати от неуспехи в изпълнението.
Значителен пример от миналото, при който банковите клиенти са били лично засегнати поради неизправности в работата, е прекъсването на работата на ИТ на NatWest и RBS в понеделник, при което клиентите са имали дебитни и кредитни карти с отказани транзакции в магазини в страната.
Тест за приемане от потребителя
Това се прави чрез включване на крайните потребители, за да се гарантира, че приложението отговаря на реалните сценарии и ще бъде прието от потребителите, ако бъде пуснато в действие.
В днешния сценарий повечето банкови проекти използват : Agile / Scrum, RUP и Continuous Integration методологии, както и пакети Инструменти като VSTS и Rational Tools на Microsoft.
Както споменахме за RUP по-горе, RUP означава Rational Unified Process, което е итеративна методология за разработване на софтуер, въведена от IBM, която се състои от четири фази, в които се извършват дейности по разработка и тестване.
Четири фази са
i) Начало
ii) Сътрудничество
iii) Строителство и
iv) Преход
RUP широко включва инструменти на IBM Rational.
Примерни тестови случаи за банково приложение
Тестови случаи за New Branch
- Създайте нов клон с валидни и невалидни тестови данни.
- Създайте нов клон без данни.
- Създайте нов клон със съществуващи данни за клонове.
- Проверете опциите за нулиране и анулиране.
- Актуализирайте подробностите за клона с валидни и невалидни данни от теста.
- Актуализирайте подробностите за клона със съществуващи данни за тест на клонове
- Проверете дали новият клон може да бъде запазен.
- Проверете дали опцията за анулиране работи.
- Проверете изтриването на клона със и без зависимости.
- Проверете дали опцията за търсене на клон работи.
Тестови случаи за нова роля
- Създайте нова роля с валидни и невалидни тестови данни.
- Създайте нова роля без данни.
- Проверете дали може да се създаде нова роля със съществуващите данни от теста.
- Проверете описанието на ролите и типовете роли.
- Проверете дали опцията за анулиране и нулиране работи.
- Проверете процеса на изтриване на ролята със и без зависимост.
- Проверете връзките на страницата с подробности за ролята.
- Проверете влизането на администратора без тестови данни.
- Проверете всички начални връзки за ролята на администратор.
- Уверете се, че администраторът може да промени паролата с валидни и невалидни тестови данни.
- Проверете успешно излизането на администратора.
Тестови случаи за клиенти и банкери
- Проверете дали всички връзки за посетители и клиенти работят правилно.
- Проверете влизането на клиента с валидни и невалидни тестови данни.
- Проверете потребителския вход без никакви данни.
- Проверете влизането на банкера без никакви данни.
- Проверете влизането на банкера с валидни или невалидни тестови данни.
- Проверете дали клиентът или банкерът може да излезе успешно.
Тестови случаи за нови потребители
- Проверете дали новият потребител може да бъде създаден с валидни и невалидни тестови данни.
- Създайте нов потребител със съществуващи данни за тест на клонове
- Проверете дали опцията за анулиране и нулиране работи правилно.
- Актуализирайте потребителските подробности с валидни и невалидни тестови данни.
- Проверете изтриването на новия потребител.
- проверете дали новият потребител може да бъде проверен.
- Проверете задължителните входни параметри.
- Проверете незадължителните входни параметри.
- Проверете дали потребител може да бъде създаден без незадължителни параметри.
Тестови случаи за създаване на нов акаунт
- Създайте нов акаунт с валидни и невалидни потребителски данни.
- Проверете дали данните за потребителя могат да бъдат актуализирани.
- Проверете дали може да бъде запазен нов потребител.
- Създайте нов акаунт със съществуващите данни на потребителя.
- Проверете дали потребителят може да депозира сумата в новосъздадения акаунт (и да актуализира салдото).
- Уверете се, че потребителят може да тегли сума от новата сметка (след депозит и актуализиране на салдото).
- В случай на заплата, акаунтът потвърждава името на компанията и други данни се предоставят от потребителя.
- Проверете дали номерът на основния акаунт е предоставен в случай на вторичен акаунт.
- Проверете данните за потребителя, предоставени в случаите на текущия акаунт.
- Проверете предоставените доказателства за съвместна сметка в случай на съвместна сметка.
- Проверете дали можете да поддържате нулев баланс в сметката за заплата.
- Проверете дали можете да поддържате нулево салдо или минимално салдо за сметката без заплата.
- Проверете дали новият потребител може да излезе успешно.
Тестови случаи за приложението за нетно банкиране
- Проверете дали потребителят може да отвори сайта на банката.
- Проверете дали всички връзки в сайта работят.
- Проверете дали потребителят е в състояние да създаде нов акаунт.
- Проверете дали потребителят може да влезе с валидни и невалидни потребителско име и парола.
- Проверете дали някое от потребителското име или паролата е празно по време на влизане, потребителят не трябва да има право да влиза и се показва предупредително съобщение.
- Проверете дали потребителят има право да промени паролата.
- Ако е въведен невалиден потребител или парола, се показва правилно съобщение за грешка.
- Потребителите с невалидна парола не трябва да имат право да влизат.
- Уверете се, че след многократни опити за влизане с неправилна парола, на потребителя трябва да се покаже съобщение за грешка и да се блокира.
- Проверете дали потребителят е в състояние да извърши някои основни транзакции.
- Проверете дали потребителят може да добави бенефициент с валидни и невалидни данни.
- Проверете дали потребителят може да изтрие бенефициента.
- Проверете дали потребителят е в състояние да извършва транзакции с новодобавения бенефициент.
- След транзакцията проверете дали акаунтите на потребителя и бенефициента са актуализирани.
- Проверете дали потребителят е в състояние да въведе сумата в десетично число.
- Проверете дали потребителят не може да въведе отрицателни числа в полето за сума.
- Проверете дали на потребителя е разрешено да извършва транзакции със или без минимално салдо.
- Проверете дали потребителят може да направи нов RD.
- Проверете дали правилното съобщение се показва в случай на транзакция, извършена с недостатъчно салдо.
- Проверете дали потребителят е помолен за потвърждение, преди да бъде извършена транзакция.
- Проверете дали за всяка успешна транзакция е предоставена разписка за потвърждение.
- Проверете дали потребителят е в състояние да прехвърля пари към множество сметки.
- проверете дали потребителят може да анулира транзакцията.
- Уверете се, че данните за сметката отразяват и извършени финансови транзакции.
- Проверете дали е внедрена функцията за изчакване.
- проверете дали в случай на изчакване на сесията потребителят трябва да влезе отново.
- проверете дали правилното време за изчакване на сесията е направено в случай на бездействие.
- проверете дали при извършване на транзакцията потребителят е изведен в защитен режим.
- Проверете дали потребителят може да излезе успешно.
- Проверете опциите за търсене и нулиране.
Заключение
В тази статия обсъдихме колко сложно би могло да бъде приложение за банково дело и какви са типични фази, участващи в тестването на приложението . Освен това обсъдихме и съвременните тенденции, следвани от ИТ индустриите, включително методологии и инструменти за разработване на софтуер.
Чувствайте се свободни да споделите своя опит или въпроси по тази тема!
Препоръчително четене
- Как да тествате приложението за инвестиционно банкиране (с 34+ важни сценария за тестване)
- Как да тестваме системата за банкиране на дребно
- Как да тествате приложението за здравни грижи - част 1
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Алфа тестване и бета тестване (Пълно ръководство)
- Изтегляне на eBook за тестване на Primer
- Функционално тестване срещу нефункционално тестване
- Инсталиране на приложения и подготовката им за тестване на Appium