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.

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

Bankdomæneviden – introduktion

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

Traditionel banksektor
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
Det skal håndtere komplekse 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
Krav Revse: 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.

Følgende 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 på siden med rolledetaljer
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 ved at følge 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	Testeren 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 og 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

Du kan lide: