Meni

Kako testirati aplikacije bankarskih domena: Cjelovit BFSI vodič za testiranje

how test banking domain applications

Isprobajte Naš Instrument Za Uklanjanje Problema

Cjelovit vodič za testiranje bankarske prijave: BFSI (bankarstvo, financijske usluge i osiguranje) postupak testiranja i savjeti

Bankarske aplikacije jedna su od najsloženijih aplikacija u današnjoj industriji razvoja i testiranja softvera.

Što bankarske aplikacije čini tako složenima? Koji pristup treba slijediti za testiranje složenih tijekova rada koji su uključeni u bankarske aplikacije?

U ovom ćemo članku istaknuti različite faze i tehnike uključene u testiranje bankarskih aplikacija.

Kako testirati bankarske aplikacije

Što ćete naučiti:

Kako testirati bankarske aplikacije?

Razne funkcije koje obavljaju bankarske aplikacije su:

Funkcije banaka

Prvo shvatimo karakteristike bankarske prijave:

  • Višerazinska funkcionalnost za podršku tisućama istodobnih korisničkih sesija
  • Velike integracije: Bankarska se aplikacija obično integrira s brojnim drugim aplikacijama poput uslužnog programa Bill Pay i trgovačkih računa
  • Složeni poslovni tijekovi rada
  • Obrada u realnom vremenu i serija
  • Visoka stopa transakcija u sekundama
  • Sigurne transakcije
  • Odjeljak robusnog izvještavanja za praćenje svakodnevnih transakcija
  • Snažna revizija za rješavanje problema s kupcima
  • Masivni sustav za pohranu
  • Upravljanje katastrofama / oporavkom.

Gore navedenih deset točaka su najvažnije karakteristike bankarske aplikacije.

Bankarske aplikacije imaju više nivoa uključenih u obavljanje operacije.

Na primjer , do Zahtjev za bankarstvo može imati:

  • Web poslužitelj za interakciju s krajnjim korisnicima putem preglednika
  • Srednji nivo za provjeru ulaznih i izlaznih podataka web poslužitelja
  • DataBase za pohranu podataka i postupaka
  • Procesor za transakcije koji može biti glavni kapacitet velikog računala ili bilo koji drugi naslijeđeni sustav za provođenje bilijuna transakcija u sekundi.

Ako govorimo o testiranju bankovnih aplikacija, to zahtijeva Metodologija testiranja od kraja do kraja koja uključuje više tehnika testiranja softvera kako bi se osiguralo:

  • Ukupna pokrivenost svih bankarskih tijekova rada i poslovnih zahtjeva
  • Funkcionalni aspekt aplikacije
  • Sigurnosni aspekt aplikacije
  • Integritet podataka
  • Konkurencija
  • Korisničko iskustvo

Što bankarske aplikacije čini tako složenima?

  • Bankarski softver uglavnom se bavi povjerljivim financijskim podacima, tako da izvedba softvera treba biti bez pogrešaka i sigurna.
  • Programeri preferiraju složeni dizajn za razvoj ovih aplikacija kako bi osigurali da aplikacija radi na željeni siguran način.
  • Bankarstvo je svijet koji se neprestano mijenja. Danas je bankarstvo klijentu dostupno putem različitih kanala poput filijala, bankomata, internetskog bankarstva i brige o kupcima.
  • Pojavom tehnologije mnogi su novčanici preplavili tržišta koja se povezuju s bankarskim sustavima za financijske transakcije.
  • Očekuje se i bankarstvo koje će raditi i raditi 24 X 7 s visokim performansama. Nadogradnje softvera, trenutni popravci itd. Ne smiju utjecati na ovu dostupnost.
  • Na bankarski svijet također su pod velikim utjecajem stalne promjene koje je vlada uvela u obliku bankarskih propisa. Sve promjene u poreznoj strukturi utječu i na bankarski sustav.
  • Bankarski sustav također mora biti ažuriran što se tiče novih tehnologija. Analitika podataka poput Obrade velikih podataka i izvlačenja instinkta iz velikih podataka pomoću Data Sciencea raste u bankarskom svijetu.

