Meni

Kako preizkusiti aplikacije za bančne domene: popoln priročnik za testiranje BFSI

how test banking domain applications

Preizkusite Naš Instrument Za Odpravo Težav

Popoln vodnik za preizkušanje bančne prijave: BFSI (bančništvo, finančne storitve in zavarovanje) Postopek testiranja in nasveti

Bančne aplikacije so ena najbolj zapletenih aplikacij v današnji industriji razvoja in testiranja programske opreme.

Zakaj so bančne aplikacije tako zapletene? Kakšen pristop je treba uporabiti za preizkušanje zapletenih delovnih tokov, povezanih z bančnimi aplikacijami?

V tem članku bomo predstavili različne faze in tehnike preizkušanja bančnih aplikacij.

Kako preizkusiti bančne aplikacije

Kaj se boste naučili:

Kako preizkusiti bančne aplikacije?

Različne funkcije, ki jih izvajajo bančne aplikacije, so:

Funkcije bank

Najprej razumemo značilnosti bančne aplikacije:

  • Večplastna funkcionalnost za podporo tisočim sočasnim uporabniškim sejam
  • Obsežna integracija: Običajno se bančna aplikacija integrira s številnimi drugimi aplikacijami, kot sta pripomoček Bill Pay in trgovalni računi
  • Kompleksni poslovni tokovi
  • Realnočasovna in paketna obdelava
  • Visoka stopnja transakcij na sekundo
  • Varne transakcije
  • Odsek za trdno poročanje za spremljanje vsakodnevnih transakcij
  • Močna revizija za odpravljanje težav s strankami
  • Masivni sistem za shranjevanje
  • Upravljanje ob nesrečah / obnovi.

Zgoraj naštetih deset točk je najpomembnejše značilnosti bančne aplikacije.

Bančne aplikacije imajo več nivojev, ki sodelujejo pri izvajanju operacije.

Na primer , do Vloga za bančništvo ima lahko:

  • Spletni strežnik za interakcijo s končnimi uporabniki prek brskalnika
  • Srednji nivo za preverjanje vhodnih in izhodnih vrednosti za spletni strežnik
  • DataBase za shranjevanje podatkov in postopkov
  • Procesor za transakcije, ki je lahko glavni računalnik z veliko zmogljivostjo ali kateri koli drug sistem Legacy za izvajanje bilijonov transakcij na sekundo.

Če govorimo o testiranju bančnih aplikacij, zahteva Metodologija preskušanja od konca do konca, ki vključuje več tehnik testiranja programske opreme, da se zagotovi:

  • Skupno pokritje vseh bančnih delovnih procesov in poslovnih zahtev
  • Funkcionalni vidik aplikacije
  • Varnostni vidik aplikacije
  • Celovitost podatkov
  • Sočasnost
  • Uporabniška izkušnja

Zakaj so bančne aplikacije tako zapletene?

  • Programska oprema za bančništvo se ukvarja predvsem z zaupnimi finančnimi podatki, zato mora biti delovanje programske opreme brez napak in varno.
  • Razvijalci raje uporabljajo zapleteno zasnovo za razvoj teh aplikacij, da se zagotovi, da aplikacija deluje na želeni varen način.
  • Bančništvo je svet, ki se nenehno spreminja. Bančništvo je danes strankam na voljo po različnih kanalih, kot so poslovalnice, bankomati, spletno bančništvo in skrb za stranke.
  • S prihodom tehnologije je veliko denarnic preplavilo trge, ki se povezujejo z bančnimi sistemi za finančne transakcije.
  • Pričakuje se tudi, da bo bančništvo začelo delovati 24 X 7 z visoko zmogljivostjo. Nadgradnje programske opreme, takojšnje popravke itd. Ne morejo vplivati ​​na to razpoložljivost.
  • Na bančni svet močno vplivajo tudi nenehne spremembe, ki jih je vlada uvedla v obliki bančnih predpisov. Kakršne koli spremembe davčne strukture vplivajo tudi na bančni sistem.
  • Tudi bančni sistem mora biti posodobljen, kar zadeva nove tehnologije. Podatkovna analitika, kot je obdelava velikih podatkov in pridobivanje nagonov iz velikih podatkov z uporabo Data Science, v bančnem svetu narašča.

