Menu

Sådan tester du bankdomæneapplikationer: En komplet BFSI-testvejledning

how test banking domain applications

Prøv Vores Instrument Til At Fjerne Problemer

En komplet guide til afprøvning af bankansøgning: BFSI (Banking, Financial Services, and Insurance) Testproces og tip

Bankapplikationer er en af ​​de mest komplekse applikationer i nutidens softwareudvikling og testindustri.

Hvad gør bankansøgninger så komplekse? Hvilken tilgang skal følges for at teste de komplekse arbejdsgange, der er involveret i bankapplikationer?

I denne artikel vil vi fremhæve forskellige faser og teknikker, der er involveret i afprøvning af bankapplikationer.

Sådan tester du bankansøgninger

Hvad du lærer:

Sådan testes bankansøgninger?

Forskellige funktioner udført af bankansøgninger er:

Funktioner-af-banker

Lad os først kende egenskaberne ved en bankansøgning:

  • Multi-tier funktionalitet til at understøtte tusindvis af samtidige brugersessioner
  • Integration i stor skala: En bankapplikation integreres typisk med adskillige andre applikationer såsom Bill Pay-hjælpeprogrammet og handelskonti
  • Komplekse forretningsgange
  • Realtids- og batchbehandling
  • Den høje transaktionshastighed pr. Sekund
  • Sikre transaktioner
  • Robust rapporteringsafsnit for at holde styr på daglige transaktioner
  • Stærk revision til fejlfinding af kundeproblemer
  • Massivt opbevaringssystem
  • Katastrofe / opsving.

De ovennævnte ti punkter er de vigtigste egenskaber ved en bankapplikation.

Bankapplikationer har flere niveauer, der er involveret i udførelsen af ​​en operation.

For eksempel , til Bankansøgning kan have:

  • Webserver til at interagere med slutbrugere via browser
  • Middle Tier for at validere input og output til webserveren
  • DataBase til lagring af data og procedurer
  • Transaktionsprocessor, der kunne være en stor kapacitet Mainframe eller ethvert andet ældre system til at udføre billioner af transaktioner pr. Sekund.

Hvis vi taler om at teste bankapplikationer, kræver det en End-to-End-testmetode, der involverer flere softwaretestteknikker for at sikre:

  • Samlet dækning af alle bankarbejdsgange og forretningskrav
  • Det funktionelle aspekt af applikationen
  • Sikkerhedsaspektet ved applikationen
  • Dataintegritet
  • Samtidighed
  • Brugererfaring

Hvad gør bankansøgninger så komplekse?

  • Banksoftware beskæftiger sig primært med fortrolige økonomiske data, så softwarens ydeevne skal være fejlfri og sikker.
  • Udviklere foretrækker et kompliceret design for at udvikle disse applikationer for at sikre, at applikationen kører på en ønsket sikker måde.
  • Bank er en verden i konstant forandring. Bank, i dag, stilles til rådighed for kunden ved hjælp af forskellige kanaler som mur og mørtel filialer, pengeautomater, online bank og kundebehandling.
  • Med fremkomsten af ​​teknologi har mange tegnebøger oversvømmet markederne, der forbinder banksystemerne til finansielle transaktioner.
  • Bank forventes også at være i drift 24 X 7 med høj ydeevne. Softwareopgraderinger, øjeblikkelige rettelser osv. Kan ikke tillades at påvirke denne tilgængelighed.
  • Bankverdenen er også stærkt påvirket af de konstante ændringer, som regeringen medfører i form af bankbestemmelser. Eventuelle ændringer i skattestrukturen påvirker også banksystemet.
  • Banksystemet skal også ajourføres for så vidt angår nye teknologier. Dataanalyse som Big Data Processing og at få instinkter ud af big data ved hjælp af Data Science vokser trækkraft i bankverdenen.

Ovenstående punkter gør banksystemet komplekst for udviklere at oprette en softwareapplikation omkring det.

