Bankdomæneapplikationstestning: Eksempel på testsager

Bankdomænetestning

Bankdomænetestning er en softwaretestproces af en bankapplikation for funktionalitet, ydeevne og sikkerhed. Hovedformålet med at teste bankapplikationer er at sikre, at alle aktiviteter og funktionaliteter i en banksoftware kører problemfrit uden fejl, og at den forbliver beskyttet.

BFSI-sektoren (Banking, Financial Services and Insurance) er den største forbruger af it-tjenester. Bankapplikationer omhandler direkte fortrolige finansielle data. Det er obligatorisk, at alle aktiviteter udført af banksoftware kører problemfrit og uden fejl. Banksoftware udfører forskellige funktioner som overførsel og indbetaling af midler, saldoforespørgsel, transaktionshistorik, tilbagetrækning og så videre. Test af bankapplikationer sikrer, at disse aktiviteter ikke kun udføres godt, men også forbliver beskyttet mod hackere.

Tilmeld dig vores Live Banking-testprojekt gratis

Hvad er domæne i test?

Domæne i test er intet andet end den industri, som softwaretestprojektet er skabt til. Når vi taler om softwareprojekter eller udvikling, henvises der ofte til dette begreb. For eksempel forsikringsdomæne, bankdomæne, detaildomæne, telecomdomæne osv.

Test af bankdomæneapplikationer

Normalt, mens der udvikles et specifikt domæneprojekt, søges domæneeksperthjælp. Domæneeksperter er mestre i emnet, og han kender muligvis produktet eller applikationen ud og ind.

Hvorfor er domæneviden vigtig?

Domæneviden er meget vigtig for at teste ethvert softwareprodukt, og det har sine egne fordele som f.eks

Domæneviden er vigtig

Bankdomæneviden – introduktion

Bankdomæne concepts er enorme, og grundlæggende er det underkarakteriseret i to sektorer

  1. Traditionel banksektor
  2. Servicebaseret banksektor

Nedenfor er tabellen over de tjenester, som disse to undersektorer af bankvirksomhed omfatter

Traditionel banksektor
  • Core bankvirksomhed
  • Virksomhedsbankvirksomhed
  • Detailbank
Servicebaseret banksektor
  • Core
  • Corporate
  • Retail
  • Lån
  • Handelsfinansiering
  • Privat bankvirksomhed
  • Forbrugerfinansiering
  • Islamisk bankvirksomhed
  • Kundeleveringskanaler/Frontend levering

Baseret på omfanget af dit projekt skal du muligvis teste en eller alle ovenstående servicetilbud. Før du begynder at teste, skal du sikre dig, at du har tilstrækkelig baggrund om den tjeneste, der testes.

Karakteristika for en bankapplikation

Før du begynder at teste, er det vigtigt at bemærke de standardfunktioner, der forventes af enhver bankapplikation. Så du kan geare din testindsats til at opnå disse egenskaber.

En standard bankapplikation skal opfylde alle disse egenskaber som nævnt nedenfor.

  • Det skulle understøtte tusindvis af samtidige brugersessioner
  • En bankapplikation skal integreres med andre talrige applikationer som handelskonti, Bill betalingsforsyning, kreditkort osv.
  • Det skal behandle hurtige og sikre transaktioner
  • Det bør omfatte massivt lagersystem.
  • For at fejlfinde kundeproblemer skal den have høj revisionskapacitet
  • Den skal håndtere complex forretningsmæssige arbejdsgange
  • Behov for at understøtte brugere på flere platforme (Mac, Linux, Unix, Windows)
  • Det bør understøtte brugere fra flere steder
  • Det bør understøtte flersprogede brugere
  • Det skal understøtte brugere på forskellige betalingssystemer (VISA, AMEX, MasterCard)
  • Det bør understøtte flere servicesektorer (lån, detailbank osv.)
  • Idiotsikker katastrofehåndteringsmekanisme

Testfaser i test af bankapplikationer

Til test af bankapplikationer inkluderer forskellige teststadier

  • Behovsanalyse: Det gøres af forretningsanalytiker; krav til en bestemt bankapplikation samles og dokumenteres
  • Kravgennemgang: Kvalitetsanalytikere, forretningsanalytikere og udviklingsledere er involveret i denne opgave. Kravindsamlingsdokumentet gennemgås på dette trin og krydstjekkes for at sikre, at det ikke påvirker arbejdsgangen
  • Dokumentation for forretningskrav: Forretningskravdokumenter udarbejdes af kvalitetsanalytikere, hvor alle gennemgåede forretningskrav er dækket
  • Databasetest: Det er den vigtigste del af test af bankapplikationer. Denne test udføres for at sikre dataintegritet, dataindlæsning, datamigrering, lagrede procedurer og funktionsvalidering, regeltest osv.
  • Integrationstest: Under Integrationstest alle komponenter, der udvikles, er integrerede og validerede
  • Funktionel testning: De sædvanlige softwaretestaktiviteter som Test sag forberedelse, test case review og test case eksekvering udføres i denne fase
  • Sikkerhedstest: Det sikrer, at softwaren ikke har nogen sikkerhedsfejl. Under testforberedelsen skal QA-teamet inkludere både negative og positive testscenarier for at bryde ind i systemet og rapportere det, før enhver uautoriseret person får adgang til det. For at forhindre hacking bør banken også implementere et flerlags adgangsvalidering som en engangsadgangskode. Til Sikkerhedstest, automatiseringsværktøjer som IBM AppScan og HPWebInspect bruges mens til Manuel testning værktøjer som Proxy Sniffer, Paros proxy, HTTP watch osv. bruges
  • Usability Testing: Det sikrer, at forskelligt dygtige mennesker skal kunne bruge systemet som normal bruger. For eksempel hæveautomat med høre- og punktskrift for handicappede
  • Brugeraccepttest: Det er den sidste fase af test udført af slutbrugerne for at sikre applikationens overensstemmelse med det virkelige scenarie.