Gore spomenute točke čine bankarski sustav složenim za programere kako bi oko njega stvorili softversku aplikaciju.

Važnost testiranja bankarske aplikacije

  • Testiranje aplikacije za bankarstvo osigurava da se sve aktivnosti ne samo dobro izvršavaju već i ostaju zaštićene i osigurane.
  • Softver za bankarstvo kompliciran je s tisućama ovisnosti, postupak testiranja zahtijeva više vremena, resursa i kontinuirano praćenje.
  • Kako su ovdje uključene financije, smjernice se moraju strogo poštivati. I testeri i programeri trebali bi imati dobro znanje domene.
  • Ono što je najvažnije, mora se osigurati da se zakoni i propisi pravilno provode u financijskim transakcijama. To se može osigurati samo testiranjem.
  • Također je važno osigurati da aplikacija i infrastruktura na kojoj je aplikacija postavljena mogu podnijeti opterećenje, posebno tijekom vršnog radnog vremena, bez nanošenja smetnji. To se može osigurati provođenjem ispitivanja performansi.
  • U današnjem digitalnom svijetu jedna stvar koja se tiče svih je sigurnost. Bankovne aplikacije i financijske transakcije koje se unutar nje obavljaju moraju biti sigurne od svakog pokušaja provale. To se može osigurati provođenjem sigurnosnih ispitivanja. Ispitivanje sigurnosti pomaže u provođenju industrijskih standarda kako bi se osigurale financijske transakcije.
  • Također je važno osigurati da se različiti moduli bankarske aplikacije i pravilno integriraju i postignu ciljevi klijenta. Ispitivanje integracije sustava pomaže u postizanju ovog zadatka.

Tok rada za testiranje bankarskih aplikacija

Tipične faze ispitivanja bankarskih aplikacija prikazani su u donjem tijeku rada. Razgovarat ćemo o svakoj fazi pojedinačno.

Ovo je model vodopada za testiranje aplikacije.

Testiranje bankarskih aplikacija

# 1) Prikupljanje zahtjeva

Faza okupljanja zahtjeva uključuje dokumentiranje zahtjeva bilo kao funkcionalne specifikacije ili kao slučajeve uporabe. Zahtjevi se prikupljaju prema potrebama kupaca i dokumentiraju bankarski stručnjaci ili poslovni analitičari.

Skupljanje zahtjeva

Stručnjaci su uključeni u pisanje zahtjeva za više od jedne teme, jer samo bankarstvo ima više poddomena, a jedna punopravna bankarska aplikacija bit će integracija svih tih domena.

Na primjer, Bankarska aplikacija može imati zasebne module za transfere, kreditne kartice, izvještaje, račune zajma, plaćanja računa, trgovanje itd.

# 2) Pregled zahtjeva

Isporuku Prikupljanja zahtjeva pregledavaju sve zainteresirane strane, poput QA inženjera, razvojnih potencijalnih kupaca i ravnopravnih poslovnih analitičara.

Pregled zahtjeva

Unakrsno provjeravaju da li se krši niti postojeći tijek posla niti novi tijek rada. Svi su zahtjevi provjereni i potvrđeni. Daljnje radnje i revizije dokumenata zahtjeva vrše se na temelju istih.

# 3) Pripreme za poslovni scenarij

U ovoj fazi QA inženjeri izvode poslovne scenarije iz potrebnih dokumenata (specifikacije funkcija ili slučajevi korištenja); Poslovni scenariji izvedeni su na takav način da su pokriveni svi poslovni zahtjevi. Poslovni scenariji su scenariji na visokoj razini bez detaljnih koraka.

Nadalje, ovi poslovni scenariji pregledavaju poslovne analitičare kako bi se osiguralo da su ispunjeni svi poslovni zahtjevi. BA-ima je lakše pregledati scenarije visoke razine, a ne detaljne slučajeve ispitivanja niske razine.

