Menu

Ako testovať bankové doménové aplikácie: Kompletný sprievodca testovaním BFSI

how test banking domain applications

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Kompletný sprievodca testovaním bankovej aplikácie: Proces testovania a tipy na BFSI (bankovníctvo, finančné služby a poistenie)

Bankové aplikácie sú jednou z najkomplexnejších aplikácií v dnešnom priemysle vývoja a testovania softvéru.

Čo robí bankové aplikácie tak zložitými? Aký prístup je potrebné dodržať pri testovaní zložitých pracovných postupov zahrnutých v bankových aplikáciách?

V tomto článku zdôrazníme rôzne fázy a techniky testovania bankových aplikácií.

Ako testovať bankové aplikácie

Čo sa dozviete:

Ako otestovať bankové aplikácie?

Rôzne funkcie vykonávané bankovými aplikáciami sú:

Bankové funkcie

Poďme si najskôr uvedomiť vlastnosti bankovej aplikácie:

  • Viacúrovňová funkčnosť na podporu tisícov súbežných používateľských relácií
  • Integrácia vo veľkom meradle: Banková aplikácia sa typicky integruje s mnohými ďalšími aplikáciami, ako sú pomôcka Bill Pay a obchodné účty
  • Komplexné pracovné toky
  • Real-Time a dávkové spracovanie
  • Vysoká miera transakcií za sekundu
  • Zabezpečené transakcie
  • Robustná sekcia prehľadov na sledovanie každodenných transakcií
  • Silný audit na riešenie problémov so zákazníkmi
  • Masívny úložný systém
  • Správa po katastrofe / zotavení.

Vyššie uvedených desať bodov je najdôležitejšie vlastnosti bankovej aplikácie.

Bankové aplikácie majú pri vykonávaní operácie viacero úrovní.

Napríklad , do Banková aplikácia môže mať:

  • Webový server komunikuje s koncovými používateľmi prostredníctvom prehľadávača
  • Middle Tier na overenie vstupu a výstupu pre webový server
  • DataBase na ukladanie údajov a postupov
  • Transakčný procesor, ktorým môže byť veľkokapacitný mainframe alebo akýkoľvek iný starší systém na vykonávanie biliónov transakcií za sekundu.

Pokiaľ hovoríme o testovaní bankových aplikácií, vyžaduje to Metodika testovania typu end to end zahŕňajúca viac techník testovania softvéru na zabezpečenie:

  • Celkové pokrytie všetkých bankových pracovných tokov a obchodných požiadaviek
  • Funkčné hľadisko aplikácie
  • Bezpečnostný aspekt aplikácie
  • Integrita údajov
  • Súbežnosť
  • Užívateľská skúsenosť

Čo robí bankové aplikácie tak zložitými?

  • Bankový softvér sa zaoberá hlavne dôvernými finančnými údajmi, takže výkon softvéru by mal byť bezchybný a bezpečný.
  • Vývojári uprednostňujú pri vývoji týchto aplikácií komplikovaný dizajn, aby sa zaistilo, že aplikácia beží požadovaným spôsobom.
  • Bankovníctvo je svet, ktorý sa neustále mení. Bankovníctvo je dnes zákazníkom sprístupnené pomocou rôznych kanálov, ako sú kamenné pobočky, bankomaty, online bankovníctvo a starostlivosť o zákazníka.
  • S príchodom technológie zaplavilo trhy mnoho peňaženiek, ktoré sa pripájajú k bankovým systémom pre finančné transakcie.
  • Očakáva sa tiež, že bankovníctvo bude v prevádzke 24 X 7 s vysokým výkonom. Na túto dostupnosť nemôže mať vplyv aktualizácia softvéru, okamžité opravy atď.
  • Na bankový svet majú veľký vplyv aj neustále zmeny, ktoré vláda prináša v podobe bankových predpisov. Akékoľvek zmeny v daňovej štruktúre majú dopad aj na bankový systém.
  • Bankový systém musí byť tiež aktuálny, pokiaľ ide o nové technológie. Analytika dát, ako je spracovanie veľkých dát a získavanie inštinktov z veľkých dát pomocou Data Science, rastie v bankovom svete.