Betydningen af ​​at teste bankansøgning

  • Test af bankapplikationen sikrer, at alle aktiviteter ikke kun udføres godt, men også forbliver beskyttet og sikret.
  • Banksoftware er kompliceret med tusindvis af afhængigheder, testprocessen kræver mere tid, ressourcer og kontinuerlig overvågning.
  • Da økonomi er involveret, skal retningslinjer følges nøje. Både testere og udviklere skal have god domæne viden.
  • Vigtigst er det, at det skal sikres, at love og regler håndhæves korrekt i finansielle transaktioner. Dette kan kun sikres ved test.
  • Det er også vigtigt at sikre, at applikationen og infrastrukturen, som applikationen er implementeret på, er i stand til at håndtere belastningen, især i spidsbelastningstider, uden at forårsage nogen forstyrrelse. Dette kan sikres ved at udføre ydelsestest.
  • I nutidens digitale verden er den eneste ting, der vedrører alle, sikkerheden. Bankapplikationerne og de finansielle transaktioner, der udføres inden for det, skal være sikre mod ethvert forsøg på at bryde ind. Dette kan sikres ved at udføre sikkerhedstest. Sikkerhedstest hjælper med at håndhæve industristandarder til at sikre finansielle transaktioner.
  • Det er også vigtigt at sikre, at forskellige moduler i en bankapplikation og integreres ordentligt og nå klientens mål. Systemintegrationstest hjælper med at nå denne opgave.

Bankflow-test af arbejdsgang

Typiske faser involveret i afprøvning af bankapplikationer vises i nedenstående arbejdsgang. Vi vil diskutere hvert trin individuelt.

Dette er en vandfaldsmodel til test af en applikation.

Test af bankansøgninger

# 1) Kravsamling

Fase til indsamling af krav involverer dokumentation af krav enten som funktionelle specifikationer eller som brugstilfælde. Krav samles efter kundens behov og dokumenteres af bankeksperter eller forretningsanalytikere.

Kravindsamling

Eksperter er involveret i at skrive krav til mere end et emne, da bankvæsenet selv har flere underdomæner, og en fuldgyldig bankapplikation vil være integrationen af ​​alle disse domæner.

For eksempel, En bankapplikation kan have separate moduler til overførsler, kreditkort, rapporter, lånekonti, regning, betaling osv.

# 2) Kravsanmeldelse

Leveringen af ​​Requirement Gathering gennemgås af alle interessenter såsom QA Engineers, Development Leads og Peer Business Analysts.

Kravsanmeldelse

De krydstjekker, at hverken eksisterende forretningsarbejdsproces eller nye arbejdsgange overtrædes. Alle krav er verificeret og valideret. Opfølgningshandlinger og kravdokumentrevisioner udføres på samme måde.

# 3) Forberedelse af forretningsscenarier

I dette trin udleder QA-ingeniører forretningsscenarier fra kravdokumenterne (Funktionsspecifikationer eller Brugssager); Forretningsscenarier udledes på en sådan måde, at alle forretningskrav er dækket. Forretningsscenarier er scenarier på højt niveau uden detaljerede trin.

Desuden gennemgås disse forretningsscenarier af forretningsanalytikere for at sikre, at alle forretningskrav er opfyldt. Det er lettere for BA'er at gennemgå scenarier på højt niveau snarere end at gennemgå detaljerede testtilfælde på lavt niveau.

For eksempel , kan en kunde, der åbner et fast depositum på den digitale bankgrænseflade, være et forretningsscenarie. På samme måde kan vi have forskellige forretningsscenarier relateret til oprettelse af netbank-konto, onlineindskud, onlineoverførsler osv.

# 4) Funktionstest

I dette trin udføres funktionel test, og de sædvanlige softwaretestaktiviteter udføres som:

Forberedelse af testkasse: I dette trin stammer testtilfælde fra forretningsscenarier, et forretningsscenario fører til flere positive testsager og negative testsager. Generelt er værktøjer, der bruges i denne fase, Microsoft Excel, testdirektør eller kvalitetscenter.

Test sag gennemgang: Anmeldelser af peer QA Engineers

Test sag Udførelse: Testkørsel kan enten være manuel eller automatisk med værktøjer som QC, QTP osv.

Den funktionelle test af en bankapplikation adskiller sig meget fra almindelig softwaretest. Da disse applikationer fungerer med kundens penge og følsomme økonomiske data, skal de testes grundigt. Intet vigtigt forretningsscenarie skal overlades til at blive dækket.

Den QA-ressource, der tester applikationen, skal også have den grundlæggende viden om bankdomænet.

