how test banking domain applications
En komplett guide til testing av banksøknad: Testprosess og tips for BFSI (bank, finansielle tjenester og forsikring)
Bankapplikasjoner er en av de mest komplekse applikasjonene i dagens programvareutvikling og testing.
Hva gjør banksøknader så kompliserte? Hvilken tilnærming bør følges for å teste de komplekse arbeidsflytene som er involvert i banksøknader?
I denne artikkelen vil vi fremheve forskjellige trinn og teknikker som er involvert i testing av banksøknader.
Hva du vil lære:
- Hvordan teste banksøknader?
- Viktigheten av å teste banksøknad
- Bankfly App Testing Workflow
- Eksempel på testtilfeller for banksøknad
- Konklusjon
Hvordan teste banksøknader?
Ulike funksjoner utført av bankapplikasjoner er:
La oss først forstå egenskapene til en banksøknad:
- Multi-tier funksjonalitet for å støtte tusenvis av samtidige brukersessioner
- Storskala integrasjon: Vanligvis integreres en banksøknad med mange andre applikasjoner, for eksempel Bill Pay-verktøy og handelskontoer
- Komplekse arbeidsflyter
- Sanntids- og batchbehandling
- Den høye frekvensen av transaksjoner per sekund
- Sikre transaksjoner
- Robust rapporteringsseksjon for å holde oversikt over daglige transaksjoner
- Sterk revisjon for å feilsøke kundeproblemer
- Massivt lagringssystem
- Disaster / Recovery Management.
De ovennevnte ti punktene er viktigste egenskapene til en banksøknad.
Bankapplikasjoner har flere nivåer involvert i å utføre en operasjon.
For eksempel , til Banksøknad kan ha:
- Webserver for å samhandle med sluttbrukere via nettleseren
- Middle Tier for å validere inndata og utdata for webserveren
- DataBase for å lagre data og prosedyrer
- Transaksjonsprosessor som kan være en stor kapasitetsramme eller et annet Legacy-system for å utføre billioner av transaksjoner per sekund.
Hvis vi snakker om å teste banksøknader, krever det en End to End Testing Methodology som involverer flere teknikker for programvaretesting for å sikre:
- Total dekning av alle bankarbeidsflyter og forretningskrav
- Det funksjonelle aspektet ved applikasjonen
- Sikkerhetsaspektet ved applikasjonen
- Dataintegritet
- Samtidighet
- Brukererfaring
Hva gjør banksøknader så kompliserte?
- Bankprogramvare håndterer hovedsakelig konfidensielle økonomiske data, slik at ytelsen til programvaren skal være feilfri og sikker.
- Utviklere foretrekker en komplisert design for å utvikle disse applikasjonene for å sikre at applikasjonen kjører på en ønsket sikker måte.
- Bank er en verden i stadig endring. Banking i dag gjøres tilgjengelig for kunden ved hjelp av forskjellige kanaler som murstein- og mørtelgrener, minibanker, nettbank og kundebehandling.
- Med fremkomsten av teknologi har mange lommebøker flommet over markedene som kobles til banksystemene for finansielle transaksjoner.
- Bank forventes også å være i gang 24 X 7 med høy ytelse. Programvareoppgraderinger, øyeblikkelige reparasjoner osv. Kan ikke tillates å påvirke denne tilgjengeligheten.
- Bankverdenen er også sterkt påvirket av de konstante endringene som myndighetene bringer inn i form av bankreguleringer. Eventuelle endringer i skattestrukturen påvirker også banksystemet.
- Banksystemet må også være oppdatert når det gjelder ny teknologi. Dataanalyse som Big Data Processing og å få instinkter ut av big data ved hjelp av Data Science, øker trekkraften i bankverdenen.
Ovennevnte punkter gjør banksystemet komplisert for utviklere å lage en programvare rundt det.
Viktigheten av å teste banksøknad
- Testing av banksøknaden sikrer at alle aktivitetene ikke bare utføres godt, men også forblir beskyttet og sikret.
- Bankprogramvare er komplisert med tusenvis av avhengigheter, testprosessen krever mer tid, ressurser og kontinuerlig overvåking.
- Siden økonomi er involvert, må retningslinjene følges nøye. Både testere og utviklere bør ha god domenekunnskap.
- Viktigst, det må sikres at lovene og forskriftene håndheves riktig i finansielle transaksjoner. Dette kan bare sikres ved testing.
- Det er også viktig å sørge for at applikasjonen og infrastrukturen applikasjonen er distribuert på, er i stand til å håndtere belastningen, spesielt i topptid, uten å forårsake forstyrrelser. Dette kan sikres ved å utføre ytelsestesting.
- I dagens digitale verden er det som gjelder alle, sikkerhet. Bankapplikasjonene og de finansielle transaksjonene som utføres i den, må være sikre mot ethvert forsøk på innbrudd. Dette kan sikres ved å utføre sikkerhetstesting. Sikkerhetstesting hjelper med å håndheve industristandarder for å sikre finansielle transaksjoner.
- Det er også viktig å sikre at forskjellige moduler i en bankapplikasjon og integreres ordentlig og oppnå målet for klienten. Systemintegrasjonstesting hjelper deg med å oppnå denne oppgaven.
Bankfly App Testing Workflow
Typiske stadier involvert i testing av bankapplikasjoner vises i arbeidsflyten nedenfor. Vi vil diskutere hvert trinn individuelt.
Dette er en fossemodell for testing av et program.
# 1) Kravsamling
Kravsamlingsfase innebærer dokumentasjon av krav enten som funksjonelle spesifikasjoner eller som brukstilfeller. Krav samles etter kundens behov og dokumenteres av bankeksperter eller forretningsanalytikere.
Eksperter er involvert i å skrive krav til mer enn ett emne, ettersom banken i seg selv har flere underdomener og en fullverdig banksøknad vil være integrasjonen av alle disse domenene.
For eksempel, En banksøknad kan ha separate moduler for overføringer, kredittkort, rapporter, lånekontoer, regningsbetalinger, handel osv.
# 2) Kravgjennomgang
Leveransen av Requirement Gathering blir gjennomgått av alle interessenter som QA Engineers, Development leads og Peer Business Analysts.
De kryssjekker at verken eksisterende arbeidsflyt eller nye arbeidsflyter brytes. Alle kravene er verifisert og validert. Oppfølgingshandlinger og kravdokumentrevisjoner gjøres basert på det samme.
# 3) Forberedelser for forretningsscenario
I dette stadiet henter QA-ingeniører forretningsscenarier fra kravdokumentene (Funksjonsspesifikasjoner eller brukstilfeller); Forretningsscenarier er avledet på en slik måte at alle forretningskrav dekkes. Forretningsscenarier er scenarier på høyt nivå uten noen detaljerte trinn.
Videre blir disse forretningsscenariene gjennomgått av forretningsanalytikere for å sikre at alle forretningskravene blir oppfylt. Det er lettere for BAs å gjennomgå scenarier på høyt nivå i stedet for å gjennomgå detaljerte testsaker på lavt nivå.
For eksempel , kan en kunde som åpner et fast innskudd på det digitale bankgrensesnittet være et forretningsscenario. På samme måte kan vi ha forskjellige forretningsscenarier knyttet til nettbankopprettelse, innskudd på nettet, overføringer på nettet, etc.
# 4) Funksjonstesting
I dette stadiet utføres funksjonell testing og de vanlige programvaretestaktivitetene utføres som:
Test Case Case Preparation: I dette stadiet er testtilfeller avledet fra forretningsscenarier, ett forretningsscenario fører til flere positive testsaker og negative testsaker. Generelt er verktøy som brukes i denne fasen Microsoft Excel, Test Director eller Quality Center.
Test Case Review: Vurderinger av peer QA Engineers
Testforsøk Henrettelse: Test Case Execution kan være enten manuell eller automatisk som involverer verktøy som QC, QTP, etc.
Funksjonstesting av en banksøknad er ganske forskjellig fra vanlig programvaretesting. Siden disse applikasjonene fungerer med kundens penger og sensitive økonomiske data, må de testes grundig. Ingen viktige forretningsscenarier skal overlates til å bli dekket.
QA-ressursen som tester applikasjonen, bør også ha grunnleggende kunnskap om banksektoren.
# 5) Databasetesting
Bankapplikasjon innebærer komplekse transaksjoner som utføres både på UI-nivå og databasenivå. Derfor er databasetesting like viktig som funksjonstesting. Databasen er komplisert og et helt eget lag i applikasjonen, og dermed blir testingen utført av databasespesialister. Den bruker teknikker som:
- Datainnlasting
- Databaseoverføring
- Testing av DB-skjema og datatyper
- Testing av regler
- Testing av lagrede prosedyrer og funksjoner
- Testing av utløsere
- Dataintegritet
Hovedformålet med databasetesting er å sikre at:
- Applikasjonen er i stand til å lagre og hente data fra databasen uten tap av data.
- Fullførte transaksjoner bør begås og avbrutte transaksjoner tilbakestilles for å unngå misforhold i lagrede data.
- Bare autoriserte applikasjoner og brukere har tilgang til databasen og de underliggende tabellene.
Det er primært tre måter å teste databaser på:
- Strukturell testing
- Funksjonell testing
- Ikke-funksjonell testing
Strukturell testing
Det innebærer testing av databaseobjekter som databaser, skjema, tabeller, visninger, utløsere, tilgangskontroller, etc. Sikre at datatyper i tabeller er synkronisert med de tilsvarende variablene i applikasjonen. Validering av data og referanseintegritet i tabellene.
For eksempel, Et beløpsfelt i applikasjonen skal ha en datatype desimal / flyt i tabellen.
- For å overholde standarder, bør brukerne få tilgangskontroll gjennom visninger.
Funksjonell testing
Det innebærer å teste databasene som tilfredsstiller brukerens krav. Det er to måter å oppnå: Black box testing og White box testing.
For eksempel, Når vi foretar en pengeoverføring på nettet, skal avsenderkontoen belastes og mottakerkontoen krediteres med nøyaktig samme beløp. Hvis transaksjonen mislykkes, bør hele transaksjoner tilbakestilles, og avsenderkontoen skal ikke belastes eller krediteres tilbake.
Ikke-funksjonell testing
Det innebærer belastning og stresstesting og ytelsesoptimalisering. Lastetesting hjelper deg med å identifisere flest antall transaksjoner som kan utføres samtidig uten å påvirke databasens ytelse.
For eksempel, Basert på innspill fra belastnings- og stresstesting kan bankapplikasjoner bestemme seg for å legge til flere ressurser i applikasjonen i løpet av topptid og redusere ressursene utenom arbeidstid. Dette hjelper banken til å utnytte ressursene optimalt og spare penger.
# 6) Sikkerhetstesting
Sikkerhetstesting er vanligvis den siste fasen i testsyklusen. En forutsetning for å starte sikkerhetstesting er fullføring av funksjonell og ikke-funksjonell testing. Sikkerhetstesting er en av de viktigste trinnene i hele applikasjonstestsyklusen, da dette trinnet sørger for at applikasjonen er i samsvar med føderale og industristandarder.
På grunn av innholdet i dataene de har, er bankapps veldig følsomme og er et viktig mål for hackere og falske aktiviteter. Sikkerhetstesting sørger for at applikasjonen ikke har et slikt nettsårbarhet som kan utsette sensitive data for en inntrenger eller en angriper. Det forsikrer også at applikasjonen overholder standarder som OWASP.
I dette stadiet er hovedoppgaven hele applikasjonsskanningen som utføres ved hjelp av verktøy som IBM AppScan eller HP WebInspect (dette er de mest populære verktøyene).
Når skanningen er fullført, blir skanningsrapporten publisert. I løpet av denne rapporten blir falske positive filtrert ut, og resten av sårbarhetene rapporteres til utviklingsteamet slik at de begynner å løse problemene, avhengig av alvorlighetsgraden av hvert problem.
Penetrasjonstesting gjøres også i dette trinnet for å avsløre forplantningen av feil. Streng sikkerhetstesting bør gjøres på tvers av plattformer, nettverk og OS.
Noen andre Manuelle verktøy for sikkerhetstesting brukt er Paros Proxy , Http Watch , Burp-suite , og Forsterke.
Hovedformålet med sikkerhetstesting er å finne eventuelle sårbarheter programvaren kan ha.
Sikkerhetstesten tester søknaden mot:
- Ethvert eksternt angrep eller forsøk på å hacke applikasjonen med ondsinnet hensikt.
- Ethvert smutthull i programvaren kan utnyttes og forårsake data eller tap av penger.
- Eventuelt sårbarhet i nettverket, serverne og arbeidsstasjonene som er vert for applikasjonen.
Følgende er de forskjellige typene sikkerhetstesting:
Sårbarhetstesting: Et automatisert program er utviklet og utført for å se etter ulike sårbarheter.
Sikkerhetsskanning: Denne varianten dreier seg om å undersøke sårbarheter i nettverk og system, gi løsninger for å redusere den tilknyttede risikoen.
Penetrasjonstesting: Denne varianten av sikkerhetstesting imiterer et hackingsforsøk på å fange opp sårbarheter og smutthull, som ellers kunne ha fått tilgang til databasen eller applikasjonsdataene.
Sikkerhetsrevisjon: Det innebærer revisjon av applikasjonen og tilknyttede nettverk for eventuelle sikkerhetsavvik.
Risikovurdering: Denne varianten gjør en analyse for å vurdere risikonivået i tilfelle en sårbarhet eller smutthull blir utnyttet for ondsinnet hensikt. Slik risiko kan kategoriseres i lav, middels og høy. Basert på risikonivået anbefales testteamet til å redusere eller avverge risikoen.
Etisk hacking: Dette utføres av en organisasjon på systemene for å identifisere smutthull som kan utnyttes i applikasjonen eller nettverket. Hensikten med denne typen hacking er ikke å stjele eller skade applikasjonen eller nettverket.
Holdningsvurdering: Dette er en paraplyvurdering som består av sikkerhetsskanning, risikovurderinger og etisk hacking.
SQL-injeksjon: SQL Injection kan brukes til å få tilgang til serverdatabasen. Testingen gjøres for å sikre at koden fungerer som den skal, som utfører spørsmål i databasen basert på følgende innganger fra brukeren:
- Braketter
- Apostrofer
- Komma
- Anførselstegn
Andre stadier i testing av BFSI-app
Bortsett fra de ovennevnte hovedstadiene, kan det være forskjellige trinn involvert, for eksempel integrasjonstesting, brukervennlighetstesting, brukertesttesting og ytelsestesting.
La oss også snakke kort om disse stadiene:
Integrasjonstesting
Som du vet at i en banksøknad kan det være flere forskjellige moduler som overføringer, regningsbetalinger, innskudd osv. Og dermed er det mange komponenter utviklet. I integrasjonstesting ble alle komponentene integrert sammen og validert.
Brukervennlighetstesting
En banksøknad betjener et bredt utvalg av kunder. Noen av disse kundene mangler kanskje ferdighetene og bevisstheten som kreves for å utføre bankoppgavene over appen.
Dermed bør banksøknaden testes for enkel og effektiv design for å gjøre den brukbar på tvers av forskjellige kundegrupper. Jo enklere og brukervennlig grensesnitt er, jo høyere antall kunder vil få fordel av banksøknaden.
Det handler om å undersøke hvor enkelt det er bedriftsbrukerne eller bankkundene når de bruker applikasjonen. Denne testen utføres ikke av utvikleren eller testeren, men utføres av forretningsbrukerne.
For eksempel, I dag bruker alle mobilapper. Bankappen skal være brukervennlig og lett å forstå og bruke av sluttbrukeren.
Typer av brukervennlighetstesting
Sammenlignende brukervennlighetstesting: Dette er sammenligningsbasert testing, hvor brukervennligheten til et nettsted eller applikasjon med et annet er enkel. Målet for slik testing er å gi den beste brukeropplevelsen.
Eksplorativ brukervennlighetstesting: Målet med denne testingen er å identifisere hvilke funksjoner den nye applikasjonen eller programvaren skal ha for å oppfylle bankens kundekrav.
Følgende er fordeler og ulemper ved brukervennlighetstesting
ms sql server intervju spørsmål og svar for erfarne
Fordeler:
- Sluttbrukerne av applikasjonen er vanligvis involvert i testingen, og derfor oppnås førstehånds tilbakemelding.
- I stedet for å bruke tid på analyse og diskusjon om en funksjon som et produkt skal ha eller ikke, er det bedre å få inngangene fra sluttbrukeren direkte.
- Vi kan fange opp eventuelle problemer på forhånd.
Ulemper:
- Ettersom flere sluttbrukere er involvert i testing, kan deres meninger om ikke presise påvirke kravet.
- Strømmen fra sluttbrukere kan bli påvirket.
Ytelsestesting
Enkelte perioder som lønningsdag, slutten av regnskapsåret, høytider kan føre til endring eller økning i den vanlige trafikken på appen. Derfor bør grundige ytelsestester utføres slik at kundene ikke blir påvirket av ytelsesfeil.
Et viktig eksempel fra fortiden hvor bankkunder ble personlig berørt på grunn av svikt i ytelsen, er NatWest og RBS cyber Monday IT-strømbrudd der kundene fikk debet- og kredittkortet fikk avviste transaksjoner på tvers av butikker i landet.
Testing av brukeraksept
Dette gjøres ved å involvere sluttbrukerne for å sikre at applikasjonen er i samsvar med de virkelige scenariene og vil bli akseptert av brukerne hvis den blir live.
I dagens scenario de fleste bankprosjekter bruker : Agile / Scrum, RUP og kontinuerlig integrasjonsmetodikk, og verktøypakker som Microsofts VSTS og Rational Tools.
Som vi nevnte om RUP ovenfor, står RUP for Rational Unified Process, som er en iterativ programvareutviklingsmetodikk introdusert av IBM som består av fire faser der utviklings- og testaktiviteter utføres.
Fire faser er
i) Oppstart
ii) Samarbeid
iii) Bygg og
iv) Overgang
RUP involverer bredt IBM Rational-verktøy.
Eksempel på testtilfeller for banksøknad
Test tilfeller for New Branch
- Opprett en ny gren med gyldige og ugyldige testdata.
- Opprett en ny gren uten data.
- Opprett en ny gren med eksisterende grendata.
- Bekreft tilbakestillings- og avbrytingsalternativene.
- Oppdater greninformasjon med gyldige og ugyldige testdata.
- Oppdater grendetaljer med eksisterende filtestdata.
- Bekreft om den nye grenen kan lagres.
- Bekreft at alternativet for avbryt fungerer.
- Bekreft sletting av grenen med og uten avhengigheter.
- Bekreft om alternativet for filialsøk fungerer.
Test tilfeller for ny rolle
- Opprett en ny rolle med gyldige og ugyldige testdata.
- Lag en ny rolle uten data.
- Bekreft at en ny rolle kan opprettes med eksisterende testdata.
- Bekreft rollebeskrivelsen og rolletypene.
- Bekreft at alternativet avbryt og tilbakestill fungerer.
- Bekreft rolleslettingsprosessen med og uten avhengighet.
- Bekreft lenkene på siden med rolleinformasjon.
- Bekreft administratorinnloggingen uten testdata.
- Bekreft alle hjemmekoblinger for administratorrollen.
- Bekreft at administratoren kan endre passordet med gyldige og ugyldige testdata.
- Bekreft administratorloggingen.
Test tilfeller for kunde og bankmann
- Kontroller om alle besøkende og kundekoblinger fungerer som de skal.
- Bekreft påloggingen hos kunden med gyldige og ugyldige testdata.
- Bekreft påloggingen til kunden uten data.
- Bekreft pålogging for bankmannen uten data.
- Bekreft påloggingen for bankmannen med gyldige eller ugyldige testdata.
- Bekreft at kunden eller bankmannen kan logge ut.
Test tilfeller for nye brukere
- Bekreft om den nye brukeren kan opprettes med gyldige og ugyldige testdata.
- Opprett en ny bruker med eksisterende grenprøvedata
- Bekreft om alternativet for avbryt og tilbakestilling fungerer som det skal.
- Oppdater brukerdetaljer med gyldige og ugyldige testdata.
- Bekreft slettingen av den nye brukeren.
- sjekk om den nye brukeren kan bekreftes.
- Bekreft obligatoriske inngangsparametere.
- Bekreft valgfrie inngangsparametere.
- Kontroller om en bruker kan opprettes uten valgfrie parametere.
Test saker for opprettelse av en ny konto
- Opprett en ny konto med gyldige og ugyldige brukerdata.
- Bekreft om brukeropplysninger kan oppdateres.
- Bekreft om en ny bruker kan lagres.
- Opprett en ny konto med den eksisterende brukerens data.
- Bekreft at brukeren kan sette inn beløpet på den nylig opprettede kontoen (og oppdatere saldoen).
- Bekreft at brukeren kan ta ut et beløp fra den nye kontoen (etter innskudd og oppdatere saldoen).
- Når det gjelder lønn, må du bekrefte firmaets navn og andre detaljer gitt av brukeren.
- Kontroller om det primære kontonummeret er oppgitt i tilfelle en sekundær konto.
- Bekreft brukerinformasjon gitt i tilfeller av gjeldende konto.
- Bekreft de medfølgende bevisene for en felles konto i tilfelle en felles konto.
- Kontroller om du kan opprettholde nullbalansen i lønnskontoen.
- Kontroller om du kan opprettholde null- eller minimumsbalanse for ikke-lønnskontoen.
- Bekreft at den nye brukeren kan logge ut.
Test tilfeller for søknad om nettbank
- Sjekk om brukeren er i stand til å åpne banksiden.
- Sjekk om alle lenkene på nettstedet fungerer.
- Bekreft om brukeren er i stand til å opprette en ny konto.
- Sjekk om brukeren er i stand til å logge på med gyldig og ugyldig brukernavn og passord.
- Bekreft om noe av brukernavnet eller passordet er tomt mens du logger inn, brukeren ikke skal ha lov til å logge på og en varselmelding vises.
- Sjekk om brukeren har lov til å endre passordet.
- Hvis en ugyldig bruker eller passord er angitt, vises riktig feilmelding.
- Brukere med ugyldig passord skal ikke få lov til å logge på.
- Bekreft at etter gjentatte forsøk på å logge på med feil passord, skal brukeren vises en feilmelding og blokkeres.
- Sjekk om brukeren er i stand til å utføre noen grunnleggende transaksjoner.
- Bekreft at brukeren er i stand til å legge til en mottaker med gyldige og ugyldige detaljer.
- Bekreft om brukeren kan slette mottakeren.
- Bekreft at brukeren er i stand til å gjøre transaksjoner til den nylig tilførte mottakeren.
- Etter transaksjonen må du kontrollere om kontoene til både bruker og mottaker er oppdatert.
- Sjekk om brukeren kan angi beløpet i desimaltall.
- Bekreft om brukeren ikke kan angi negative tall i beløpsfeltet.
- Bekreft om brukeren har lov til å gjøre transaksjoner med eller uten minimumssaldo.
- Bekreft om brukeren kan gjøre en ny RD.
- Kontroller at riktig melding vises i tilfelle transaksjoner er utført med utilstrekkelig balanse.
- Sjekk om brukeren blir bedt om bekreftelse før en transaksjon er gjennomført.
- Kontroller om kvittering mottas på hver vellykkede transaksjon.
- Kontroller om brukeren er i stand til å overføre penger til flere kontoer.
- bekrefte om brukeren kan avbryte transaksjonen.
- Kontroller at kontodetaljene også gjenspeiler økonomiske transaksjoner.
- Kontroller at tidsavbruddsfunksjonen er implementert.
- verifiser at i tilfelle timeout skulle en bruker logge på igjen.
- kontroller at riktig tidsavbrudd er gjort i tilfelle inaktivitet.
- bekrefte at brukeren blir tatt i sikker modus mens han gjør transaksjonen.
- Bekreft om brukeren kan logge ut.
- Bekreft søke- og tilbakestillingsalternativer.
Konklusjon
I denne artikkelen diskuterte vi hvor komplisert en banksøknad kan være og hva er typiske faser involvert i testing av applikasjonen . Bortsett fra det diskuterte vi også dagens trender fulgt av IT-bransjer, inkludert programvareutviklingsmetoder og verktøy.
Del gjerne dine erfaringer eller spørsmål om dette emnet!
Anbefalt lesing
- Hvordan teste investeringsbankapplikasjon (med 34+ viktige testscenarier)
- Hvordan teste detaljbanksystemet
- Hvordan teste helseprogrammet - Del 1
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Alpha Testing og Beta Testing (En komplett guide)
- Testing Primer eBook Download
- Funksjonstesting mot ikke-funksjonell testing
- Installere applikasjoner og klargjøre dem for appiumtesting