Vyššie uvedené body robia bankový systém pre vývojárov zložitým pre vytváranie softvérových aplikácií okolo neho.

Dôležitosť testovania bankovej aplikácie

  • Testovanie bankovej aplikácie zaručuje, že všetky činnosti sú nielen dobre vykonané, ale aj zostávajú chránené a zabezpečené.
  • Bankový softvér je komplikovaný tisíckami závislostí, testovací proces si vyžaduje viac času, zdrojov a neustále sledovanie.
  • Pretože tu ide o financie, musia sa dôsledne dodržiavať usmernenia. Testéri aj vývojári by mali mať dobré znalosti domény.
  • Najdôležitejšie je zabezpečiť, aby sa pri finančných transakciách správne dodržiavali zákony a nariadenia. To je možné zabezpečiť iba testovaním.
  • Je tiež dôležité zabezpečiť, aby aplikácia a infraštruktúra, na ktorej bola aplikácia nasadená, boli schopné zvládnuť záťaž, najmä počas špičkových pracovných hodín, bez toho, aby spôsobili akékoľvek prerušenie. To je možné zabezpečiť vykonaním testovania výkonnosti.
  • V dnešnom digitálnom svete sa každá vec týka každého, čo sa týka bezpečnosti. Bankové aplikácie a finančné transakcie, ktoré sa v nej uskutočňujú, musia byť chránené pred akýmkoľvek pokusom o vlámanie. To je možné zabezpečiť vykonaním bezpečnostných testov. Testovanie bezpečnosti pomáha presadzovať priemyselné štandardy na zabezpečenie finančných transakcií.
  • Je tiež dôležité zabezpečiť, aby sa rôzne moduly bankovej aplikácie správne integrovali a dosiahli cieľ klienta. Testovanie integrácie systému pomáha dosiahnuť túto úlohu.

Pracovný tok testovania bankových aplikácií

Typické fázy testovania bankových aplikácií sú zobrazené v nasledujúcom pracovnom postupe. Budeme diskutovať o každej etape individuálne.

Toto je Waterfallov model testovania aplikácie.

Testovanie bankových aplikácií

# 1) Zhromažďovanie požiadaviek

Fáza zhromažďovania požiadaviek zahŕňa dokumentáciu požiadaviek buď ako funkčné špecifikácie, alebo ako prípady použitia. Požiadavky sa zhromažďujú podľa potrieb zákazníka a dokumentujú ich bankoví experti alebo obchodní analytici.

Zhromaždenie požiadavky

Odborníci sa zaoberajú písaním požiadaviek na viac ako jeden predmet, pretože samotné bankovníctvo má viac subdomén a integráciou všetkých týchto domén bude jedna plnohodnotná banková aplikácia.

Napríklad, Banková aplikácia môže mať samostatné moduly pre prevody, kreditné karty, výkazy, pôžičkové účty, platby účtov, obchodovanie atď.

# 2) Kontrola požiadaviek

Výsledky zhromaždenia požiadaviek sú preskúmané všetkými zainteresovanými stranami, ako sú QA Engineers, Development Leads a Peer Business Analysts.

Kontrola požiadaviek

Krížovo kontrolujú, či nie sú porušené existujúce obchodné ani nové pracovné postupy. Všetky požiadavky sú overené a validované. Na základe toho sa robia následné kroky a revízie dokumentu požiadaviek.

# 3) Prípravy obchodného scenára

V tejto fáze odvodzujú inžinieri QA obchodné scenáre z dokumentov požiadaviek (špecifikácie funkcií alebo prípady použitia); Podnikateľské scenáre sú odvodené takým spôsobom, že sú pokryté všetky obchodné požiadavky. Podnikateľské scenáre sú scenáre na vysokej úrovni bez podrobných krokov.

Ďalej tieto obchodné scenáre kontrolujú obchodní analytici, aby sa zabezpečilo, že sú splnené všetky obchodné požiadavky. Pre BA je jednoduchšie kontrolovať scenáre na vysokej úrovni, ako kontrolovať podrobné testovacie prípady na nízkej úrovni.