Zgoraj omenjene točke bančni sistem zapletejo, da razvijalci lahko okoli njega ustvarijo programsko aplikacijo.

Pomen testiranja bančne aplikacije

  • Testiranje aplikacije za bančništvo zagotavlja, da se vse dejavnosti ne samo dobro izvajajo, temveč tudi ostanejo zaščitene in zaščitene.
  • Programska oprema za bančništvo je zapletena z več tisoč odvisnostmi, postopek testiranja zahteva več časa, virov in nenehnega spremljanja.
  • Ker gre tukaj za finance, je treba dosledno upoštevati smernice. Tako preizkuševalci kot razvijalci bi morali imeti dobro domensko znanje.
  • Najpomembneje pa je zagotoviti, da se zakoni in predpisi v finančnih transakcijah pravilno izvajajo. To je mogoče zagotoviti le s testiranjem.
  • Pomembno je tudi zagotoviti, da lahko aplikacija in infrastruktura, na kateri je bila aplikacija razporejena, prenese obremenitev, zlasti v času največjega delovnega časa, ne da bi povzročala motnje. To je mogoče zagotoviti s preskušanjem zmogljivosti.
  • V današnjem digitalnem svetu je ena stvar, ki zadeva vsakogar, varnost. Bančne aplikacije in finančne transakcije, ki se v njem izvajajo, morajo biti zaščitene pred vsakim poskusom vloma. To je mogoče zagotoviti z izvajanjem varnostnih preizkusov. Varnostno testiranje pomaga uveljaviti industrijske standarde za zavarovanje finančnih transakcij.
  • Pomembno je tudi zagotoviti, da se različni moduli bančne aplikacije in pravilno integrirajo ter dosežejo cilj stranke. Testiranje sistemske integracije pomaga doseči to nalogo.

Potek testiranja aplikacij za bančništvo

Tipične faze preizkušanja bančnih aplikacij so prikazani v spodnjem delovnem toku. Razpravljali bomo o vsaki fazi posebej.

To je model slapa za preizkušanje aplikacije.

Testiranje bančnih aplikacij

# 1) Zbiranje zahtev

Faza zbiranja zahtev vključuje dokumentacijo zahtev bodisi kot funkcionalne specifikacije bodisi kot primere uporabe. Zahteve zbirajo glede na potrebe strank in jih dokumentirajo strokovnjaki za bančništvo ali poslovni analitik.

Zbiranje zahtev

Strokovnjaki sodelujejo pri pisanju zahtev o več temah, saj ima bančništvo več poddomen, ena polnopravna bančna aplikacija pa bo integracija vseh teh domen.

Na primer, Bančna aplikacija ima lahko ločene module za nakazila, kreditne kartice, poročila, račune posojil, plačila računov, trgovanje itd.

# 2) Pregled zahtev

Rezultat zbiranja zahtev pregledajo vse zainteresirane strani, kot so inženirji za zagotavljanje kakovosti, razvojni vodje in analitiki vrstniških poslov.

Pregled zahtev

Navzkrižno preverijo, ali je kršen niti obstoječi potek dela niti novi potek dela. Vse zahteve so preverjene in potrjene. Nadaljnja dejanja in revizije dokumentov zahtev se izvajajo na podlagi istega.

# 3) Priprave na poslovni scenarij

V tej fazi inženirji QA iz scenarijev zahtev zahtevajo poslovne scenarije (specifikacije funkcij ali primeri uporabe); Poslovni scenariji so sestavljeni tako, da so zajete vse poslovne zahteve. Poslovni scenariji so scenariji na visoki ravni brez podrobnih korakov.

Nadalje te poslovne scenarije pregledajo poslovni analitiki, da se zagotovi izpolnjevanje vseh poslovnih zahtev. BA-jem je lažje pregledati scenarije na visoki ravni, kot pa podrobne primere preizkusov na nizki ravni.

