Test af bankdomæneansøgning: Eksempel på testtilfælde

Testning af bankdomæner

Banking Domain Testing er en softwaretestproces af en bankapplikation til funktionalitet, ydeevne og sikkerhed. Hovedformålet med at teste bankapplikationer er at sikre, at alle aktiviteter og funktioner i en banksoftware kører problemfrit uden fejl, og den forbliver beskyttet.

BFSI (bankvæsen, finansielle tjenester og forsikring) er den største forbruger af it-tjenester. Bankapplikationer behandler direkte fortrolige økonomiske data. Det er obligatorisk, at alle aktiviteter, der udføres af banksoftware, kører problemfrit og uden nogen fejl. Banksoftware udfører forskellige funktioner som overførsel og deponering af fond, balanceforespørgsel, transaktionshistorik, tilbagetrækning og så videre. Test af bankapplikation sikrer, at disse aktiviteter ikke kun udføres godt, men også forbliver beskyttet mod hackere.

I denne vejledning lærer vi

Hvad er domæne i testning?
Hvorfor domæne viden spørgsmål?
Introduktion til bankdomæne
Karakteristika ved en bankapplikation
Stadier til test af bankapplikationer
Eksempel på test sag til netbanking login applikation
Udfordringer i test af bankdomæne og deres afhjælpning

Deltag i vores Live Banking Testing Project gratis

Hvad er domæne i testning?

Domæne i testning er intet andet end den branche, som softwaretestprojektet oprettes for. Når vi taler om softwareprojekter eller udvikling, henvises der ofte til dette udtryk. For eksempel forsikringsdomæne, bankdomæne, detaildomæne, telekomdomæne osv.

Normalt søges domæneeksperthjælp under udvikling af et specifikt domæneprojekt. Domæneekspert er herre over emnet, og han kender muligvis indersiden af produktet eller applikationen.

Hvorfor domæne viden spørgsmål?

Domæne viden er afgørende for at teste ethvert softwareprodukt, og det har sine egne fordele som

Banking Domain Knowledge - Introduktion

Bankdomæne-koncepter er enorme, og dybest set er det underkarakteriseret i to sektorer

Traditionel banksektor
Servicebaseret banksektor

Nedenfor er tabellen over de tjenester, som disse to undersektorer inden for bank omfatter

Traditionel banksektor	Core bankvirksomhed Virksomhedsbankvirksomhed Detailbank
Servicebaseret banksektor	Kerne Virksomhed Detailhandel Lån Handelsfinansiering Privat bankvirksomhed Forbrugerfinansiering Islamisk bankvirksomhed Kundeleveringskanaler / Frontend levering

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

Karakteristika for en bankansøgning

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

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

Det skal understøtte tusindvis af samtidige brugersessioner
En bankapplikation skal integreres med andre mange applikationer som handelskonti, Bill-betalingsværktøj, kreditkort osv.
Det skal behandle hurtige og sikre transaktioner
Det skal omfatte massivt lagringssystem.
For at foretage fejlfinding af kundeproblemer skal den have høj revisionsfunktion
Det skal håndtere komplekse forretningsarbejdsprocesser
Brug for at støtte brugere på flere platforme (Mac, Linux, Unix, Windows)
Det skal støtte brugere fra flere placeringer
Det skal understøtte flersprogede brugere
Det skal understøtte brugere på forskellige betalingssystemer (VISA, AMEX, MasterCard)
Det skal understøtte flere servicesektorer (lån, detailbank osv.)
Foolproof mekanisme til katastrofehåndtering

Testfaser i afprøvning af bankansøgninger

Til test af bankapplikationer inkluderer forskellige testfaser