Napríklad , môže zákazník, ktorý otvorí Fixný vklad na rozhraní digitálneho bankovníctva, obchodným scenárom. Podobne môžeme mať rôzne obchodné scenáre týkajúce sa vytvorenia účtu v internetovom bankovníctve, online vkladov, online prevodov atď.

# 4) Funkčné testovanie

V tejto fáze sa vykonáva funkčné testovanie a vykonávajú sa bežné testovacie činnosti softvéru, ako napríklad:

Príprava testovacieho prípadu: V tejto fáze sú testovacie prípady odvodené z obchodných scenárov, jeden obchodný scenár vedie k niekoľkým pozitívnym a negatívnym testovacím prípadom. Počas tejto fázy sa zvyčajne používajú nástroje Microsoft Excel, Test Director alebo Quality Center.

Recenzia testovacieho prípadu: Recenzie rovnocennými inžiniermi QA

Testovacia situácia Prevedenie: Vykonanie testovacieho prípadu môže byť buď manuálne alebo automatické zahŕňajúce nástroje ako QC, QTP atď.

Funkčné testovanie bankovej aplikácie sa značne líši od bežného testovania softvéru. Pretože tieto aplikácie pracujú s peniazmi zákazníka a citlivými finančnými údajmi, je potrebné ich dôkladne otestovať. Nemal by sa nechať pokrývať žiadny dôležitý obchodný scenár.

Zdroj QA, ktorý testuje aplikáciu, by tiež mal mať základné znalosti o bankovej doméne.

# 5) Testovanie databázy

Banková aplikácia zahŕňa komplexné transakcie, ktoré sa vykonávajú na úrovni používateľského rozhrania aj na úrovni databázy. Preto je testovanie databázy rovnako dôležité ako funkčné testovanie. Databáza je komplikovaná a v aplikácii je úplne samostatná vrstva, a preto jej testovanie vykonávajú špecialisti na databázu. Používa techniky ako:

  • Načítavajú sa údaje
  • Migrácia databázy
  • Testovanie schémy DB a dátových typov
  • Testovanie pravidiel
  • Testovanie uložených postupov a funkcií
  • Testovanie spúšťačov
  • Integrita údajov

Hlavným účelom testovania databázy je zabezpečiť, aby:

  • Aplikácia je schopná ukladať a načítať údaje z databázy bez ich straty.
  • Dokončené transakcie by sa mali zaviazať a zrušené transakcie sa vrátia späť, aby sa zabránilo nesúladu uložených údajov.
  • Prístup do databázy a základných tabuliek majú povolené iba oprávnené aplikácie a používatelia.

Existujú predovšetkým tri spôsoby testovania databázy:

  • Štrukturálne testovanie
  • Funkčné testovanie
  • Nefunkčné testovanie

Štrukturálne testovanie

Zahŕňa to testovanie databázových objektov, ako sú databázy, schéma, tabuľky, zobrazenia, spúšťače, kontroly prístupu atď. Zabezpečenie synchronizácie dátových typov v tabuľkách s príslušnými premennými v aplikácii. Overovanie údajov a referenčnej integrity v tabuľkách.

Napríklad, Pole množstva v aplikácii by malo mať v tabuľke dátový typ desatinné číslo / float.

- S cieľom dodržať normy by sa používateľom mala umožniť kontrola prístupu prostredníctvom pohľadov.

Funkčné testovanie

Zahŕňa to testovanie databáz, ktoré vyhovujú požiadavkám používateľov. Existujú dva spôsoby, ako to dosiahnuť: testovanie čiernej skrinky a testovanie bielej skrinky.

Napríklad, Keď robíme online prevod peňazí, mala by sa z účtu odosielateľa odpísať suma a na účet príjemcu by sa mala pripísať presne rovnaká suma. Ak transakcia zlyhá, mali by sa vrátiť celé transakcie a z účtu odosielateľa by sa už nemalo účtovať ani účtovať späť.

Nefunkčné testovanie

Zahŕňa záťažové a záťažové testovanie a optimalizáciu výkonu. Testovanie záťaže pomáha pri identifikácii najväčšieho počtu transakcií, ktoré je možné vykonať súčasne bez ovplyvnenia výkonu databázy.