Na primjer , kupac koji otvori fiksni depozit na sučelju digitalnog bankarstva može biti poslovni scenarij. Slično tome, možemo imati različite poslovne scenarije koji se odnose na stvaranje neto bankarskih računa, mrežne depozite, mrežne transfere itd.

# 4) Funkcionalno ispitivanje

U ovoj se fazi izvodi funkcionalno testiranje i izvode se uobičajene aktivnosti testiranja softvera, kao što su:

Priprema test slučaja: U ovoj fazi test slučajevi su izvedeni iz poslovnih scenarija, jedan poslovni scenarij dovodi do nekoliko pozitivnih i negativnih test slučajeva. Općenito, alati koji se koriste u ovoj fazi su Microsoft Excel, direktor testa ili Centar za kvalitetu.

Pregled testnog slučaja: Recenzije vršnjačkih QA inženjera

Test slučaj Izvršenje: Izvršenje testnog slučaja može biti ručno ili automatski uključujući alate poput QC, QTP itd.

Funkcionalno testiranje bankarske aplikacije sasvim se razlikuje od uobičajenog testiranja softvera. Budući da ove aplikacije rade s novcem kupca i osjetljivim financijskim podacima, moraju se temeljito testirati. Nijedan važan poslovni scenarij ne bi smio biti pokriven.

Također, QA resurs koji testira aplikaciju trebao bi imati osnovno znanje o bankarskoj domeni.

# 5) Ispitivanje baze podataka

Bankarska aplikacija uključuje složenu transakciju koja se izvodi na razini korisničkog sučelja i na razini baze podataka, stoga je testiranje baze podataka jednako važno kao i funkcionalno testiranje. Baza podataka je komplicirana i u potpunosti zaseban sloj u aplikaciji, tako da njezino testiranje provode stručnjaci za baze podataka. Koristi tehnike poput:

  • Učitavanje podataka
  • Migracija baze podataka
  • Testiranje DB sheme i tipova podataka
  • Ispitivanje pravila
  • Testiranje pohranjenih postupaka i funkcija
  • Okidači za testiranje
  • Integritet podataka

Glavna svrha testiranja baze podataka je osigurati da:

  • Aplikacija je u stanju pohraniti i dohvatiti podatke iz baze podataka bez gubitka podataka.
  • Završene transakcije trebaju se počiniti, a prekidane transakcije vraćaju se natrag kako bi se izbjegla neslaganja uskladištenih podataka.
  • Pristup bazi podataka i temeljnim tablicama dopušten je samo ovlaštenim aplikacijama i korisnicima.

Postoje primarno tri načina testiranja baze podataka:

  • Ispitivanje konstrukcije
  • Ispitivanje funkcionalnosti
  • Nefunkcionalno ispitivanje

Ispitivanje konstrukcije

Uključuje testiranje objekata baze podataka kao što su baze podataka, shema, tablice, pogledi, okidači, kontrole pristupa itd. Osiguravanje da su vrste podataka u tablicama sinkronizirane s odgovarajućim varijablama u aplikaciji. Provjera valjanosti podataka i referentnog integriteta u tablicama.

Na primjer, Polje iznosa u aplikaciji u tablici mora imati tip podataka decimalni / plutajući.

- Kako bi bili u skladu sa standardima, korisnici bi trebali dobiti kontrolu pristupa putem pogleda.

Ispitivanje funkcionalnosti

Uključuje testiranje baza podataka koje zadovoljavaju zahtjeve korisnika. Postoje dva načina za postizanje: testiranje crne kutije i testiranje bijele kutije.

Na primjer, Kada vršimo internetski prijenos novca, račun pošiljatelja treba teretiti, a račun primatelja treba uplatiti s potpuno istim iznosom. Ako transakcija ne uspije, cijele transakcije treba poništiti, a račun pošiljatelja ne treba teretiti niti vraćati natrag.

Nefunkcionalno ispitivanje