# 5) Databasetest

Bankansøgning involverer en kompleks transaktion, der udføres både på brugergrænsefladeniveau og databaseniveau. Derfor er databasetestning lige så vigtig som funktionel testning. Databasen er kompliceret og et helt separat lag i applikationen, og dens test udføres derfor af databasespecialister. Det bruger teknikker som:

  • Indlæsning af data
  • Databasemigration
  • Test af DB-skema og datatyper
  • Test af regler
  • Test af lagrede procedurer og funktioner
  • Test af udløsere
  • Dataintegritet

Hovedformålet med databasetest er at sikre, at:

  • Applikationen er i stand til at gemme og hente data fra databasen uden tab af data.
  • Gennemførte transaktioner skal begås, og afbrudte transaktioner tilbageføres for at undgå enhver uoverensstemmelse i lagrede data.
  • Kun autoriserede applikationer og brugere har adgang til databasen og de underliggende tabeller.

Der er primært tre måder til databasetestning:

  • Strukturel testning
  • Funktionel testning
  • Ikke-funktionel test

Strukturel testning

Det involverer test af databaseobjekter som databaser, skema, tabeller, visninger, udløsere, adgangskontrol osv. Sikring af, at datatyper i tabeller er synkroniseret med de tilsvarende variabler i applikationen. Validering af data og referenceintegritet i tabellerne.

For eksempel, Et beløbfelt i applikationen skal have en datatype decimal / float i tabellen.

- For at overholde standarder bør brugerne få adgangskontrol gennem visninger.

Funktionel testning

Det indebærer at teste de databaser, der opfylder brugernes krav. Der er to måder at opnå: test af sort boks og test af hvid boks.

For eksempel, Når vi foretager en online pengeoverførsel, skal afsenderkontoen debiteres, og modtagerkontoen krediteres nøjagtigt det samme beløb. Hvis transaktionen mislykkes, skal hele transaktioner tilbageføres, og afsenderkontoen skal ikke debiteres eller krediteres tilbage.

Ikke-funktionel test

Det involverer belastning og stresstest og ydeevneoptimering. Belastningstest hjælper med at identificere det mest antal transaktioner, der kan udføres samtidigt uden at påvirke databaseydelsen.

For eksempel, Baseret på input fra belastnings- og stresstestning kan bankapplikationer beslutte at tilføje flere ressourcer til deres applikation i spidsbelastningstimer og reducere ressourcerne uden for åbningstiden. Dette hjælper banken med at udnytte ressourcer optimalt og spare penge.

# 6) Sikkerhedstest

Sikkerhedstestning er normalt det sidste trin i testcyklussen. En forudsætning for at påbegynde sikkerhedstest er afslutningen af ​​funktionel og ikke-funktionel test. Sikkerhedstest er en af ​​de største faser i hele applikationstestcyklussen, da dette trin sikrer, at applikationen overholder føderale og industristandarder.

På grund af arten af ​​de data, de bærer, er bankapps meget følsomme og er et primært mål for hackere og falske aktiviteter. Sikkerhedstest sørger for, at applikationen ikke har en sådan websårbarhed, der kan udsætte følsomme data for en ubuden gæst eller en angriber. Det forsikrer også, at applikationen overholder standarder som OWASP.

I dette trin er den største opgave hele applikationsscanningen, der udføres ved hjælp af værktøjer som IBM AppScan eller HP WebInspect (disse er de mest populære værktøjer).

Når scanningen er afsluttet, offentliggøres scanningsrapporten. I løbet af denne rapport filtreres falske positive ud, og resten af ​​sårbarhederne rapporteres til udviklingsteamet, så de begynder at løse problemerne afhængigt af sværhedsgraden af ​​hvert problem.

Penetrationstest udføres også på dette trin for at afsløre udbredelsen af ​​fejl. Streng sikkerhedstestning skal udføres på tværs af platforme, netværk og OS.

Nogle andre Manuelle værktøjer til sikkerhedstest anvendte er Paros Proxy , Http Watch , Burp-suite og Forstærke.

Hovedformålet med sikkerhedstest er at lokalisere eventuelle sårbarheder, softwareapplikationen måtte have.