Napríklad, Na základe vstupu z testovania záťaže a záťažového bankovníctva sa bankové aplikácie môžu rozhodnúť pridať do svojej aplikácie ďalšie zdroje počas špičkových pracovných hodín a znížiť ich v mimopracovných hodinách. To pomáha banke optimálne využívať zdroje a šetriť peniaze.

# 6) Testovanie bezpečnosti

Testovanie bezpečnosti je zvyčajne poslednou fázou testovacieho cyklu. Predpokladom na začatie testovania bezpečnosti je absolvovanie funkčného a nefunkčného testovania. Testovanie bezpečnosti je jednou z hlavných fáz celého cyklu testovania aplikácií, pretože táto fáza zaisťuje, že aplikácia je v súlade s federálnymi a priemyselnými štandardmi.

Vzhľadom na povahu dát, ktoré prenášajú, sú bankové aplikácie veľmi citlivé a sú hlavným terčom hackerov a podvodných aktivít. Testovanie bezpečnosti zaisťuje, že aplikácia nemá žiadnu takúto webovú zraniteľnosť, ktorá by mohla odhaliť citlivé údaje votrelcovi alebo útočníkovi. Zaisťuje tiež, že aplikácia je v súlade s normami, ako je OWASP.

V tejto fáze je hlavnou úlohou skenovanie celej aplikácie, ktoré sa vykonáva pomocou nástrojov ako IBM AppScan alebo HP WebInspect (sú to najobľúbenejšie nástroje).

Po dokončení skenovania sa správa o skenovaní zverejní. V tejto správe sa odfiltrujú falošné pozitívy a zvyšné chyby sa nahlasujú vývojovému tímu, ktorý ich začne opravovať v závislosti od závažnosti každého problému.

V tomto kroku sa tiež vykonáva penetračné testovanie, aby sa zistilo šírenie chýb. Mali by sa vykonať dôkladné bezpečnostné testy na rôznych platformách, sieťach a OS.

Niečo iné Ručné nástroje na testovanie bezpečnosti použité sú Paros Proxy , Http hodinky , Burp Suite a Opevniť.

Hlavným účelom testovania bezpečnosti je presne určiť všetky chyby zabezpečenia, ktoré softvérová aplikácia môže mať.

Testovanie bezpečnosti testuje aplikáciu proti:

  • Akýkoľvek externý útok alebo pokus o hacknutie aplikácie so škodlivým úmyslom.
  • Akákoľvek medzera v softvérovej aplikácii by mohla byť zneužitá a spôsobiť tak údaje alebo finančné straty.
  • Akákoľvek slabina v sieti, serveroch a pracovných staniciach, ktoré sú hostiteľmi aplikácie.

Nasledujú rôzne typy testovania zabezpečenia:

Testovanie zraniteľnosti: Na kontrolu rôznych chýb zabezpečenia je vyvinutý a vykonaný automatizovaný program.

Bezpečnostné skenovanie: Tento variant sa točí okolo vyšetrovania zraniteľností siete a systému a poskytuje riešenia na zníženie súvisiaceho rizika.

Testovanie prieniku: Tento variant testovania bezpečnosti napodobňuje pokus o hackerstvo zachytiť zraniteľné miesta a medzery, ktoré by inak mohli získať prístup k databáze alebo údajom aplikácie.

Bezpečnostný audit: Zahŕňa audit aplikácie a pridružených sietí v prípade akýchkoľvek bezpečnostných výpadkov.

Posúdenie rizík: Tento variant robí analýzu na zhodnotenie úrovne rizika v prípade, že je zraniteľnosť alebo medzera zneužitá na úmysel zneužitia. Takéto riziko by sa dalo kategorizovať na nízke, stredné a vysoké. Na základe úrovne rizika odporúča testovací tím správne opatrenia na zníženie alebo odvrátenie rizika.

Etické hackerstvo: Vykonáva to organizácia na svojich systémoch s cieľom identifikovať medzery, ktoré by sa dali zneužiť v jej aplikácii alebo sieti. Účelom tohto typu hackerstva nie je ukradnutie alebo poškodenie aplikácie alebo siete.