Na primer , kupec, ki odpre fiksni depozit na digitalnem bančnem vmesniku, je lahko poslovni scenarij. Podobno imamo lahko različne poslovne scenarije, povezane z ustvarjanjem neto bančnih računov, spletnimi depoziti, spletnimi prenosi itd.

# 4) Funkcionalno preskušanje

V tej fazi se izvede funkcionalno testiranje in izvedejo se običajne dejavnosti testiranja programske opreme, kot so:

Priprava testnega primera: V tej fazi testni primeri izhajajo iz poslovnih scenarijev, en poslovni scenarij vodi do več pozitivnih in negativnih testnih primerov. Na tej stopnji se na splošno uporabljajo orodja Microsoft Excel, Test Director ali Center za kakovost.

Pregled testnega primera: Ocene inženirjev QA

Testni primer Izvedba: Izvajanje testnih primerov je lahko ročno ali samodejno z orodji, kot so QC, QTP itd.

Funkcionalno testiranje bančne aplikacije se precej razlikuje od običajnega testiranja programske opreme. Ker te aplikacije delujejo z denarjem stranke in občutljivimi finančnimi podatki, jih je treba temeljito preizkusiti. Nobenega pomembnega poslovnega scenarija ne bi smeli zajeti.

Tudi vir kakovosti, ki preizkuša aplikacijo, bi moral imeti osnovno znanje o bančništvu.

# 5) Testiranje zbirke podatkov

Bančna aplikacija vključuje zapletene transakcije, ki se izvajajo tako na ravni uporabniškega vmesnika kot na ravni baze podatkov, zato je testiranje baze podatkov enako pomembno kot funkcionalno testiranje. Baza podatkov je zapletena in popolnoma ločena plast v aplikaciji, zato njeno testiranje izvajajo strokovnjaki za baze podatkov. Uporablja tehnike, kot so:

  • Nalaganje podatkov
  • Selitev zbirke podatkov
  • Testiranje sheme DB in podatkovnih tipov
  • Testiranje pravil
  • Testiranje shranjenih postopkov in funkcij
  • Testiranje sprožilcev
  • Celovitost podatkov

Glavni namen testiranja baz podatkov je zagotoviti, da:

  • Aplikacija lahko shranjuje in pridobiva podatke iz baze podatkov brez izgube podatkov.
  • Dokončane transakcije je treba zavezati in prekinjene transakcije vrniti nazaj, da se prepreči kakršno koli neskladje med shranjenimi podatki.
  • Dostop do baze podatkov in osnovnih tabel je dovoljen le pooblaščenim aplikacijam in uporabnikom.

Obstajajo predvsem trije načini testiranja zbirke podatkov:

  • Strukturno preskušanje
  • Funkcionalno preskušanje
  • Nefunkcionalno preskušanje

Strukturno preskušanje

Vključuje testiranje predmetov baze podatkov, kot so baze podatkov, shema, tabele, pogledi, sprožilci, nadzor dostopa itd. Zagotavljanje, da so podatkovni tipi v tabelah sinhronizirani z ustreznimi spremenljivkami v aplikaciji. Preverjanje podatkov in referenčne integritete v tabelah.

Na primer, Polje zneska v aplikaciji mora imeti v tabeli podatkovni tip decimalno / float.

- Za izpolnjevanje standardov je treba uporabnikom omogočiti nadzor dostopa prek pogledov.

Funkcionalno preskušanje

Vključuje testiranje baz podatkov, ki ustrezajo uporabniškim zahtevam. Obstajata dva načina: testiranje črne škatle in testiranje bele škatle.

Na primer, Ko opravimo spletno nakazilo denarja, je treba račun pošiljatelja bremeniti, račun prejemnika pa knjižiti z enakim zneskom. Če transakcija ne uspe, je treba celotne transakcije razveljaviti, računa pošiljatelja pa ne bremeniti ali pripisati nazaj.

Nefunkcionalno preskušanje