Sikkerhedstesten tester applikationen mod:

  • Ethvert eksternt angreb eller forsøg på at hacke applikationen med ondsindet hensigt.
  • Ethvert smuthul i softwareapplikationen kan udnyttes og forårsage data eller tab af penge.
  • Enhver sårbarhed i netværket, servere og arbejdsstationer, der er vært for applikationen.

Følgende er de forskellige typer sikkerhedstest:

Test af sårbarhed: Et automatiseret program er udviklet og udført for at kontrollere for forskellige sårbarheder.

Sikkerhedsscanning: Denne variant drejer sig om at undersøge netværks- og systemsårbarheder, levere løsninger til at reducere den tilknyttede risiko.

Penetrationstest: Denne variant af sikkerhedstest efterligner et hackingsforsøg på at fange sårbarheder og smuthuller, som ellers kunne have fået adgang til databasen eller applikationsdataene.

Sikkerhedsrevision: Det involverer revision af applikationen og de tilknyttede netværk for eventuelle sikkerhedsudfald.

Risikovurdering: Denne variant foretager en analyse for at vurdere risikoniveauet i tilfælde af, at en sårbarhed eller smuthul udnyttes til ondsindet hensigt. En sådan risiko kunne kategoriseres i lav, medium og høj. Baseret på risikoniveauet tilrådes passende foranstaltninger af testteamet til at reducere eller afværge risikoen.

Etisk hacking: Dette udføres af en organisation på sine systemer for at identificere smuthuller, der kan udnyttes i dens applikation eller netværk. Hensigten med denne form for hacking er ikke at stjæle eller forårsage skade på applikationen eller netværket.

Kropsholdningsvurdering: Dette er en paraplyvurdering, der består af sikkerhedsscanning, risikovurderinger og etisk hacking.

SQL-injektion: SQL Injection kunne bruges til at få adgang til serverdatabasen. Testen udføres for at sikre, at koden fungerer korrekt, hvilket udfører forespørgsler på databasen baseret på følgende input fra brugeren:

  • Beslag
  • Apostrofer
  • Kommaer
  • Anførselstegn

Andre faser i testning af BFSI-app

Bortset fra ovenstående hovedfaser kan der være forskellige faser involveret, f.eks. Integrationstest, brugervenlighedstest, brugeraccepteringstest og præstationstest.

Lad os også tale kort om disse faser:

Integrationstest

Som du ved, at der i en bankapplikation kan være flere forskellige moduler som overførsler, regningsbetalinger, indskud osv. Og således er der udviklet mange komponenter. I integrationstest blev alle komponenter integreret sammen og valideret.

Brugervenlighedstest

Brugervenlighedstest

En bankapplikation betjener en bred vifte af kunder. Nogle af disse kunder mangler muligvis de nødvendige færdigheder og bevidsthed til at udføre bankopgaver via appen.

Således skal bankapplikationen testes for enkel og effektiv design for at gøre den anvendelig på tværs af forskellige kundegrupper. Den enklere og brugervenlige grænseflade er, jo højere antal kunder vil drage fordel af bankapplikationen.

Det handler om at undersøge det lethedsniveau, forretningsbrugere eller bankkunder har i brugen af ​​applikationen. Denne test udføres ikke af udvikleren eller testeren, men udføres af forretningsbrugere.

For eksempel, I dag bruger alle mobile apps. Bankappen skal være brugervenlig og let at forstå og bruge af slutbrugeren.

Typer af brugertest

Sammenlignende brugervenlighedstest: Dette er sammenligningsbaseret test, hvor brugervenligheden af ​​et websted eller applikation med et andet er let. Målet for sådan test er at give den bedste brugeroplevelse.

Eksplorativ brugervenlighedstest: Målet med denne test er at identificere, hvilke funktioner den nye applikation eller software skal have for at imødekomme bankens kundebehov.

Følgende er fordele og ulemper ved Usability Testing

hvordan man åbner en .bin fil i windows

Fordele:

  • Slutbrugerne af applikationen er normalt involveret i testningen, og der opnås derfor førstehåndsfeedback.
  • I stedet for at bruge tid på analyse og diskussion om en funktion, som et produkt skal have eller ej, er det bedre at få input fra slutbrugeren direkte.
  • Vi kan fange eventuelle potentielle problemer på forhånd.