Hodnotenie držania tela: Toto je zastrešujúce hodnotenie pozostávajúce z bezpečnostného skenovania, hodnotení rizík a etického hackerstva.

SQL Injection: Na získanie prístupu do databázy servera je možné použiť SQL Injection. Testovanie sa vykonáva preto, aby sa zaistilo správne fungovanie kódu, ktorý vykonáva dotazy na databázu na základe nasledujúcich vstupov od používateľa:

  • Konzoly
  • Apostrofy
  • Čiarky
  • Úvodzovky

Ďalšie etapy testovania aplikácie BFSI

Okrem vyššie uvedených hlavných fáz môžu byť zahrnuté rôzne fázy, ako napríklad Testovanie integrácie, Testovanie použiteľnosti, Testy prijatia používateľom a Testovanie výkonu.

Hovorme v krátkosti aj o týchto fázach:

Testovanie integrácie

Ako viete, v bankovej aplikácii môže existovať niekoľko rôznych modulov, ako sú prevody, platby účtov, vklady atď. Existuje teda veľa vyvíjaných komponentov. V integračnom testovaní sa všetky komponenty integrovali a overili.

Testovanie použiteľnosti

Testovanie použiteľnosti

Banková aplikácia slúži širokej škále zákazníkov. Niektorým z týchto zákazníkov nemusí chýbať zručnosti a povedomie potrebné na vykonávanie bankových úloh v aplikácii.

Banková aplikácia by mala byť testovaná na jednoduchý a efektívny dizajn, aby bola použiteľná pre rôzne skupiny zákazníkov. Čím je rozhranie jednoduchšie a ľahšie použiteľné, tým vyšší počet zákazníkov bude mať z bankovej aplikácie prospech.

Ide o preskúmanie úrovne ľahkosti, ktorú majú používatelia firmy alebo zákazníci bánk pri používaní aplikácie. Toto testovanie nevykonáva vývojár alebo tester, ale vykonávajú ho obchodní používatelia.

Napríklad, V dnešnej dobe každý používa mobilné aplikácie. Banková aplikácia by mala byť užívateľsky prívetivá, ľahko pochopiteľná a použiteľná pre koncového používateľa.

Druhy testovania použiteľnosti

Porovnávacie testovanie použiteľnosti: Jedná sa o testovanie založené na porovnaní, kde je ľahká použiteľnosť jednej webovej stránky alebo aplikácie s druhou. Cieľom tohto testovania je poskytnúť čo najlepšiu používateľskú skúsenosť.

Exploratívne testovanie použiteľnosti: Cieľom tohto testovania je zistiť, aké vlastnosti by mala mať nová aplikácia alebo softvér, aby vyhovoval požiadavkám banky.

Nasledujú výhody a nevýhody testovania použiteľnosti

čo môže prehrávať súbory .swf

Výhody:

  • Do testovania sú zvyčajne zapojení koncoví používatelia aplikácie, a preto sa získava spätná väzba z prvej ruky.
  • Namiesto trávenia času analýzou a diskusiou o funkcii, ktorú by produkt mal alebo nemal mať, je lepšie získavať vstupy priamo od koncového používateľa.
  • Predtým dokážeme zachytiť akékoľvek potenciálne problémy.

Nevýhody:

  • Pretože je do testovania zapojených viac koncových používateľov, môžu ich požiadavky, ak nie sú presné, ovplyvniť požiadavku.
  • Informačný kanál od koncových používateľov môže byť ovplyvnený.

Testovanie výkonu

Určité časové obdobia, ako sú výplaty, koniec finančného roka, sviatočné obdobia, môžu spôsobiť zmenu alebo prudký nárast obvyklej premávky v aplikácii. Preto by sa malo vykonať dôkladné testovanie výkonu, aby zákazníci neboli ovplyvnení výpadkami výkonu.

Významným príkladom z minulosti, kedy boli zákazníci bánk osobne postihnutí z dôvodu zlyhania výkonu, sú výpadky IT v sieťach NatWest a RBS cyber Monday, v rámci ktorých mali zákazníci debetné a kreditné karty odmietnuté transakcie v obchodoch v krajine.

Testovanie prijatia používateľa