Eksempel på testtilfælde for netbankloginapplikation

Sikkerhed er det vigtigste for enhver bankapplikation. Under testforberedelsen bør QA-teamet derfor inkludere både negative og positive testscenarier for at snige sig ind i systemet og rapportere for eventuelle sårbarheder, før en uautoriseret person får adgang til det. Det involverer ikke kun at skrive negative testcases, men kan også omfatte destruktiv test.

Following er generiske testsager for at kontrollere enhver bankapplikation

Eksempel på testcases
Til Admin
  • Bekræft administratorlogin med gyldige og ugyldige data
  • Bekræft administratorlogin uden data
  • Bekræft alle links til administratorhjemmesiden
  • Bekræft administratorens ændringsadgangskode med gyldige og ugyldige data
  • Bekræft administratorens ændringsadgangskode uden data
  • Bekræft administratorens ændringsadgangskode med eksisterende data
  • Bekræft administratorlogout
Til ny afdeling
  • Opret en ny filial med gyldige og ugyldige data
  • Opret en ny filial uden data
  • Opret en ny filial med eksisterende filialdata
  • Bekræft nulstilling og annuller mulighed
  • Opdater filial med gyldige og ugyldige data
  • Opdater filial uden data
  • Opdater filial med eksisterende filialdata
  • Bekræft annulleringsmuligheden
  • Bekræft sletning af gren med og uden afhængigheder
  • Bekræft filialsøgningsmulighed
Til ny rolle
  • Opret en ny rolle med gyldige og ugyldige data
  • Opret en ny rolle uden data
  • Bekræft ny rolle med eksisterende data
  • verificere rollebeskrivelse og rolletyper
  • Bekræft muligheden for annullering og nulstilling
  • Bekræft sletning af rolle med og uden afhængighed
  • verificere links i rolle details side
Til kunder og besøgende
  • Bekræft alle besøgende eller kundelinks
  • Bekræft kundernes login med gyldige og ugyldige data
  • Bekræft kundernes login uden data
  • Bekræft bankmands login uden data
  • Bekræft bankmands login med gyldige eller ugyldige data
For nye brugere
  • Opret en ny bruger med gyldige og ugyldige data
  • Opret en ny bruger uden data
  • Opret en ny bruger med eksisterende filialdata
  • Bekræft muligheden for annullering og nulstilling
  • Opdater bruger med gyldige og ugyldige data
  • Opdater bruger med eksisterende data
  • Bekræft annulleringsmuligheden
  • Bekræft sletning af brugeren

Udfordringer i at teste bankdomæne og deres afbødning

Udfordringer, som testeren kan stå over for under test af bankdomæne

Udfordring Mitigation
  • At få adgang til produktionsdata og replikere dem som testdata til test er udfordrende
  • Sørg for, at testdata opfylder lovmæssige overholdelseskrav og retningslinjer
  • Oprethold datafortroligheden af ​​following teknikker som datamaskering, syntetiske testdata, testsystemintegration osv.
  • Den største udfordring i at teste banksystem er under migreringen af ​​systemet fra det gamle system til det nye system som test af alle rutiner, procedurer og planer. Også hvordan data vil blive hentet, uploadet og overført til det nye system efter migrering
  • Sørg for, at datamigreringstestning er fuldført
  • Sørg for, at tilfælde af regressionstest udføres på gamle og nye systemer, og at resultaterne stemmer overens.
  • Der kan være tilfælde, hvor krav ikke er godt dokumenteret og kan føre til funktionelle huller i testplanen
  • Mange ikke-funktionelle krav er ikke fuldt dokumenteret, og testere ved ikke, om de skal teste det eller ej
  • Testen skal deltage i projektet lige fra kravanalysefaserne og skal aktivt gennemgå forretningskravene
  • Det vigtigste er at kontrollere, om det nævnte system følger de ønskede politikker og procedurer
  • Overholdelses- eller lovgivningsmæssige politikker-test skal udføres
  • Omfanget og tidslinjerne øges, efterhånden som bankapplikationen integreres med andre applikationer som internet eller Mobil bank
  • Sørg for, at der tages højde for tidsbudgettet for integrationstest, hvis din bankapplikation har mange eksterne grænseflader

Resumé

Bankdomæne er det mest sårbare område for cybertyveri, og sikring af softwaren kræver præcise tests. Denne vejledning giver en klar idé om, hvad der skal til for at teste bankdomæne, og hvor vigtigt det er. Det må man forstå –

  • Størstedelen af ​​banksoftware er udviklet på Mainframe , Unix
  • Test hjælper med at mindske mulige fejl, der opstår under softwareudvikling
  • Korrekt testning og overholdelse af industristandarder sparer virksomheder for bøder
  • God praksis hjælper med at udvikle gode resultater, omdømme og mere forretning for virksomheder
  • Både manuel og automatiseret test har respektive fordele og anvendelighed

Tilmeld dig vores Live Banking domænetestprojekt