Ulemper:

  • Da flere slutbrugere er involveret i test, kan deres meninger, hvis de ikke er præcise, påvirke kravet.
  • Feedet fra slutbrugere kan blive påvirket.

Test af ydeevne

Visse perioder som lønningsdag, slutningen af ​​regnskabsåret, festlige årstider kan medføre ændringer eller øge den sædvanlige trafik på appen. Derfor skal der foretages en grundig præstationstest, så kunderne ikke bliver påvirket af ydeevnefejl.

Et betydningsfuldt eksempel fra fortiden, hvor bankkunder blev personligt berørt på grund af præstationsfejl, er NatWest og RBS cyber Monday it-afbrydelse, hvor kunderne fik deres debet- og kreditkort fik afviste transaktioner på tværs af butikker i landet.

Test af brugeraccept

Dette gøres ved at involvere slutbrugerne for at sikre, at applikationen overholder de virkelige scenarier og vil blive accepteret af brugerne, hvis den går live.

I dagens scenarie størstedelen af ​​bankprojekter bruger : Agile / Scrum, RUP og kontinuerlig integrationsmetoder og værktøjspakker som Microsofts VSTS og Rational Tools.

Som vi nævnte om RUP ovenfor, står RUP for Rational Unified Process, som er en iterativ softwareudviklingsmetode introduceret af IBM, der består af fire faser, hvor udviklings- og testaktiviteter udføres.

Fire faser er
i) Start
ii) Samarbejde
iii) Konstruktion og
iv) Overgang

RUP involverer bredt IBM Rational-værktøjer.

Eksempel på testtilfælde til bankansøgning

Test sager for New Branch

  • Opret en ny gren med gyldige og ugyldige testdata.
  • Opret en ny filial uden data.
  • Opret en ny gren med eksisterende filialdata.
  • Bekræft nulstillings- og annulleringsindstillingerne.
  • Opdater grenoplysninger med gyldige og ugyldige testdata.
  • Opdater grenoplysninger med eksisterende filialtestdata.
  • Kontroller, om den nye filial kan gemmes.
  • Kontroller, at annulleringsfunktionen fungerer.
  • Bekræft sletningen af ​​grenen med og uden afhængigheder.
  • Kontroller, om filialens søgemulighed fungerer.

Test tilfælde for ny rolle

  • Opret en ny rolle med gyldige og ugyldige testdata.
  • Opret en ny rolle uden data.
  • Bekræft, at en ny rolle kan oprettes med eksisterende testdata.
  • Kontroller rollebeskrivelsen og rolletyperne.
  • Bekræft, at indstillingen Annuller og Nulstil fungerer.
  • Bekræft rolle sletningsprocessen med og uden afhængighed.
  • Bekræft links på siden med rolleoplysninger.
  • Bekræft admin-login uden testdata.
  • Bekræft alle hjemmekoblinger til administratorrollen.
  • Bekræft, at administratoren kan ændre adgangskoden med gyldige og ugyldige testdata.
  • Kontroller, at administratoren logger af med succes.

Testcases for kunde og bankmand

  • Kontroller, om alle links til besøgende og kunder fungerer korrekt.
  • Bekræft kundens login med gyldige og ugyldige testdata.
  • Bekræft kundens login uden nogen data.
  • Bekræft bankmandens login uden data.
  • Bekræft bankmandens login med gyldige eller ugyldige testdata.
  • Bekræft, at kunden eller bankmanden kan logge af med succes.

Test cases for nye brugere

  • Kontroller, om den nye bruger kan oprettes med gyldige og ugyldige testdata.
  • Opret en ny bruger med eksisterende filialtestdata
  • Kontroller, om indstillingen Annuller og Nulstil fungerer korrekt.
  • Opdater brugeroplysninger med gyldige og ugyldige testdata.
  • Bekræft sletningen af ​​den nye bruger.
  • kontrollere, om den nye bruger kan verificeres.
  • Kontroller obligatoriske inputparametre.
  • Bekræft valgfrie inputparametre.
  • Kontroller, om en bruger kan oprettes uden valgfri parametre.