To sa deje zapojením koncových používateľov, aby sa zabezpečilo, že aplikácia vyhovuje scenárom z reálneho sveta a ak bude zverejnená, budú ju používatelia akceptovať.

V dnešnom scenári väčšina bankových projektov využíva : Metodiky Agile / Scrum, RUP a Continuous Integration a balíčky nástrojov ako VSTS spoločnosti Microsoft a Rational Tools.

Ako sme už spomenuli o RUP vyššie, RUP znamená Rational Unified Process, čo je iteratívna metodika vývoja softvéru zavedená spoločnosťou IBM, ktorá pozostáva zo štyroch fáz, v ktorých sa vykonávajú vývojové a testovacie činnosti.

Štyri fázy sú
i) Počiatok
ii) Spolupráca
iii) Konštrukcia a
iv) Prechod

RUP vo veľkej miere zahŕňa nástroje IBM Rational.

Vzorové testovacie prípady pre bankové aplikácie

Testovacie prípady pre novú pobočku

  • Vytvorte novú vetvu s platnými a neplatnými údajmi o teste.
  • Vytvorte novú pobočku bez údajov.
  • Vytvorte novú pobočku s existujúcimi údajmi o pobočkách.
  • Overte možnosti obnovenia a zrušenia.
  • Aktualizujte podrobnosti vetvy o platné a neplatné údaje o teste.
  • Aktualizujte podrobnosti pobočky o existujúce údaje o testovaní pobočky.
  • Skontrolujte, či je možné novú pobočku uložiť.
  • Skontrolujte, či možnosť zrušenia funguje.
  • Overte odstránenie vetvy so závislosťami a bez závislostí.
  • Skontrolujte, či možnosť vyhľadávania pobočiek funguje.

Testovacie prípady pre novú rolu

  • Vytvorte novú rolu s platnými a neplatnými testovacími údajmi.
  • Vytvorte novú rolu bez údajov.
  • Overte, či je možné vytvoriť novú rolu s existujúcimi údajmi o teste.
  • Overte popis a typy rolí.
  • Skontrolujte funkčnosť možnosti zrušenia a obnovenia.
  • Overte proces odstránenia roly so závislosťou alebo bez nej.
  • Overte odkazy na stránke s podrobnosťami o role.
  • Overte prihlásenie správcu bez testovacích údajov.
  • Overte všetky domovské odkazy pre rolu správcu.
  • Skontrolujte, či správca môže zmeniť heslo pomocou platných a neplatných údajov o teste.
  • Overte, či sa administrátor úspešne odhlásil.

Testovacie prípady pre zákazníka a bankára

  • Overte, či všetky prepojenia návštevníkov a zákazníkov fungujú správne.
  • Overte prihlásenie zákazníka platnými a neplatnými testovacími údajmi.
  • Overte prihlásenie zákazníka bez akýchkoľvek údajov.
  • Overte prihlásenie bankára bez akýchkoľvek údajov.
  • Overte prihlásenie bankára pomocou platných alebo neplatných testovacích údajov.
  • Overte, či sa zákazník alebo bankár môžu úspešne odhlásiť.

Testovacie prípady pre nových používateľov

  • Overte, či je nového používateľa možné vytvoriť pomocou platných a neplatných údajov o teste.
  • Vytvorte nového používateľa s existujúcimi údajmi o teste pobočky
  • Skontrolujte, či možnosť zrušenia a obnovenia funguje správne.
  • Aktualizujte údaje o používateľovi platnými a neplatnými údajmi o teste.
  • Overte odstránenie nového používateľa.
  • skontrolujte, či je možné nového používateľa overiť.
  • Overte povinné vstupné parametre.
  • Overte voliteľné vstupné parametre.
  • Overte, či je možné používateľa vytvoriť bez voliteľných parametrov.