Vključuje testiranje obremenitve in obremenitve ter optimizacijo zmogljivosti. Testiranje obremenitve pomaga pri prepoznavanju največjega števila transakcij, ki jih je mogoče izvesti hkrati, ne da bi to vplivalo na delovanje baze podatkov.

Na primer, Na podlagi prispevkov iz obremenitve in testiranja izjemnih situacij se lahko bančne aplikacije odločijo, da bodo svojim aplikacijam dodale več virov med največjim delovnim časom in zmanjšale vire med izven delovnega časa. To pomaga banki, da optimalno izkoristi vire in prihrani denar.

# 6) Testiranje varnosti

Testiranje varnosti je ponavadi zadnja faza preskusnega cikla. Predpogoj za začetek varnostnega preskušanja je dokončanje funkcionalnega in nefunkcionalnega preskušanja. Testiranje varnosti je ena glavnih faz celotnega cikla testiranja aplikacij, saj ta stopnja zagotavlja skladnost aplikacije z zveznimi in industrijskimi standardi.

Zaradi narave podatkov, ki jih prenašajo, so bančne aplikacije zelo občutljive in so glavna tarča hekerjev in goljufivih dejavnosti. Varnostno preskušanje zagotavlja, da aplikacija nima takšne spletne ranljivosti, ki bi lahko izpostavila občutljive podatke vsiljivcu ali napadalcu. Zagotavlja tudi, da je aplikacija v skladu s standardi, kot je OWASP.

V tej fazi je glavna naloga pregled celotne aplikacije, ki se izvede z orodji, kot je IBM AppScan ali HP WebInspect (to so najbolj priljubljena orodja).

Ko je skeniranje končano, se objavi poročilo o skeniranju. V tem poročilu se filtrirajo lažni pozitivni učinki, preostale ranljivosti pa se sporočijo razvojni skupini, da začnejo odpravljati težave, odvisno od resnosti posamezne težave.

V tem koraku se opravi tudi preizkus penetracije, da se razkrije širjenje napak. Strogo testiranje varnosti bi bilo treba opraviti na vseh platformah, omrežjih in OS.

Nekateri drugi Ročna orodja za preskušanje varnosti uporabljeni so Paros proxy , Http Watch , Apartma Burp , in Utrdite.

Glavni namen varnostnega preizkušanja je določiti morebitne ranljivosti, ki jih ima programska aplikacija.

Varnostno preskušanje preizkuša aplikacijo glede na:

  • Vsak zunanji napad ali poskus vdora v aplikacijo z zlonamernim namenom.
  • Vsako vrzel v programski aplikaciji bi lahko izkoristila in povzročila izgubo podatkov ali denarja.
  • Vse ranljivosti v omrežju, strežnikih in delovnih postajah, ki gostijo aplikacijo.

Sledijo različne vrste varnostnih preizkusov:

Testiranje ranljivosti: Razvit in izveden je avtomatiziran program za preverjanje različnih ranljivosti.

Varnostno skeniranje: Ta varianta se vrti okoli preiskovanja ranljivosti omrežja in sistema ter ponuja rešitve za zmanjšanje s tem povezanega tveganja.

Testiranje penetracije: Ta različica varnostnega preizkušanja posnema poskus vdora v zajetje ranljivosti in vrzeli, ki bi sicer lahko imele dostop do baze podatkov ali podatkov aplikacije.

Revizija varnosti: Vključuje revizijo aplikacije in povezanih omrežij zaradi morebitnih varnostnih izpadov.

Ocena tveganja: Ta različica naredi analizo za oceno stopnje tveganja v primeru, ko je ranljivost ali vrzel izkoriščena zaradi zlonamernih namenov. Takšno tveganje bi lahko razvrstili na nizko, srednje in visoko. Glede na stopnjo tveganja preskusna skupina svetuje ustrezne ukrepe za zmanjšanje ali preprečitev tveganja.

Etično vdiranje: To izvaja organizacija na svojih sistemih, da prepozna vrzeli, ki bi jih lahko izkoristili v svoji aplikaciji ali omrežju. Namen tovrstnega vdora ni ukrasti ali povzročiti škode v aplikaciji ali omrežju.