Uključuje ispitivanje opterećenja i naprezanja i optimizaciju izvedbe. Ispitivanje učitavanja pomaže u identificiranju najvećeg broja transakcija koje se mogu istodobno izvesti bez utjecaja na performanse baze podataka.

Na primjer, Na temelju podataka iz opterećenja i testiranja otpornosti na stres, bankarske aplikacije mogu odlučiti dodati više resursa svojoj aplikaciji tijekom najvećeg radnog vremena i smanjiti resurse tijekom izvan radnog vremena. To pomaže banci da optimalno koristi resurse i uštedi novac.

# 6) Ispitivanje sigurnosti

Ispitivanje sigurnosti obično je zadnja faza u ciklusu testiranja. Preduvjet za početak sigurnosnog testiranja je završetak funkcionalnog i nefunkcionalnog testiranja. Ispitivanje sigurnosti jedna je od glavnih faza u cijelom ciklusu testiranja aplikacija, jer ova faza osigurava da je aplikacija u skladu sa saveznim i industrijskim standardima.

Zbog prirode podataka koje nose, bankarske su aplikacije vrlo osjetljive i glavna su meta za hakere i lažne aktivnosti. Testiranje sigurnosti osigurava da aplikacija nema takvu mrežnu ranjivost koja može izložiti osjetljive podatke uljezu ili napadaču. Također osigurava da je aplikacija u skladu sa standardima poput OWASP-a.

U ovoj je fazi glavni zadatak cjelokupno skeniranje aplikacija koje se provodi pomoću alata poput IBM AppScan ili HP WebInspect (ovo su najpopularniji alati).

Po završetku skeniranja objavljuje se izvješće o skeniranju. Preko ovog izvješća, Lažni pozitivni učinci su filtrirani, a ostatak ranjivosti prijavljen je razvojnom timu kako bi počeli rješavati probleme ovisno o težini svakog problema.

U ovom se koraku također provodi penetracijsko ispitivanje kako bi se otkrilo širenje pogrešaka. Stroga sigurnosna ispitivanja trebala bi se provoditi na platformama, mrežama i OS-ima.

Neki drugi Ručni alati za sigurnosno ispitivanje koriste se Parosov proxy , Http Watch , Suite podrigivanja , i Utvrditi.

Glavna svrha sigurnosnog testiranja je utvrditi sve ranjivosti softverske aplikacije.

Testiranje sigurnosti testira aplikaciju na:

  • Svaki vanjski napad ili pokušaj hakiranja aplikacije sa zlonamjernom namjerom.
  • Svaka rupa u softverskoj aplikaciji može se iskoristiti što uzrokuje gubitak podataka ili novca.
  • Bilo koja ranjivost u mreži, poslužiteljima i radnim stanicama na kojima se nalazi aplikacija.

Slijede razne vrste sigurnosnih ispitivanja:

Ispitivanje ranjivosti: Razvijen je i izveden automatizirani program za provjeru različitih ranjivosti.

Sigurnosno skeniranje: Ova se varijanta vrti oko istraživanja ranjivosti mreže i sustava, pruža rješenja za smanjenje povezanog rizika.

Ispitivanje prodiranja: Ova varijanta sigurnosnog testiranja oponaša pokušaj hakiranja kako bi se uhvatile ranjivosti i rupe, koje bi inače mogle dobiti pristup bazi podataka ili podacima aplikacije.

Revizija sigurnosti: Uključuje reviziju aplikacije i povezanih mreža radi bilo kakvih sigurnosnih propusta.

Procjena rizika: Ova varijanta vrši analizu za procjenu razine rizika u slučaju kada se ranjivost ili rupa iskorištavaju u svrhu zlonamjerne namjere. Takav bi se rizik mogao svrstati u niski, srednji i visoki. Na temelju razine rizika, ispitni tim savjetuje odgovarajuće mjere kako bi se rizik smanjio ili izbjegao.

Etičko hakiranje: To izvodi organizacija na svojim sustavima kako bi identificirala rupe koje bi se mogle iskoristiti u njezinoj aplikaciji ili mreži. Namjera ove vrste hakiranja nije krađa ili nanošenje štete aplikaciji ili mreži.