Kravsanalyse: Det udføres af forretningsanalytiker; krav til en bestemt bankapplikation indsamles og dokumenteres
Kravsanmeldelse: Kvalitetsanalytikere, forretningsanalytikere og udviklingsledere er involveret i denne opgave. Dokumentet til indsamling af krav gennemgås på dette stadium og krydstjekkes for at sikre, at det ikke påvirker arbejdsgangen
Dokumentation for forretningskrav: Dokumenter om forretningskrav udarbejdes af kvalitetsanalytikere, hvor alle gennemgange 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, test af regler osv.
Integration Testing: Under Integration Testing integreres og valideres alle komponenter, der er udviklet
Funktionel testning: De sædvanlige softwaretestaktiviteter som forberedelse af testsag, gennemgang af testsag og udførelse af testsag udføres i denne fase
Sikkerhedstest: Det sikrer, at softwaren ikke har nogen sikkerhedsfejl. Under testforberedelsen skal QA-teamet medtage både negative såvel som positive testscenarier for at bryde ind i systemet og rapportere det, før uautoriseret person får adgang til det. Mens banken forhindrer hacking, skal den også implementere et flerlags adgangsvalidering som en engangskodeord. Til sikkerhedstest bruges automatiseringsværktøjer som IBM AppScan og HPWebInspect, mens man bruger manuelle testværktøjer som Proxy Sniffer, Paros proxy, HTTP-ur osv.
Usability Testing: Det sikrer, at forskelligt dygtige mennesker skal kunne bruge systemet som normal bruger. For eksempel ATM med høre- og blindeskriftanlæg for handicappede
Test af brugeraccept: Det er den sidste fase af test udført af slutbrugerne for at sikre, at applikationen er i overensstemmelse med det virkelige verdensscenarie.

Eksempel på test sag til netbanking login applikation

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

Følgende er generiske testsager for at kontrollere enhver bankapplikation

Prøveeksempler
For administrator	Bekræft administrator login med gyldige og ugyldige data Bekræft administrator login uden data Bekræft alle admin-hjemmelinks Bekræft administratorændringsadgangskode med gyldige og ugyldige data Bekræft administratorændringsadgangskode uden data Bekræft administratorændringsadgangskode med eksisterende data Bekræft administratorlogout
Til ny filial	Opret en ny filial med gyldige og ugyldige data Opret en ny filial uden data Opret en ny gren med eksisterende filialdata Bekræft nulstilling og annullering Opdater gren med gyldige og ugyldige data Opdater gren uden data Opdater gren med eksisterende filialdata Bekræft annulleringsmulighed Bekræft sletning af gren med og uden afhængigheder Bekræft filsøgningsmulighed
For 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 annullering og nulstilling Bekræft sletning af roller med og uden afhængighed bekræft links på siden med rolleoplysninger
For kunde & besøgende	Bekræft alle besøgende- eller kundelinks Bekræft kundens login med gyldige og ugyldige data Bekræft kundens login uden data Bekræft bankmandens login uden data Bekræft bankmandens 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 annullering og nulstilling Opdater bruger med gyldige og ugyldige data Opdater bruger med eksisterende data Bekræft annulleringsmulighed Bekræft sletning af brugeren

Udfordringer ved test af bankdomæne og deres afhjælpning

Udfordringer, som tester kan blive udsat for under test af bankdomæne er

Udfordring	Afbødning
At få adgang til produktionsdata og replikere dem som testdata til test er udfordrende	Sørg for, at testdata overholder lovgivningsmæssige krav og retningslinjer Oprethold datahemmeligheden ved at følge teknikker som datamaskering, syntetiske testdata, test af systemintegration osv.
Den største udfordring ved afprøvning af banksystemet er under overgangen af systemet fra det gamle system til det nye system som test af alle rutiner, procedurer og planer. Også hvordan dataene bliver hentet, uploadet og overført til det nye system efter migrering	Sørg for, at datamigreringstest er gennemført Sørg for, at sager om regressionstest udføres på gamle og nye systemer, og at resultaterne stemmer overens.
Der kan være de tilfælde, hvor kravene ikke er dokumenteret godt 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 faser med kravanalyse og bør aktivt gennemgå forretningskravene
Det vigtigste punkt er at kontrollere, om det nævnte system følger de ønskede politikker og procedurer	Test af overholdelse eller lovgivningsmæssige politikker skal udføres
Omfanget og tidslinjerne stiger, da bankapplikationer er integreret med andre applikationer som internet eller mobilbank	Sørg for, at tidsbudget til integrationstest tages i betragtning, hvis din bankapplikation har mange eksterne grænseflader

Resumé

Bankdomæne er det mest sårbare område for cybertyveri, og beskyttelse af softwaren kræver præcis test. Denne vejledning giver en klar idé om, hvad der kræves for banktestdomænetest, og hvor vigtigt det er. Man skal forstå det -

Størstedelen af banksoftware er udviklet på Mainframe og Unix
Test hjælper med at mindske mulige fejl, der opstår under softwareudvikling
Korrekt test og overholdelse af industristandarder sparer virksomheder for sanktioner
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

Deltag i vores Live Banking Domain Testing Project