Ocena drže telesa: To je krovna ocena, ki jo sestavljajo varnostno skeniranje, ocene tveganja in etično vdiranje.

Vbrizgavanje SQL: SQL Injection je mogoče uporabiti za dostop do strežniške baze podatkov. Testiranje se opravi, da se zagotovi pravilno delovanje kode, ki izvaja poizvedbe v zbirki podatkov na podlagi naslednjih vnosov uporabnika:

  • Nosilci
  • Apostrofi
  • Vejice
  • Narekovaji

Druge faze preizkušanja aplikacije BFSI

Poleg zgornjih glavnih stopenj so morda vključene različne stopnje, kot so integracijsko testiranje, testiranje uporabnosti, testiranje sprejemljivosti uporabnikov in testiranje učinkovitosti.

Pogovorimo se na kratko tudi o teh fazah:

Integracijsko testiranje

Kot veste, da lahko v bančni aplikaciji obstaja več različnih modulov, kot so prenosi, plačila računov, depoziti itd. Tako je razvitih veliko komponent. Pri integracijskem testiranju so bili vsi sestavni deli integrirani in potrjeni.

Testiranje uporabnosti

Testiranje uporabnosti

Bančna aplikacija služi najrazličnejšim strankam. Nekaterim od teh strank morda primanjkuje spretnosti in zavedanja, potrebnih za izvajanje bančnih nalog v aplikaciji.

Tako bi bilo treba bančno aplikacijo preizkusiti za preprosto in učinkovito zasnovo, da bi bila uporabna za različne skupine strank. Enostavnejši in enostavnejši vmesnik je, večje število strank bo imelo koristi od bančne aplikacije.

Gre za preučevanje stopnje enostavnosti, ki jo imajo pri uporabi aplikacije poslovni uporabniki ali kupci bank. Tega testiranja ne izvede razvijalec ali preizkuševalec, ampak ga opravijo poslovni uporabniki.

Na primer, Danes vsi uporabljajo mobilne aplikacije. Aplikacija za bančništvo mora biti uporabniku prijazna in jo je končni uporabnik enostavno razumeti in uporabljati.

Vrste preizkušanja uporabnosti

Primerjalno testiranje uporabnosti: To je primerjalno testiranje, kjer je enostavnost uporabnosti ene spletne strani ali aplikacije z drugo. Cilj takšnega testiranja je zagotoviti najboljšo uporabniško izkušnjo.

Raziskovalno testiranje uporabnosti: Cilj tega testiranja je ugotoviti, katere funkcije mora imeti nova aplikacija ali programska oprema, da bo lahko izpolnila zahteve strank banke.

Sledijo prednosti in slabosti preizkušanja uporabnosti

odprtokodni operacijski sistemi za pc

Prednosti:

  • Končni uporabniki aplikacije so običajno vključeni v testiranje, zato se pridobijo povratne informacije iz prve roke.
  • Namesto da bi porabili čas za analizo in razprave o lastnostih, ki bi jih moral imeti izdelek, je bolje, da vhodne podatke pridobite neposredno od končnega uporabnika.
  • Morebitne težave lahko predhodno odkrijemo.

Slabosti:

  • Ker je v testiranje vključenih več končnih uporabnikov, lahko njihova mnenja, če niso natančna, vplivajo na zahtevo.
  • Na vir končnih uporabnikov lahko vplivajo.

Testiranje učinkovitosti

Določena obdobja, kot so plač, konec poslovnega leta, praznični časi, lahko privedejo do sprememb ali povečajo običajni promet v aplikaciji. Zato je treba opraviti temeljito preizkušanje zmogljivosti, da kupci ne bodo prizadeti zaradi napak v delovanju.

Pomemben primer iz preteklosti, ko so bili bančni kupci osebno prizadeti zaradi neuspešnega poslovanja, je izpad IT NatWest in RBS v ponedeljek, ko so stranke imele debetno in kreditno kartico zavrnjene transakcije v trgovinah v državi.

Preizkus sprejemljivosti uporabnika