Procjena držanja tijela: Ovo je krovna procjena koja se sastoji od sigurnosnog skeniranja, procjene rizika i etičkog hakiranja.

SQL ubrizgavanje: SQL Injection se može koristiti za dobivanje pristupa poslužiteljskoj bazi podataka. Testiranje se vrši kako bi se osiguralo da kôd radi ispravno, a koji izvršavaju upite u bazi podataka na temelju sljedećih podataka korisnika:

  • Zagrade
  • Apostrofi
  • Zarezi
  • Navodnici

Ostale faze testiranja aplikacije BFSI

Osim gore navedenih glavnih faza, mogu biti uključene različite faze, poput integracijskog testiranja, testiranja upotrebljivosti, korisničkog testiranja i testiranja performansi.

Razgovarajmo ukratko i o ovim fazama:

Integracijsko ispitivanje

Kao što znate da u bankarskoj aplikaciji može postojati nekoliko različitih modula poput prijenosa, plaćanja računa, depozita itd. Dakle, postoji mnogo razvijenih komponenata. U integracijskom testiranju sve su komponente integrirane i provjerene.

Ispitivanje upotrebljivosti

Ispitivanje upotrebljivosti

Bankarska aplikacija služi širokom spektru klijenata. Nekim od tih kupaca možda nedostaju vještine i svijest potrebne za obavljanje bankarskih zadataka putem aplikacije.

Stoga bi bankarsku aplikaciju trebalo testirati na jednostavan i učinkovit dizajn kako bi bila upotrebljiva u različitim skupinama klijenata. Jednostavnije i jednostavno za korištenje sučelje, veći će broj klijenata imati koristi od bankarske aplikacije.

Riječ je o ispitivanju razine lakoće koju poslovni korisnici ili klijenti banaka imaju u korištenju aplikacije. Ovo testiranje ne provodi programer ili ispitivač, već ga provode poslovni korisnici.

Na primjer, Danas svi koriste mobilne aplikacije. Aplikacija za bankarstvo trebala bi biti jednostavna za upotrebu i krajnja korisnika lako razumjeti i koristiti.

Vrste ispitivanja upotrebljivosti

Usporedno ispitivanje upotrebljivosti: Ovo je testiranje temeljeno na usporedbi, gdje je jednostavnost upotrebe jedne web stranice ili aplikacije s drugom. Cilj takvog testiranja je pružiti najbolje korisničko iskustvo.

Istraživanje upotrebljivosti: Cilj ovog testiranja je utvrditi koje značajke treba imati nova aplikacija ili softver kako bi udovoljila zahtjevima banke.

Slijede prednosti i nedostaci ispitivanja upotrebljivosti

što može reproducirati .swf datoteke

Prednosti:

  • Krajnji korisnici aplikacije obično su uključeni u testiranje, stoga se dobivaju povratne informacije iz prve ruke.
  • Umjesto trošenja vremena na analizu i raspravu o značajci koju proizvod treba imati ili ne, bolje je podatke dobiti od krajnjeg korisnika izravno.
  • Unaprijed možemo uhvatiti sve potencijalne probleme.

Mane:

  • Kako je u testiranje uključeno više krajnjih korisnika, njihova mišljenja ako nisu precizna mogu utjecati na zahtjev.
  • Na feed krajnjih korisnika može se utjecati.

Ispitivanje performansi

Određena vremenska razdoblja kao što su dan isplate, kraj financijske godine, blagdanska godišnja doba mogu donijeti promjene ili povećati uobičajeni promet na aplikaciji. Stoga bi trebalo provesti temeljito ispitivanje izvedbe kako kupci ne bi bili pogođeni neuspjesima u izvedbi.

Značajan primjer iz prošlosti u kojem su bankarski klijenti osobno pogođeni zbog neuspjeha u radu je prekid rada NatWesta i RBS-a u cyber ponedjeljku u kojem su klijenti imali debitnu i kreditnu karticu zbog odbijenih transakcija u trgovinama u zemlji.