Testovacie prípady na vytvorenie nového účtu

  • Vytvorte nový účet s platnými a neplatnými údajmi používateľa.
  • Overte, či je možné aktualizovať údaje používateľa.
  • Overte, či je možné uložiť nového používateľa.
  • Vytvorte nový účet s údajmi o existujúcich používateľoch.
  • Skontrolujte, či používateľ môže vložiť sumu na novovytvorený účet (a aktualizovať zostatok).
  • Overte, či používateľ môže vybrať čiastku z nového účtu (po uložení a aktualizácii zostatku).
  • V prípade platu účet overte názov spoločnosti a ďalšie podrobnosti poskytne užívateľ.
  • Skontrolujte, či je v prípade sekundárneho účtu uvedené číslo primárneho účtu.
  • Overte údaje o používateľovi poskytnuté v prípade aktuálneho účtu.
  • V prípade spoločného účtu overte poskytnuté dôkazy pre spoločný účet.
  • Overte, či je schopný udržiavať nulový zostatok na platovom účte.
  • Overte, či je možné zachovať nulový alebo minimálny zostatok pre nemzdový účet.
  • Overte, či sa nový používateľ môže úspešne odhlásiť.

Testovacie prípady pre aplikácie v oblasti internetového bankovníctva

  • Skontrolujte, či je používateľ schopný otvoriť stránku banky.
  • Skontrolujte, či všetky odkazy na webe fungujú.
  • Overte, či je používateľ schopný vytvoriť nový účet.
  • Skontrolujte, či je používateľ schopný prihlásiť sa pomocou platného a neplatného používateľského mena a hesla.
  • Počas prihlásenia skontrolujte, či je niektoré z používateľských mien alebo hesiel prázdne, používateľovi by nemalo byť umožnené prihlásiť sa a zobrazí sa výstražná správa.
  • Skontrolujte, či má používateľ povolenie na zmenu hesla.
  • Ak je zadaný neplatný užívateľ alebo heslo, zobrazí sa správne chybové hlásenie.
  • Používateľom s neplatným heslom by nemalo byť dovolené prihlásiť sa.
  • Overte si, že po opakovaných pokusoch o prihlásenie pomocou nesprávneho hesla by sa malo používateľovi zobraziť chybové hlásenie a byť zablokovaný.
  • Skontrolujte, či je používateľ schopný vykonať niektoré základné transakcie.
  • Overte, či je používateľ schopný pridať príjemcu s platnými a neplatnými údajmi.
  • Overte, či môže používateľ príjemcu vymazať.
  • Overte, či je používateľ schopný vykonať transakcie s novo pridaným príjemcom.
  • Po transakcii overte, či sú účty používateľov aj príjemcov aktualizované.
  • Skontrolujte, či je používateľ schopný zadať sumu v desatinnom počte.
  • Overte, či používateľ nie je schopný zadať záporné čísla do poľa sumy.
  • Overte, či je používateľ oprávnený vykonávať transakcie s minimálnym zostatkom alebo bez neho.
  • Overte, či môže používateľ urobiť nový RD.
  • Skontrolujte, či sa správna správa zobrazuje v prípade transakcie vykonanej s nedostatočným zostatkom.
  • Pred vykonaním akejkoľvek transakcie skontrolujte, či je používateľ vyzvaný na potvrdenie.
  • Overte, či je pri každej úspešnej transakcii poskytnuté potvrdenie o prijatí.
  • Overte, či je používateľ schopný prevádzať peniaze na viac účtov.
  • overiť, či môže používateľ transakciu zrušiť.
  • Overte, či podrobnosti účtu odrážajú aj uskutočnené finančné transakcie.
  • Skontrolujte, či je implementovaná funkcia časového limitu.
  • overte si, že v prípade časového limitu relácie by sa mal používateľ znova prihlásiť.
  • skontrolujte, či je v prípade nečinnosti vykonaný správny časový limit relácie.
  • overiť, či je používateľ pri transakcii uvedený do zabezpečeného režimu.
  • Overte, či sa používateľ môže úspešne odhlásiť.
  • Overte možnosti vyhľadávania a obnovenia.

Záver

V tomto článku sme diskutovali aká zložitá môže byť banková aplikácia a čo sú typické fázy testovania aplikácie . Okrem toho sme diskutovali aj o súčasných trendoch sledovaných v IT priemysle vrátane metodík a nástrojov pre vývoj softvéru.

Neváhajte a podeľte sa o svoje skúsenosti alebo otázky týkajúce sa tejto témy!

Odporúčané čítanie

^