To se naredi tako, da se vključijo končni uporabniki, da se zagotovi skladnost aplikacije z realnimi scenariji in jo bodo uporabniki sprejeli, če bo objavljena.

V današnjem scenariju večina bančnih projektov uporablja : Metodologije Agile / Scrum, RUP in Continuous Integration ter paketi Tools, kot so Microsoftovi VSTS in Rational Tools.

Kot smo že omenili glede RUP, RUP pomeni Rational Unified Process, ki je iterativna metodologija razvoja programske opreme, ki jo je uvedel IBM in obsega štiri faze, v katerih se izvajajo razvojne in preskusne dejavnosti.

Štiri faze so
i) Začetek
ii) Sodelovanje
iii) Gradbeništvo in
iv) Prehod

RUP široko vključuje orodja IBM Rational.

Vzorčni primeri primerov za bančništvo

Testni primeri za New Branch

  • Ustvarite novo vejo z veljavnimi in neveljavnimi testnimi podatki.
  • Ustvarite novo vejo brez podatkov.
  • Ustvarite novo vejo z obstoječimi podatki o vejah.
  • Preverite možnosti ponastavitve in preklica.
  • Podrobnosti o veji posodobite z veljavnimi in neveljavnimi testnimi podatki.
  • Podrobnosti o podružnicah posodobite z obstoječimi podatki o preizkusu podružnice.
  • Preverite, ali je novo vejo mogoče shraniti.
  • Preverite, ali možnost preklica deluje.
  • Preverite brisanje vej z odvisnostmi in brez njih.
  • Preverite, ali možnost iskanja podružnic deluje.

Testni primeri za novo vlogo

  • Ustvarite novo vlogo z veljavnimi in neveljavnimi testnimi podatki.
  • Ustvarite novo vlogo brez podatkov.
  • Preverite, ali je z obstoječimi testnimi podatki mogoče ustvariti novo vlogo.
  • Preverite opis vloge in vrste vlog.
  • Preverite, ali možnost preklica in ponastavitve deluje.
  • Preverite postopek brisanja vloge z odvisnostjo in brez nje.
  • Preverite povezave na strani s podrobnostmi o vlogi.
  • Preverite prijavo skrbnika brez testnih podatkov.
  • Preverite vse domače povezave za skrbniško vlogo.
  • Preverite, ali lahko skrbnik spremeni geslo z veljavnimi in neveljavnimi testnimi podatki.
  • Preverite skrbniško odjavo uspešno.

Testni primeri za stranke in bankirje

  • Preverite, ali vse povezave za obiskovalce in stranke delujejo pravilno.
  • Potrdite prijavo stranke z veljavnimi in neveljavnimi testnimi podatki.
  • Potrdite prijavo stranke brez podatkov.
  • Preverite prijavo bankirja brez podatkov.
  • Preverite bankovno prijavo z veljavnimi ali neveljavnimi testnimi podatki.
  • Preverite, ali se stranka ali bankir lahko uspešno odjavi.

Testni primeri za nove uporabnike

  • Preverite, ali je novega uporabnika mogoče ustvariti z veljavnimi in neveljavnimi testnimi podatki.
  • Ustvarite novega uporabnika z obstoječimi podatki o preizkusu vej
  • Preverite, ali možnost preklica in ponastavitve deluje pravilno.
  • Posodobite podatke o uporabniku z veljavnimi in neveljavnimi testnimi podatki.
  • Preverite izbris novega uporabnika.
  • preverite, ali je novega uporabnika mogoče preveriti.
  • Preverite obvezne vhodne parametre.
  • Preverite neobvezne vhodne parametre.
  • Preverite, ali je uporabnika mogoče ustvariti brez izbirnih parametrov.