Ispitivanje prihvaćanja korisnika

To se postiže uključivanjem krajnjih korisnika kako bi se osiguralo da je aplikacija u skladu sa stvarnim scenarijima i da će je korisnici prihvatiti ako krene s radom.

U današnjem scenariju koristi većina bankarskih projekata : Agile / Scrum, RUP i kontinuirana integracija metodologije i paketi Alati poput Microsoftovih VSTS i Rational Tools.

Kao što smo gore spomenuli o RUP-u, RUP je kratica od Rational Unified Process, koji je iterativna metodologija razvoja softvera koju je uveo IBM, a sastoji se od četiri faze u kojima se provode razvojne i ispitne aktivnosti.

Četiri su faze
i) Početni
ii) Suradnja
iii) Izgradnja i
iv) Prijelaz

RUP široko uključuje IBM Rational alate.

Primjeri testnih slučajeva za bankarsku aplikaciju

Test slučajevi za New Branch

  • Stvorite novu granu s važećim i nevaljanim testnim podacima.
  • Stvorite novu granu bez podataka.
  • Stvorite novu granu s postojećim podacima o grani.
  • Provjerite opcije resetiranja i otkazivanja.
  • Ažurirajte podatke o grani s važećim i nevaljanim testnim podacima.
  • Ažurirajte podatke o grani postojećim podacima o testiranju grana.
  • Provjerite može li se nova grana spremiti.
  • Provjerite radi li opcija otkazivanja.
  • Provjerite brisanje grane sa i bez ovisnosti.
  • Provjerite radi li opcija pretraživanja grana.

Ispitni slučajevi za novu ulogu

  • Stvorite novu ulogu s važećim i nevaljanim testnim podacima.
  • Stvorite novu ulogu bez podataka.
  • Provjerite može li se stvoriti nova uloga s postojećim testnim podacima.
  • Provjerite opis uloge i vrste uloga.
  • Provjerite radi li opcija otkazivanja i poništavanja.
  • Provjerite postupak brisanja uloge sa i bez ovisnosti.
  • Provjerite veze na stranici s pojedinostima o ulozi.
  • Provjerite administratorsku prijavu bez podataka o testiranju.
  • Potvrdite sve veze na kući za ulogu administratora.
  • Provjerite može li administrator promijeniti lozinku s važećim i nevaljanim testnim podacima.
  • Potvrdite uspješno odjavu administratora.

Test slučajevi za kupca i bankara

  • Provjerite rade li sve veze posjetitelja i kupaca ispravno.
  • Potvrdite prijavu kupca valjanim i nevaljanim testnim podacima.
  • Potvrdite prijavu kupca bez ikakvih podataka.
  • Potvrdite prijavu bankara bez ikakvih podataka.
  • Potvrdite prijavu bankara valjanim ili nevaljanim testnim podacima.
  • Provjerite može li se kupac ili bankar uspješno odjaviti.

Test slučajevi za nove korisnike

  • Provjerite može li se novi korisnik stvoriti s važećim i nevaljanim testnim podacima.
  • Stvorite novog korisnika s postojećim podacima o testiranju grana
  • Provjerite radi li opcija otkazivanja i poništavanja ispravno.
  • Ažurirajte podatke o korisniku s važećim i nevaljanim testnim podacima.
  • Potvrdite brisanje novog korisnika.
  • provjeriti može li se novi korisnik provjeriti.
  • Provjerite obvezne ulazne parametre.
  • Provjerite neobavezne ulazne parametre.
  • Provjerite može li se korisnik stvoriti bez neobaveznih parametara.