Test sager til oprettelse af en ny konto

  • Opret en ny konto med gyldige og ugyldige brugerdata.
  • Kontroller, om brugeroplysninger kan opdateres.
  • Kontroller, om en ny bruger kan gemmes.
  • Opret en ny konto med den eksisterende brugers data.
  • Bekræft, at brugeren kan indbetale beløbet på den nyoprettede konto (og opdatere saldoen).
  • Bekræft, at brugeren kan trække et beløb fra den nye konto (efter indbetaling og opdatere saldoen).
  • I tilfælde af løn skal du kontrollere, at virksomhedsnavnet og andre oplysninger er angivet af brugeren.
  • Kontroller, om det primære kontonummer er angivet i tilfælde af en sekundær konto.
  • Bekræft brugeroplysninger, der er angivet i tilfælde af den aktuelle konto.
  • Kontroller de medfølgende bevis for fælles konto i tilfælde af en fælles konto.
  • Kontroller, om det er i stand til at opretholde nul saldo på lønkontoen.
  • Kontroller, om det er i stand til at opretholde nul saldo eller mindstesaldo for ikke-lønkontoen.
  • Bekræft, at den nye bruger kan logge ud med succes.

Test tilfælde til anvendelse af netbank

  • Kontroller, om brugeren er i stand til at åbne bankwebstedet.
  • Kontroller, om alle links på siden fungerer.
  • Kontroller, om brugeren er i stand til at oprette en ny konto.
  • Kontroller, om brugeren er i stand til at logge ind med gyldigt og ugyldigt brugernavn og adgangskode.
  • Bekræft, om et af brugernavnet eller adgangskoden er tomt under login, skal brugeren ikke have lov til at logge ind, og der vises en advarselsmeddelelse.
  • Kontroller, om brugeren har lov til at ændre adgangskoden.
  • Hvis en ugyldig bruger eller adgangskode indtastes, vises den korrekte fejlmeddelelse.
  • Brugere med en ugyldig adgangskode bør ikke få lov til at logge ind.
  • Kontroller, at brugeren efter gentagne forsøg på at logge ind med en forkert adgangskode skal vises en fejlmeddelelse og blokeres.
  • Kontroller, om brugeren er i stand til at udføre nogle grundlæggende transaktioner.
  • Kontroller, at brugeren er i stand til at tilføje en modtager med gyldige og ugyldige detaljer.
  • Kontroller, om brugeren kan slette modtageren.
  • Kontroller, at brugeren er i stand til at foretage transaktioner til den nyligt tilføjede modtager.
  • Efter transaktionen skal du kontrollere, om både brugerens og modtagerens konti opdateres.
  • Kontroller, om brugeren er i stand til at indtaste beløbet i decimal.
  • Kontroller, om brugeren ikke er i stand til at indtaste negative tal i feltet beløb.
  • Kontroller, om brugeren har tilladelse til at foretage transaktioner med eller uden minimumsbalance.
  • Kontroller, om brugeren kan lave en ny RD.
  • Kontroller, at korrekt meddelelse vises i tilfælde af transaktion, der er udført med utilstrækkelig balance.
  • Kontroller, om brugeren bliver bedt om bekræftelse, inden en transaktion udføres.
  • Kontroller, om kvittering for hver vellykket transaktion er bekræftet.
  • Kontroller, om brugeren er i stand til at overføre penge til flere konti.
  • kontrollere, om brugeren kan annullere transaktionen.
  • Kontroller, at kontooplysningerne også afspejler finansielle transaktioner.
  • Kontroller, at timeout-funktionen er implementeret.
  • kontrollere, at i tilfælde af sessionstimeout skal en bruger logge ind igen.
  • kontrollere, at korrekt sessionstimeout er udført i tilfælde af inaktivitet.
  • kontrollere, at brugeren tages i sikker tilstand, mens transaktionen udføres.
  • Kontroller, om brugeren kan logge ud med succes.
  • Bekræft søge- og nulstillingsindstillinger.

Konklusion

I denne artikel diskuterede vi hvor kompleks en bankapplikation kan være og hvad er typiske faser involveret i test af applikationen . Bortset fra det diskuterede vi også aktuelle tendenser efterfulgt af IT-brancher, herunder softwareudviklingsmetoder og værktøjer.

Del gerne din oplevelse eller spørgsmål om dette emne!

Anbefalet læsning

^