Testni primeri za ustvarjanje novega računa

  • Ustvarite nov račun z veljavnimi in neveljavnimi uporabniškimi podatki.
  • Preverite, ali je mogoče posodobiti uporabniške podatke.
  • Preverite, ali je novega uporabnika mogoče shraniti.
  • Ustvarite nov račun z obstoječimi podatki uporabnika.
  • Preverite, ali lahko uporabnik znesek položi na novo ustvarjeni račun (in posodobi stanje).
  • Preverite, ali lahko uporabnik dvigne znesek z novega računa (po položitvi in ​​posodobitvi stanja).
  • V primeru plače račun preveri ime podjetja in druge podatke navede uporabnik.
  • Preverite, ali je v primeru sekundarnega računa navedena številka primarnega računa.
  • Preverite podatke o uporabniku, ki so na voljo v primerih trenutnega računa.
  • V primeru skupnega računa preverite predložena dokazila za skupni račun.
  • Preverite, ali lahko vzdržujete ničelno stanje na računu plač.
  • Preverite, ali lahko obdržite ničelno stanje ali minimalno stanje za račun brez plač.
  • Preverite, ali se lahko novi uporabnik uspešno odjavi.

Preizkusni primeri za uporabo neto bančništva

  • Preverite, ali lahko uporabnik odpre spletno stran banke.
  • Preverite, ali vse povezave na spletnem mestu delujejo.
  • Preverite, ali lahko uporabnik ustvari nov račun.
  • Preverite, ali se uporabnik lahko prijavi z veljavnim in neveljavnim uporabniškim imenom in geslom.
  • Preverite, ali je uporabniško ime ali geslo med prijavo prazno, uporabnik ne sme imeti dovoljenja za prijavo in prikaže se opozorilno sporočilo.
  • Preverite, ali lahko uporabnik spremeni geslo.
  • Če je vnesen neveljaven uporabnik ali geslo, se prikaže pravilno sporočilo o napaki.
  • Uporabniki z neveljavnim geslom se ne smejo prijaviti.
  • Prepričajte se, da se mora uporabniku po večkratnih poskusih prijave z napačnim geslom prikazati sporočilo o napaki in ga blokirati.
  • Preverite, ali lahko uporabnik izvede nekatere osnovne transakcije.
  • Preverite, ali lahko uporabnik doda upravičenca z veljavnimi in neveljavnimi podrobnostmi.
  • Preverite, ali lahko uporabnik izbriše upravičenca.
  • Preverite, ali lahko uporabnik izvaja transakcije z novo dodanim upravičencem.
  • Po transakciji preverite, ali so računi uporabnika in upravičenca posodobljeni.
  • Preverite, ali lahko uporabnik vnese znesek v decimalni številki.
  • Preverite, ali uporabnik v polje zneska ne more vnesti negativnih števil.
  • Preverite, ali lahko uporabnik opravlja transakcije z minimalnim stanjem ali brez njega.
  • Preverite, ali lahko uporabnik naredi nov RD.
  • Preverite, ali je pravilno sporočilo prikazano v primeru transakcije, opravljene z nezadostnim stanjem.
  • Pred izvedbo kakršne koli transakcije preverite, ali je uporabnik pozvan za potrditev.
  • Preverite, ali je za vsako uspešno transakcijo na voljo potrdilo o prejemu.
  • Preverite, ali lahko uporabnik nakaže denar na več računov.
  • preverite, ali lahko uporabnik prekliče transakcijo.
  • Preverite, ali podatki o računu odražajo tudi opravljene finančne transakcije.
  • Preverite, ali je funkcija časovne omejitve uporabljena.
  • preverite, ali se mora uporabnik v primeru izteka seje znova prijaviti.
  • preverite, ali je opravljena ustrezna časovna omejitev seje, če pride do kakršne koli neaktivnosti.
  • preverite, ali je uporabnik med izvajanjem transakcije premeščen v varni način.
  • Preverite, ali se lahko uporabnik uspešno odjavi.
  • Preverite možnosti iskanja in ponastavitve.

Zaključek

V tem članku smo razpravljali kako zapletena bi bila lahko bančna aplikacija in kaj so tipične faze preizkušanja aplikacije . Poleg tega smo razpravljali tudi o trenutnih trendih, ki jim sledijo IT panoge, vključno z metodologijami in orodji za razvoj programske opreme.

Vas prosimo, da delite svoje izkušnje ali vprašanja o tej temi!

Priporočeno branje

^