Test slučajevi za stvaranje novog računa

  • Izradite novi račun s važećim i nevaljanim korisničkim podacima.
  • Provjerite mogu li se detalji korisnika ažurirati.
  • Provjerite može li se novi korisnik spremiti.
  • Izradite novi račun s podacima postojećeg korisnika.
  • Provjerite može li korisnik uplatiti iznos na novostvoreni račun (i ažurirati stanje).
  • Provjerite može li korisnik podići iznos s novog računa (nakon polaganja i ažuriranja stanja).
  • U slučaju plaće, korisnik provjerava naziv tvrtke i ostale pojedinosti.
  • Provjerite je li naveden primarni broj računa u slučaju sekundarnog računa.
  • Provjerite podatke o korisniku koji su navedeni u slučajevima tekućeg računa.
  • Provjerite dostavljene dokaze za zajednički račun u slučaju zajedničkog računa.
  • Provjerite je li u stanju održavati nulti saldo na računu plaće.
  • Provjerite je li u stanju održavati nulti saldo ili minimalni saldo za račun bez plaće.
  • Provjerite može li se novi korisnik uspješno odjaviti.

Ispitni slučajevi za primjenu mrežnog bankarstva

  • Provjerite je li korisnik u mogućnosti otvoriti web mjesto banke.
  • Provjerite rade li sve veze na web mjestu.
  • Provjerite je li korisnik u mogućnosti stvoriti novi račun.
  • Provjerite može li se korisnik prijaviti s važećim i nevaljanim korisničkim imenom i lozinkom.
  • Provjerite je li jedno od korisničkog imena ili lozinke prazno tijekom prijave, korisniku se ne smije dopustiti prijava i prikazuje se poruka upozorenja.
  • Provjerite može li korisnik promijeniti lozinku.
  • Ako je unesen nevažeći korisnik ili lozinka, prikazuje se odgovarajuća poruka o pogrešci.
  • Korisnicima s nevažećom lozinkom ne smije se dopustiti prijava.
  • Provjerite da bi nakon ponovljenih pokušaja prijave s netočnom lozinkom korisniku trebala biti prikazana poruka pogreške i blokiran.
  • Provjerite je li korisnik u mogućnosti izvršiti neke osnovne transakcije.
  • Provjerite je li korisnik u mogućnosti dodati korisnika s valjanim i nevaljanim detaljima.
  • Provjerite može li korisnik izbrisati korisnika.
  • Provjerite je li korisnik u mogućnosti izvršavati transakcije s novopostavljenim korisnikom.
  • Nakon transakcije provjerite jesu li računi korisnika i korisnika ažurirani.
  • Provjerite je li korisnik u stanju unijeti iznos u decimalnom broju.
  • Provjerite da li korisnik ne može unijeti negativne brojeve u polje za iznos.
  • Provjerite smije li korisnik obavljati transakcije sa ili bez minimalnog stanja.
  • Provjerite može li korisnik napraviti novi RD.
  • Provjerite je li prikazana ispravna poruka u slučaju transakcije obavljene s nedovoljnim saldom.
  • Provjerite traži li se od korisnika potvrdu prije bilo kakve transakcije.
  • Provjerite nalazi li se potvrda o primanju za svaku uspješnu transakciju.
  • Provjerite je li korisnik u mogućnosti prenijeti novac na više računa.
  • provjeriti može li korisnik otkazati transakciju.
  • Potvrdite da detalji računa odražavaju i financijske transakcije.
  • Provjerite je li primijenjena značajka vremenskog ograničenja.
  • provjerite mora li se korisnik u slučaju isteka sesije ponovno prijaviti.
  • provjerite je li napravljeno odgovarajuće vrijeme isteka sesije u slučaju neaktivnosti.
  • provjerite je li tijekom obavljanja transakcije korisnik prebačen u siguran način.
  • Provjerite može li se korisnik uspješno odjaviti.
  • Provjerite mogućnosti pretraživanja i resetiranja.

Zaključak

U ovom smo članku razgovarali koliko složena aplikacija za bankarstvo može biti i koji su tipične faze uključene u testiranje aplikacije . Osim toga, razgovarali smo i o trenutnim trendovima koje slijede IT industrije, uključujući metodologije i alate za razvoj softvera.

Slobodno podijelite svoje iskustvo ili upite o ovoj temi!

Preporučena literatura

^