how test banking domain applications
Комплетан водич за тестирање банкарске апликације: БФСИ (банкарство, финансијске услуге и осигурање) процес тестирања и савети
Банкарске апликације су једна од најсложенијих апликација у данашњој индустрији развоја и тестирања софтвера.
Шта чини банкарске апликације тако сложеним? Који приступ треба следити за тестирање сложених токова посла који су укључени у банкарске апликације?
У овом чланку ћемо истакнути различите фазе и технике укључене у тестирање банкарских апликација.
Шта ћете научити:
- Како тестирати банкарске апликације?
- Значај тестирања банкарске апликације
- Ток рада за тестирање банкарских апликација
- Примери тест случајева за банкарску апликацију
- Закључак
Како тестирати банкарске апликације?
Разне функције које обављају банкарске апликације су:
Прво да схватимо карактеристике банкарске апликације:
- Вишеразинска функционалност за подршку хиљадама истовремених корисничких сесија
- Велике интеграције: Обично се банкарска апликација интегрише са бројним другим апликацијама, као што су услужни програм Билл Паи и рачуни за трговање
- Сложени пословни токови посла
- Обрада у реалном времену и серија
- Висока стопа трансакција у секунди
- Сигурне трансакције
- Робусно одељење за извештавање за праћење свакодневних трансакција
- Снажна ревизија за решавање проблема са купцима
- Масивни систем за складиштење
- Управљање катастрофама / опоравком.
Горе наведених десет тачака су најважније карактеристике банкарске апликације.
Банкарске апликације имају више нивоа који су укључени у обављање операције.
На пример , до Пријава за банкарство може имати:
- Веб сервер за интеракцију са крајњим корисницима путем прегледача
- Средњи ниво за потврђивање улаза и резултата за веб сервер
- ДатаБасе за чување података и процедура
- Процесор за трансакције који може бити Маинфраме великог капацитета или било који други наслеђени систем за обављање билијуна трансакција у секунди.
Ако говоримо о тестирању банкарских апликација, потребно је Методологија тестирања од краја до краја која укључује више техника тестирања софтвера како би се осигурало:
- Укупна покривеност свих банкарских токова рада и пословних захтева
- Функционални аспект апликације
- Сигурносни аспект апликације
- Интегритет података
- Истовремено
- Корисничко искуство
Шта чини банкарске апликације тако сложеним?
- Банкарски софтвер углавном се бави поверљивим финансијским подацима, тако да перформансе софтвера треба да буду без грешака и безбедне.
- Програмери преферирају сложени дизајн за развој ових апликација како би осигурали да апликација ради на жељени сигуран начин.
- Банкарство је свет који се непрестано мења. Данас је банкарство клијентима доступно путем различитих канала попут филијала, банкомата, банкарства на мрежи и бриге о купцима.
- Појавом технологије, многи новчаници су преплавили тржишта која се повезују са банкарским системима за финансијске трансакције.
- Такође се очекује да банкарство буде у функцији 24 Кс 7 са високим перформансама. Надоградње софтвера, тренутни поправци итд. Не смеју утицати на ову доступност.
- На банкарски свет такође су под великим утицајем сталне промене које је влада увела у облику банкарских прописа. Све промене у пореској структури утичу и на банкарски систем.
- Банкарски систем такође мора да буде ажуран што се тиче нових технологија. Аналитика података попут обраде великих података и извлачења инстинкта из великих података помоћу Дата Сциенце-а расте у банкарском свету.
Горе поменуте тачке чине банкарски систем сложеним за програмере да креирају софтверску апликацију око њега.
Значај тестирања банкарске апликације
- Тестирање банкарске апликације осигурава да се све активности не само добро извршавају већ и остају заштићене и заштићене.
- Софтвер за банкарство је компликован са хиљадама зависности, процес тестирања захтева више времена, ресурса и непрекидно надгледање.
- Како су овде укључене финансије, смернице се морају стриктно поштовати. И тестери и програмери треба да имају добро доменско знање.
- Најважније је да се мора осигурати да се закони и прописи правилно примењују у финансијским трансакцијама. То се може осигурати само тестирањем.
- Такође је важно осигурати да апликација и инфраструктура на којој је апликација распоређена могу да поднесу оптерећење, посебно током највећег радног времена, без наношења сметњи. То се може осигурати вршењем испитивања перформанси.
- У данашњем дигиталном свету једна ствар која се тиче свих је сигурност. Банкарске апликације и финансијске трансакције које се у њој обављају морају бити заштићене од сваког покушаја провале. То се може осигурати вршењем сигурносних тестова. Испитивање сигурности помаже у спровођењу индустријских стандарда како би се осигурале финансијске трансакције.
- Такође је важно осигурати да се различити модули банкарске апликације и правилно интегришу и постигну циљеви клијента. Тестирање системске интеграције помаже у постизању овог задатка.
Ток рада за тестирање банкарских апликација
Типичне фазе укључене у тестирање банкарских апликација су приказани у доњем току рада. Разговараћемо о свакој фази појединачно.
Ово је модел водопада за тестирање апликације.
# 1) Окупљање захтева
Фаза окупљања захтева укључује документовање захтева или као функционалне спецификације или као случајеве употребе. Захтјеви се прикупљају према потребама клијената и документују их банкарски стручњаци или пословни аналитичари.
Стручњаци су укључени у писање захтева о више од једне теме, јер само банкарство има више поддомена, а једна пуноправна банкарска апликација биће интеграција свих ових домена.
На пример, Банкарска апликација може имати засебне модуле за трансфере, кредитне картице, извештаје, рачуне зајма, плаћања рачуна, трговање итд.
# 2) Преглед захтева
Испоруку Прикупљања захтева прегледају све заинтересоване стране, попут КА инжењера, развојних лидера и вршњачких пословних аналитичара.
Они унакрсно проверавају да ли се крше нити постојећи пословни ток нити нови токови посла. Сви захтеви су верификовани и потврђени. Пратеће радње и ревизија документа захтева врше се на основу истих.
# 3) Припрема пословног сценарија
У овој фази КА инжењери изводе пословне сценарије из захтеваних докумената (спецификације функција или случајеви употребе); Пословни сценарији су изведени на такав начин да су покривени сви пословни захтеви. Пословни сценарији су сценарији на високом нивоу без детаљних корака.
Даље, ови пословни сценарији прегледавају пословне аналитичаре како би се осигурало да су испуњени сви пословни захтеви. БА-има је лакше да прегледају сценарије високог нивоа, него да детаљно прегледају случајеве ниског нивоа.
На пример , клијент који отвара фиксни депозит на интерфејсу дигиталног банкарства може бити пословни сценарио. Слично томе, можемо имати различите пословне сценарије који се односе на креирање нето банкарских рачуна, депозите на мрежи, онлајн трансфере итд.
# 4) Функционално тестирање
У овој фази се врши функционално тестирање и обављају се уобичајене активности тестирања софтвера као што су:
Припрема тест случаја: У овој фази тест случајеви су изведени из пословних сценарија, један пословни сценарио доводи до неколико позитивних и негативних тест случајева. Генерално, алати који се користе током ове фазе су Мицрософт Екцел, директор теста или Центар за квалитет.
Преглед тест случаја: Прегледи вршњачких КА инжењера
Тест Цасе Извршење: Извршење тест случаја може бити ручно или аутоматски укључујући алате попут КЦ, КТП итд.
Функционално тестирање банкарске апликације се прилично разликује од уобичајеног тестирања софтвера. С обзиром да ове апликације раде са новцем купца и осетљивим финансијским подацима, морају се темељито тестирати. Ниједан важан пословни сценарио не би требало да буде покривен.
Такође, КА ресурс који тестира апликацију треба да има основно знање о банкарском домену.
# 5) Тестирање базе података
Банкарска апликација укључује сложену трансакцију која се изводи и на нивоу корисничког интерфејса и на нивоу базе података, стога је тестирање базе података једнако важно као и функционално тестирање. База података је компликована и потпуно одвојен слој у апликацији, тако да њено тестирање врше стручњаци за базе података. Користи технике попут:
- Учитавање података
- Миграција базе података
- Тестирање ДБ шеме и типова података
- Испитивање правила
- Тестирање ускладиштених процедура и функција
- Тестирање окидача
- Интегритет података
Главна сврха тестирања базе података је осигурати да:
- Апликација је у стању да складишти и преузима податке из базе података без губитка података.
- Завршене трансакције треба извршити, а покидане трансакције се враћају натраг како би се избегла било каква неусклађеност ускладиштених података.
- Само овлашћеним апликацијама и корисницима је дозвољен приступ бази података и основним табелама.
Постоје првенствено три начина тестирања базе података:
- Испитивање конструкције
- Функционално тестирање
- Нефункционално тестирање
Испитивање конструкције
Укључује тестирање објеката базе података као што су базе података, шема, табеле, погледи, окидачи, контроле приступа итд. Осигуравање да су типови података у табелама синхронизовани са одговарајућим променљивим у апликацији. Провера података и референтног интегритета у табелама.
На пример, Поље износа у апликацији треба да има тип података децимални / флоат у табели.
- Да би били у складу са стандардима, корисници би требали добити контролу приступа путем погледа.
Функционално тестирање
Укључује тестирање база података које задовољавају захтеве корисника. Постоје два начина за постизање: тестирање црне кутије и тестирање беле кутије.
На пример, Када вршимо пренос новца путем Интернета, рачун пошиљаоца треба да се терети, а рачун примаоца треба да се књижи са потпуно истим износом. Ако трансакција не успије, цијеле трансакције треба поништити, а рачун пошиљаоца не смије бити терећен или враћен.
Нефункционално тестирање
Укључује испитивање оптерећења и напрезања и оптимизацију перформанси. Испитивање учитавања помаже у идентификовању највећег броја трансакција које се могу истовремено изводити без утицаја на перформансе базе података.
На пример, На основу података оптерећења и тестирања отпорности на стрес, банкарске апликације могу да одлуче да додају више ресурса својој апликацији током врхунца радног времена и смање ресурсе током ван радног времена. Ово помаже банци да оптимално користи ресурсе и уштеди новац.
# 6) Испитивање сигурности
Испитивање сигурности је обично последња фаза у циклусу тестирања. Предуслов за започињање сигурносног тестирања је завршетак функционалног и нефункционалног тестирања. Испитивање сигурности је једна од главних фаза у читавом циклусу тестирања апликација, јер ова фаза осигурава да је апликација у складу са савезним и индустријским стандардима.
Због природе података које носе, банкарске апликације су веома осетљиве и главна су мета хакера и превара. Сигурносно тестирање осигурава да апликација нема такву веб рањивост која осетљиве податке може изложити уљезу или нападачу. Такође осигурава да је апликација у складу са стандардима попут ОВАСП.
У овој фази, главни задатак је целокупно скенирање апликација које се врши помоћу алата попут ИБМ АппСцан или ХП ВебИнспецт (ово су најпопуларнији алати).
По завршетку скенирања објављује се извештај о скенирању. Преко овог извештаја, Лажни позитивни резултати се филтрирају, а остатак рањивости пријављује развојном тиму тако да започну са решавањем проблема у зависности од тежине сваког проблема.
У овом кораку се такође врши испитивање пенетрације како би се открило ширење грешака. Строго тестирање безбедности требало би да се врши на свим платформама, мрежама и ОС-у.
Неке друге Ручни алати за испитивање сигурности користе се Парос Проки , Хттп Ватцх , Бурп Суите , и Утврдити.
Главна сврха безбедносног тестирања је утврђивање свих рањивости софтверске апликације.
Тестирање сигурности тестира апликацију на основу:
- Сваки спољни напад или покушај хаковања апликације са злонамерном намером.
- Свака рупа у софтверској апликацији може се искористити што доводи до губитка података или новца.
- Свака рањивост у мрежи, серверима и радним станицама на којима се налази апликација.
Следе разне врсте сигурносних испитивања:
Тестирање рањивости: Развијен је и извршен аутоматизовани програм за проверу различитих рањивости.
Сигурносно скенирање: Ова варијанта се врти око истраживања рањивости мреже и система, пружа решења за смањење повезаног ризика.
Пенетрација тестирање: Ова варијанта безбедносног тестирања имитира покушај хаковања да се ухвате рањивости и рупе, које би иначе могле добити приступ бази података или подацима апликације.
Ревизија безбедности: Укључује ревизију апликације и повезаних мрежа ради било каквих пропуста у безбедности.
Процена ризика: Ова варијанта врши анализу за процену нивоа ризика у случају када се рањивост или рупа користе због злонамерне намере. Такав ризик би се могао сврстати у низак, средњи и висок. На основу нивоа ризика, тим за испитивање саветује одговарајуће мере за смањење или спречавање ризика.
Етичко хаковање: То обавља организација на својим системима да би идентификовала рупе које би се могле искористити у њеној апликацији или мрежи. Намера ове врсте хаковања није да украде или нанесе штету апликацији или мрежи.
Процена држања тела: Ово је кровна процјена која се састоји од сигурносног скенирања, процјене ризика и етичког хаковања.
СКЛ Ињецтион: СКЛ Ињецтион се може користити за добијање приступа серверској бази података. Тестирање се врши како би се осигурало да код исправно ради, а који извршавају упите у бази података на основу следећих података корисника:
- Заграде
- Апострофи
- Зарези
- Знаци навода
Остале фазе тестирања апликације БФСИ
Осим горе наведених главних фаза, можда су укључене различите фазе, као што су интеграционо тестирање, тестирање употребљивости, тестирање прихваћености корисника и тестирање перформанси.
Разговарајмо укратко и о овим фазама:
Интеграционо тестирање
Као што знате да у банкарској апликацији може постојати неколико различитих модула попут трансфера, плаћања рачуна, депозита итд. Дакле, постоји много развијених компоненти. У интеграционом тестирању, све компоненте су интегрисане и потврђене.
Испитивање употребљивости
Банкарска апликација служи широком спектру клијената. Неким од ових клијената можда недостају вештине и свест потребне за обављање банкарских задатака преко апликације.
Стога би банкарску апликацију требало тестирати на једноставан и ефикасан дизајн како би била употребљива у различитим групама клијената. Што је интерфејс једноставнији и лак за употребу, већи број клијената ће имати користи од банкарске апликације.
Ради се о испитивању нивоа лакоће коју користе пословни корисници или банкарски клијенти. Ово тестирање не врши програмер или тестер, већ га обављају пословни корисници.
На пример, Данас сви користе мобилне апликације. Апликација за банкарство треба да буде једноставна за корисника и да је крајњи корисник лако разуме и користи.
Врсте испитивања употребљивости
Упоредно испитивање употребљивости: Ово је тестирање засновано на поређењу, где је једноставност употребе једне веб странице или апликације са другом. Циљ таквог тестирања је пружање најбољег корисничког искуства.
Испитивање употребљивости: Циљ овог тестирања је да утврди које функције нова апликација или софтвер треба да поседује како би удовољила захтевима банке.
Следе предности и недостаци испитивања употребљивости
продајно место софтвера за ипад
Предности:
- Крајњи корисници апликације обично су укључени у тестирање, па се стога добијају повратне информације из прве руке.
- Уместо да трошите време на анализу и расправу о функцији коју производ треба да има или не, боље је податке добити од крајњег корисника директно.
- Све потенцијалне проблеме можемо унапред ухватити.
Мане:
- Како је у тестирање укључено више крајњих корисника, њихова мишљења ако нису прецизна могу утицати на захтев.
- На фид крајњих корисника може се утицати.
Тестирање перформанси
Одређени временски периоди као што су дан исплате, крај финансијске године, празничне сезоне могу донети промену или повећати уобичајени промет у апликацији. Стога би требало извршити темељно испитивање перформанси како купци не би били погођени неуспехом у перформансама.
Значајан пример из прошлости када су банкарски клијенти лично погођени због неуспеха у перформансама је прекид рада НатВеста и РБС цибер понедељка у коме су клијенти имали дебитну и кредитну картицу због одбијених трансакција у трговинама у земљи.
Тестирање прихватљивости корисника
То се постиже укључивањем крајњих корисника како би се осигурало да је апликација у складу са стварним сценаријима и да ће је корисници прихватити ако буде активна.
У данашњем сценарију користи већина банкарских пројеката : Агиле / Сцрум, РУП и континуирана интеграција методологије и пакети Алати попут Мицрософтових ВСТС и Ратионал Тоолс.
Као што смо горе споменули о РУП-у, РУП је скраћеница од Ратионал Унифиед Процесс, који је итеративна методологија развоја софтвера коју је увео ИБМ, а састоји се од четири фазе у којима се спроводе развојне и испитне активности.
Четири фазе су
и) Почетни
ии) Сарадња
иии) Изградња и
ив) Транзиција
РУП широко укључује ИБМ Ратионал алате.
Примери тест случајева за банкарску апликацију
Тест случајеви за Нев Бранцх
- Направите нову грану са важећим и неважећим подацима теста.
- Направите нову грану без података.
- Направите нову грану са постојећим подацима о грани.
- Потврдите опције ресетовања и отказивања.
- Ажурирајте детаље о грани са важећим и неважећим тест подацима.
- Ажурирајте детаље о грани постојећим подацима о тестирању грана.
- Проверите да ли се нова грана може сачувати.
- Проверите да ли опција отказивања ради.
- Потврдите брисање гране са и без зависности.
- Проверите да ли опција претраге грана ради.
Тест случајеви за нову улогу
- Направите нову улогу са важећим и неважећим подацима теста.
- Направите нову улогу без података.
- Проверите да ли се нова улога може створити помоћу постојећих података о тестирању.
- Проверите опис улоге и типове улога.
- Проверите да ли опција отказивања и ресетовања ради.
- Проверите поступак брисања улоге са и без зависности.
- Проверите везе на страници са детаљима о улози.
- Потврдите администраторску пријаву без података о тестирању.
- Потврдите све везе до куће за улогу администратора.
- Уверите се да администратор може променити лозинку са важећим и неважећим подацима теста.
- Проверите да ли се администратор успешно одјавио.
Тест случајеви за купца и банкара
- Проверите да ли све везе посетилаца и купаца раде исправно.
- Потврдите пријаву купца са важећим и неважећим подацима теста.
- Потврдите пријаву купца без икаквих података.
- Потврдите пријаву банкара без икаквих података.
- Потврдите пријаву банкара са важећим или неважећим тест подацима.
- Проверите да ли се купац или банкар може успешно одјавити.
Тест случајеви за нове кориснике
- Проверите да ли нови корисник може да се креира са важећим и неважећим тест подацима.
- Направите новог корисника са постојећим подацима о тестирању грана
- Проверите да ли опција отказивања и ресетовања ради исправно.
- Ажурирајте корисничке детаље важећим и неважећим подацима теста.
- Потврдите брисање новог корисника.
- проверите да ли се нови корисник може верификовати.
- Проверите обавезне улазне параметре.
- Проверите опционалне улазне параметре.
- Проверите да ли корисник може да се креира без опционалних параметара.
Тест случајеви за стварање новог налога
- Направите нови налог са важећим и неважећим корисничким подацима.
- Проверите да ли се детаљи корисника могу ажурирати.
- Проверите да ли је могуће сачувати новог корисника.
- Направите нови налог са подацима постојећих корисника.
- Проверите да ли корисник може уплатити износ на новоотворени рачун (и ажурирати стање).
- Проверите да ли корисник може подићи износ са новог рачуна (након полагања и ажурирања стања).
- У случају зараде, рачун верификујте назив компаније и остале детаље даје корисник.
- Проверите да ли је наведен примарни број рачуна у случају секундарног рачуна.
- Потврдите корисничке детаље дане у случајевима текућег рачуна.
- Проверите достављене доказе за заједнички рачун у случају заједничког рачуна.
- Проверите да ли можете да одржавате нулти салдо на рачуну зарада.
- Проверите да ли можете да одржавате нулти салдо или минимални салдо за рачун без зарада.
- Проверите да ли се нови корисник може успешно одјавити.
Испитни случајеви за апликацију мрежног банкарства
- Проверите да ли је корисник у могућности да отвори веб локацију банке.
- Проверите да ли раде све везе на веб локацији.
- Проверите да ли је корисник у стању да отвори нови налог.
- Проверите да ли је корисник у могућности да се пријави са важећим и неважећим корисничким именом и лозинком.
- Проверите да ли је неко од корисничког имена или лозинке празно током пријављивања, кориснику не би требало бити дозвољено да се пријави и приказује се порука упозорења.
- Проверите да ли је кориснику дозвољено да промени лозинку.
- Ако је унесен неважећи корисник или лозинка, приказује се одговарајућа порука о грешци.
- Корисницима са неважећом лозинком не би требало бити дозвољено да се пријаве.
- Уверите се да би након поновљених покушаја да се пријави са нетачном лозинком, кориснику требала бити приказана порука о грешци и блокиран.
- Проверите да ли је корисник у стању да изврши неке основне трансакције.
- Уверите се да је корисник у могућности да дода корисника са важећим и неважећим детаљима.
- Проверите да ли корисник може избрисати корисника.
- Проверите да ли је корисник у стању да врши трансакције са новопостављеним корисником.
- Након трансакције проверите да ли су рачуни корисника и корисника ажурирани.
- Проверите да ли је корисник у стању да унесе износ у децималном броју.
- Проверите да ли корисник не може да унесе негативне бројеве у поље за износ.
- Проверите да ли је кориснику дозвољено да врши трансакције са или без минималног стања.
- Проверите да ли корисник може да уради нови РД.
- Проверите да ли се приказује исправна порука у случају трансакције извршене са недовољним салдом.
- Проверите да ли се од корисника тражи потврда пре него што се изврши било каква трансакција.
- Проверите да ли се за сваку успешну трансакцију налази потврда.
- Проверите да ли је корисник у стању да пребаци новац на више рачуна.
- проверите да ли корисник може отказати трансакцију.
- Проверите да ли детаљи о рачуну одражавају и финансијске трансакције.
- Проверите да ли је примењена функција временског ограничења.
- проверите да ли се у случају истека сесије корисник треба поново пријавити.
- проверите да ли је урађено правилно истека времена сесије у случају неактивности.
- проверите да ли је корисник приликом обављања трансакције пребачен у безбедни режим.
- Проверите да ли се корисник може успешно одјавити.
- Проверите опције претраживања и ресетовања.
Закључак
У овом чланку смо разговарали колико сложена може бити апликација за банкарство а шта су типичне фазе укључене у тестирање апликације . Поред тога, разговарали смо и о тренутним трендовима које прате ИТ индустрије, укључујући методологије и алате за развој софтвера.
Слободно поделите своје искуство или упите о овој теми!
Препоручено читање
- Како тестирати апликацију за инвестиционо банкарство (са 34+ важних сценарија тестирања)
- Како тестирати систем банкарства са становништвом
- Како тестирати апликацију за здравствену заштиту - 1. део
- Најбољи алати за тестирање софтвера 2021. године [КА Тест Аутоматион Тоолс]
- Алфа тестирање и бета тестирање (потпун водич)
- Преузимање е-књиге за тестирање буквара
- Функционално тестирање вс нефункционално тестирање
- Инсталирање апликација и припрема за тестирање Аппиум-а