how test banking domain applications
En komplett guide för testning av bankansökan: BFSI (bank, finansiella tjänster och försäkringar) Testprocess och tips
Bankapplikationer är en av de mest komplexa applikationerna i dagens mjukvaruutveckling och testindustri.
Vad gör bankapplikationer så komplexa? Vilket tillvägagångssätt bör följas för att testa de komplexa arbetsflödena som är involverade i bankapplikationer?
I den här artikeln kommer vi att belysa olika steg och tekniker som är involverade i testning av bankapplikationer.
Vad du kommer att lära dig:
- Hur testar jag bankansökningar?
- Betydelsen av att testa bankansökan
- Bankflödestestningsflöde
- Exempel på testfall för bankansökan
- Slutsats
Hur testar jag bankansökningar?
Olika funktioner som utförs av bankapplikationer är:
Låt oss först förstå egenskaperna hos en bankansökan:
- Multi-tier-funktionalitet för att stödja tusentals samtidiga användarsessioner
- Storskalig integration: Normalt integreras en bankapplikation med många andra applikationer som Bill Pay-verktyg och handelskonton
- Komplexa arbetsflöden
- Realtids- och batchbehandling
- Den höga transaktionsfrekvensen per sekund
- Säkra transaktioner
- Robust rapporteringsavsnitt för att hålla koll på dagliga transaktioner
- Stark revision för att felsöka kundfrågor
- Massivt lagringssystem
- Katastrofhantering / återhämtning.
Ovanstående tio punkter är viktigaste egenskaperna hos en bankapplikation.
Bankapplikationer har flera nivåer involverade i att utföra en operation.
Till exempel , till Bankansökan kan ha:
- Webbserver för att interagera med slutanvändare via webbläsaren
- Middle Tier för att validera in- och utdata för webbservern
- DataBase för att lagra data och procedurer
- Transaktionsprocessor som kan vara en stor kapacitet Mainframe eller något annat äldre system för att utföra biljoner transaktioner per sekund.
Om vi pratar om att testa bankapplikationer kräver det ett End to End Testing-metodik som involverar flera tekniker för testning av programvara för att säkerställa:
- Total täckning av alla bankarbetsflöden och affärskrav
- Den funktionella aspekten av applikationen
- Säkerhetsaspekten av applikationen
- Dataintegritet
- Samtidighet
- Användarupplevelse
Vad gör bankapplikationer så komplexa?
- Bankprogramvara behandlar främst konfidentiella ekonomiska data så att programvarans prestanda ska vara felfri och säker.
- Utvecklare föredrar en komplicerad design för att utveckla dessa applikationer för att säkerställa att applikationen körs på ett önskat säkert sätt.
- Bank är en ständigt föränderlig värld. Banktjänster görs idag tillgängliga för kunden via olika kanaler som brick & mortar-filialer, bankomater, internetbank och kundvård.
- Med tillkomsten av teknik har många plånböcker översvämmat marknaderna som ansluter till banksystemen för finansiella transaktioner.
- Bank förväntas också vara igång 24 X 7 med hög prestanda. Mjukvaruuppgraderingar, snabbkorrigeringar etc. kan inte tillåtas påverka denna tillgänglighet.
- Bankvärlden påverkas också starkt av de ständiga förändringar som regeringen infört i form av bankregler. Eventuella förändringar i skattestrukturen påverkar också banksystemet.
- Banksystemet måste också vara uppdaterat vad gäller ny teknik. Dataanalys som Big Data Processing och att få instinkter från big data med hjälp av Data Science ökar dragkraften i bankvärlden.
Ovan nämnda punkter gör banksystemet komplicerat för utvecklare att skapa en programvara runt det.
Betydelsen av att testa bankansökan
- Testning av bankapplikationen säkerställer att alla aktiviteter inte bara utförs väl utan också förblir skyddade och säkrade.
- Bankprogramvara är komplicerad med tusentals beroenden, testprocessen kräver mer tid, resurser och kontinuerlig övervakning.
- Eftersom ekonomin är inblandad måste riktlinjer följas strikt. Både testare och utvecklare bör ha god domänkunskap.
- Det viktigaste är att det måste säkerställas att lagar och regler tillämpas korrekt i finansiella transaktioner. Detta kan endast säkerställas med testning.
- Det är också viktigt att se till att applikationen och infrastrukturen som applikationen har distribuerats kan hantera belastningen, särskilt under högsta arbetstid, utan att orsaka några störningar. Detta kan säkerställas genom att utföra prestandatest.
- I dagens digitala värld är det en sak som berör alla säkerheten. Bankapplikationerna och de finansiella transaktionerna som utförs inom den måste vara säkra från varje försök att bryta in. Detta kan säkerställas genom att utföra säkerhetstester. Säkerhetstestning hjälper till att upprätthålla branschstandarder för att säkra finansiella transaktioner.
- Det är också viktigt att se till att olika moduler i en bankapplikation integreras ordentligt och uppnå kundens mål. System Integration Testing hjälper till att uppnå denna uppgift.
Bankflödestestningsflöde
Typiska steg involverade i testning av bankapplikationer visas i nedanstående arbetsflöde. Vi kommer att diskutera varje steg individuellt.
Detta är en vattenfallsmodell för att testa en applikation.
# 1) Kravsamling
Kravsamlingsfas innebär dokumentation av krav antingen som funktionsspecifikationer eller som användningsfall. Krav samlas in enligt kundernas behov och dokumenteras av bankexperter eller affärsanalytiker.
Experter är inblandade i att skriva krav på mer än ett ämne, eftersom banken i sig har flera underdomäner och en fullfjädrad bankapplikation är integrationen av alla dessa domäner.
Till exempel, En bankapplikation kan ha separata moduler för överföringar, kreditkort, rapporter, lånekonton, fakturering, handel etc.
# 2) Kravgranskning
Leveransen av kravsamling granskas av alla intressenter som QA-ingenjörer, utvecklingsledare och peer-affärsanalytiker.
De kryssar för att varken befintligt arbetsflöde eller nya arbetsflöden bryts. Alla krav är verifierade och validerade. Uppföljningsåtgärder och kravdokumentrevisioner görs baserat på samma.
# 3) Förberedelser för affärsscenario
I detta skede hämtar QA-ingenjörer affärsscenarier från kravdokumenten (Funktionsspecifikationer eller Användningsfall); Affärsscenarier härleds på ett sådant sätt att alla affärsbehov täcks. Affärsscenarier är scenarier på hög nivå utan några detaljerade steg.
Vidare granskas dessa affärsscenarier av affärsanalytiker för att säkerställa att alla affärskrav uppfylls. Det är lättare för BAs att granska scenarier på hög nivå snarare än att granska detaljerade testfall på låg nivå.
Till exempel kan en kund som öppnar en fast insättning på det digitala bankgränssnittet vara ett affärsscenario. På samma sätt kan vi ha olika affärsscenarier relaterade till skapande av nätbank, kontoinsättningar, onlineöverföringar etc.
# 4) Funktionstestning
I detta skede utförs funktionstestning och de vanliga programvarutestningsaktiviteterna utförs såsom:
Förberedelse av testfall: I detta skede härrör testfall från affärsscenarier, ett affärsscenario leder till flera positiva testfall och negativa testfall. Generellt är verktyg som används under detta steg Microsoft Excel, Test Director eller Quality Center.
Testfall Granskning: Recensioner från peer QA Engineers
Testfall Avrättning: Testfallskörning kan vara antingen manuell eller automatisk med verktyg som QC, QTP, etc.
Funktionstestningen av en bankapplikation skiljer sig ganska från vanlig programvarutestning. Eftersom dessa applikationer fungerar med kundens pengar och känsliga ekonomiska data måste de testas noggrant. Inget viktigt affärsscenario bör lämnas för att täckas.
QA-resursen som testar applikationen bör också ha grundläggande kunskaper om bankdomänen.
# 5) Databastestning
Bankansökan innefattar komplexa transaktioner som utförs både på UI-nivå och databasnivå. Därför är databastestning lika viktigt som funktionstestning. Databasen är komplicerad och ett helt separat lager i applikationen och testningen utförs därför av databasspecialister. Den använder tekniker som:
- Data laddas
- Databasmigrering
- Testa DB-schema och datatyper
- Regeltestning
- Testa lagrade procedurer och funktioner
- Testa utlösare
- Dataintegritet
Huvudsyftet med databastester är att säkerställa att:
- Applikationen kan lagra och hämta data från databasen utan förlust av data.
- Slutförda transaktioner bör göras och avbrutna transaktioner återställs för att undvika otillbörlig lagring av data.
- Endast behöriga applikationer och användare har åtkomst till databasen och de underliggande tabellerna.
Det finns främst tre sätt att testa databaser:
- Strukturell testning
- Funktionell testning
- Icke-funktionell testning
Strukturell testning
Det handlar om att testa databasobjekten som databaser, schema, tabeller, vyer, utlösare, åtkomstkontroller etc. Säkerställa att datatyper i tabeller är synkroniserade med motsvarande variabler i applikationen. Validera data och referensintegritet i tabellerna.
Till exempel, Ett beloppsfält i applikationen ska ha en datatyp av decimal / flyt i tabellen.
- För att uppfylla standarder bör användarna ges åtkomstkontroller genom vyer.
Funktionell testning
Det handlar om att testa de databaser som uppfyller användarkraven. Det finns två sätt att uppnå: Black Box-testning och White Box-testning.
Till exempel, När vi gör en onlineöverföring online ska avsändarkontot debiteras och mottagarkontot krediteras med exakt samma belopp. Om transaktionen misslyckas bör hela transaktioner återställas och avsändarkontot ska inte debiteras eller krediteras tillbaka.
Icke-funktionell testning
Det innebär belastning och stresstestning och optimering av prestanda. Lasttestning hjälper till att identifiera flest antal transaktioner som kan utföras samtidigt utan att påverka databasprestanda.
Till exempel, Baserat på input från belastning och stresstestning kan bankapplikationer besluta att lägga till fler resurser till sin applikation under högsta arbetstid och minska resurserna under arbetstid. Detta hjälper banken att utnyttja resurserna optimalt och spara pengar.
# 6) Säkerhetstestning
Säkerhetstestning är vanligtvis det sista steget i testcykeln. En förutsättning för att påbörja säkerhetstester är slutförandet av funktionell och icke-funktionell testning. Säkerhetstestning är ett av de viktigaste stegen i hela applikationsprovningscykeln, eftersom detta steg säkerställer att applikationen uppfyller federala och industristandarder.
På grund av de uppgifter de har med sig är bankappar mycket känsliga och är ett främsta mål för hackare och bedrägliga aktiviteter. Säkerhetstestning säkerställer att applikationen inte har någon sådan webbsårbarhet som kan exponera känslig data för en inkräktare eller en angripare. Det försäkrar också att applikationen uppfyller standarder som OWASP.
I det här steget är huvuduppgiften hela applikationsgenomsökningen som utförs med verktyg som IBM AppScan eller HP WebInspect (dessa är de mest populära verktygen).
När skanningen är klar publiceras skanningsrapporten. Under denna rapport filtreras False Positives bort och resten av sårbarheterna rapporteras till utvecklingsteamet så att de börjar fixa problemen beroende på svårighetsgraden för varje problem.
Penetrationstestning görs också i detta steg för att avslöja förökningen av fel. Noggranna säkerhetstester bör göras över plattformar, nätverk och operativsystem.
Någon annan Manuella verktyg för säkerhetstestning används är Paros Proxy , Http Watch , Burp Suite och Befästa.
Huvudsyftet med säkerhetstestning är att lokalisera eventuella sårbarheter som programvaran kan ha.
Säkerhetstestningen testar ansökan mot:
- Varje extern attack eller försök att hacka applikationen med skadlig avsikt.
- Varje kryphål i programvaran kan utnyttjas och orsaka data eller monetära förluster.
- Varje sårbarhet i nätverket, servrarna och arbetsstationerna som är värd för applikationen.
Följande är de olika typerna av säkerhetstester:
Test av sårbarhet: Ett automatiserat program utvecklas och körs för att kontrollera om det finns olika sårbarheter.
Säkerhetsskanning: Denna variant kretsar kring att undersöka sårbarheter i nätverk och system, tillhandahålla lösningar för att minska tillhörande risk.
Penetrationstest: Denna variant av säkerhetstest imiterar ett hackningsförsök att fånga sårbarheter och kryphål, som annars skulle ha kunnat få tillgång till databasen eller applikationsdata.
Säkerhetsgranskning: Det handlar om granskning av applikationen och tillhörande nätverk för eventuella säkerhetsfel.
Riskbedömning: Denna variant gör en analys för att bedöma risknivån i händelse av att en sårbarhet eller kryphål utnyttjas för skadlig avsikt. Sådan risk kan kategoriseras till låg, medium och hög. Baserat på risknivån rekommenderas teståtgärder för att minska eller avvärja risken.
Etiskt hackande: Detta utförs av en organisation på sina system för att identifiera kryphål som kan utnyttjas i dess applikation eller nätverk. Syftet med denna typ av hacking är inte att stjäla eller skada applikationen eller nätverket.
Bedömning av hållning: Detta är en paraplybedömning som består av säkerhetsskanning, riskbedömningar och etisk hacking.
SQL-injektion: SQL Injection kan användas för att få tillgång till serverdatabasen. Testningen görs för att säkerställa att koden fungerar korrekt, vilket kör frågor i databasen baserat på följande ingångar från användaren:
- Fästen
- Apostrofer
- Komma
- Citattecken
Andra steg i testning av BFSI-appen
Bortsett från ovanstående huvudsteg kan det finnas olika steg inblandade, såsom integrationstestning, användbarhetstestning, användaracceptansprovning och prestandatestning.
Låt oss också i korthet prata om dessa steg:
Integrationstestning
Som du vet att det i en bankapplikation kan finnas flera olika moduler som överföringar, fakturabetalningar, insättningar etc. Och därmed finns det många komponenter utvecklade. I integrationstest integrerade alla komponenter och validerades tillsammans.
Användbarhetstestning
En bankapplikation betjänar ett stort antal kunder. Vissa av dessa kunder kanske saknar den kompetens och medvetenhet som krävs för att utföra bankuppgifterna via appen.
Därför bör bankapplikationen testas för enkel och effektiv design för att göra den användbar i olika kundgrupper. Det enklare och lättanvända gränssnittet är, desto högre antal kunder kommer att dra nytta av bankapplikationen.
Det handlar om att undersöka den lätthet som affärsanvändare eller bankkunder har att använda applikationen. Denna testning utförs inte av utvecklaren eller testaren utan utförs av företagsanvändarna.
Till exempel, Numera använder alla mobilappar. Bankappen ska vara användarvänlig och lätt att förstå och använda av slutanvändaren.
Typer av användbarhetstestning
Jämförande användbarhetstestning: Detta är jämförelsebaserad testning, där användarvänligheten för en webbplats eller applikation med en annan är enkel. Målet för sådan testning är att ge den bästa användarupplevelsen.
Explorativ användbarhetstest: Syftet med denna testning är att identifiera vilka funktioner den nya applikationen eller programvaran ska ha för att uppfylla bankens kundkrav.
Följande är fördelar och nackdelar med användbarhetstestning
bra mp3-nedladdningsapp för android
Fördelar:
- Slutanvändarna av applikationen är vanligtvis inblandade i testet, varför första hand feedback erhålls.
- I stället för att spendera tid på analys och diskussion om en funktion som en produkt ska ha eller inte, är det bättre att få insatserna från slutanvändaren direkt.
- Vi kan fånga upp eventuella problem i förväg.
Nackdelar:
- Eftersom flera slutanvändare är involverade i testning kan deras åsikter om inte exakta påverka kravet.
- Flödet från slutanvändare kan bli påverkat.
Prestandatester
Vissa tidsperioder som lönedag, räkenskapsårets slut, festliga årstider kan medföra förändring eller ökad trafik i appen. Därför bör noggranna prestandatester göras så att kunderna inte påverkas av prestationsfel.
Ett betydelsefullt exempel från det förflutna där bankkunder drabbades personligen på grund av prestandafel är NatWest och RBS cybermåndag IT-avbrott där kunderna fick sina betalkort och kreditkort fick avvisade transaktioner över butiker i landet.
Test av användaracceptans
Detta görs genom att slutanvändarna involveras för att säkerställa att applikationen uppfyller de verkliga scenarierna och kommer att accepteras av användarna om den går live.
I dagens scenario majoriteten av bankprojekten använder : Agile / Scrum, RUP och kontinuerlig integrationsmetodik och verktygspaket som Microsofts VSTS och Rational Tools.
Som vi nämnde om RUP ovan står RUP för Rational Unified Process, som är en iterativ mjukvaruutvecklingsmetod som introducerats av IBM som består av fyra faser där utvecklings- och testaktiviteter utförs.
Fyra faser är
i) Start
ii) Samarbete
iii) Konstruktion och
iv) Övergång
RUP involverar i stor utsträckning IBM Rational-verktyg.
Exempel på testfall för bankansökan
Testfall för New Branch
- Skapa en ny gren med giltiga och ogiltiga testdata.
- Skapa en ny filial utan data.
- Skapa en ny gren med befintlig filialdata.
- Verifiera återställnings- och avbrytningsalternativen.
- Uppdatera greninformation med giltiga och ogiltiga testdata.
- Uppdatera greninformation med befintlig filtestdata.
- Kontrollera om den nya filialen kan sparas.
- Kontrollera att alternativet avbryt fungerar.
- Verifiera borttagningen av filialen med och utan beroenden.
- Kontrollera om filialens sökalternativ fungerar.
Testfall för ny roll
- Skapa en ny roll med giltiga och ogiltiga testdata.
- Skapa en ny roll utan data.
- Kontrollera att en ny roll kan skapas med befintliga testdata.
- Verifiera rollbeskrivningen och rolltyperna.
- Kontrollera att alternativet avbryt och återställ fungerar.
- Verifiera rollborttagningsprocessen med och utan beroende.
- Verifiera länkarna på sidan Rollinformation.
- Verifiera administratörsinloggningen utan testdata.
- Verifiera alla hemlänkar för adminrollen.
- Kontrollera att administratören kan ändra lösenordet med giltiga och ogiltiga testdata.
- Verifiera administratörens utloggning framgångsrikt.
Testfall för kund och banker
- Kontrollera om alla besökar- och kundlänkar fungerar korrekt.
- Verifiera kundinloggningen med giltiga och ogiltiga testdata.
- Verifiera kundinloggningen utan några data.
- Verifiera bankinloggningen utan några data.
- Verifiera bankinloggningen med giltiga eller ogiltiga testdata.
- Kontrollera att kunden eller bankiren kan logga ut.
Testa fall för nya användare
- Kontrollera om den nya användaren kan skapas med giltiga och ogiltiga testdata.
- Skapa en ny användare med befintliga filtestdata
- Kontrollera om alternativet avbryt och återställ fungerar korrekt.
- Uppdatera användardetaljer med giltiga och ogiltiga testdata.
- Verifiera borttagningen av den nya användaren.
- kontrollera om den nya användaren kan verifieras.
- Verifiera obligatoriska ingångsparametrar.
- Verifiera valfria ingångsparametrar.
- Kontrollera om en användare kan skapas utan valfria parametrar.
Testa fall för att skapa ett nytt konto
- Skapa ett nytt konto med giltig och ogiltig användardata.
- Kontrollera om användarinformation kan uppdateras.
- Kontrollera om en ny användare kan sparas.
- Skapa ett nytt konto med den befintliga användarens data.
- Kontrollera att användaren kan sätta in beloppet på det nyskapade kontot (och uppdatera saldot).
- Kontrollera att användaren kan ta ut ett belopp från det nya kontot (efter insättning och uppdatera saldot).
- Vid lön kontrollerar du att företagsnamnet och andra uppgifter tillhandahålls av användaren.
- Kontrollera om det primära kontonumret anges i fallet med ett sekundärt konto.
- Verifiera användaruppgifter som tillhandahålls i fall med det aktuella kontot.
- Verifiera de tillhandahållna bevisen för gemensamt konto i händelse av ett gemensamt konto.
- Kontrollera om du kan upprätthålla nollbalansen på lönekontot.
- Kontrollera om du kan upprätthålla noll- eller minimisaldo för icke-lönekontot.
- Verifiera att den nya användaren kan logga ut.
Testfall för nätbankansökan
- Kontrollera om användaren kan öppna bankwebbplatsen.
- Kontrollera om alla länkar på webbplatsen fungerar.
- Kontrollera om användaren kan skapa ett nytt konto.
- Kontrollera om användaren kan logga in med giltigt och ogiltigt användarnamn och lösenord.
- Kontrollera om något av användarnamnet eller lösenordet är tomt när du loggar in, användaren ska inte få logga in och ett varningsmeddelande visas.
- Kontrollera om användaren får ändra lösenordet.
- Om en ogiltig användare eller lösenord anges anges korrekt felmeddelande.
- Användare med ogiltigt lösenord bör inte få logga in.
- Kontrollera att efter upprepade försök att logga in med fel lösenord ska användaren visas ett felmeddelande och blockeras.
- Kontrollera om användaren kan utföra grundläggande transaktioner.
- Kontrollera att användaren kan lägga till en mottagare med giltiga och ogiltiga uppgifter.
- Kontrollera om användaren kan radera mottagaren.
- Kontrollera att användaren kan göra transaktioner till den nyligen tillagda mottagaren.
- Kontrollera efter transaktionen om konton för både användare och mottagare uppdateras.
- Kontrollera om användaren kan ange beloppet i decimaltal.
- Kontrollera om användaren inte kan ange negativa siffror i fältet belopp.
- Kontrollera om användaren får göra transaktioner med eller utan minsta saldo.
- Kontrollera om användaren kan göra en ny RD.
- Kontrollera att korrekt meddelande visas i händelse av en transaktion med otillräcklig balans.
- Kontrollera om användaren ombeds bekräfta innan någon transaktion görs.
- Verifiera om kvitto för varje godkänd transaktion bekräftas.
- Kontrollera om användaren kan överföra pengar till flera konton.
- kontrollera om användaren kan avbryta transaktionen.
- Kontrollera att kontouppgifterna återspeglar finansiella transaktioner också.
- Kontrollera att timeout-funktionen är implementerad.
- verifiera att användaren ska logga in igen vid sessionstime.
- verifiera att rätt sessionstidsgräns görs i händelse av inaktivitet.
- verifiera att användaren förflyttas till säkert läge medan han gör transaktionen.
- Kontrollera om användaren kan logga ut.
- Verifiera sök- och återställningsalternativ.
Slutsats
I den här artikeln diskuterade vi hur komplex en bankapplikation kan vara och vad är det typiska faser involverade i testning av applikationen . Bortsett från det diskuterade vi också aktuella trender följda av IT-branscher inklusive programvaruutvecklingsmetoder och verktyg.
Dela gärna dina erfarenheter eller frågor om detta ämne!
Rekommenderad läsning
- Hur man testar investeringsbankansökan (med 34+ viktiga testscenarier)
- Hur man testar detaljhandelns banksystem
- Hur man testar vårdansökan - Del 1
- Bästa verktyg för testning av programvara 2021 [QA Test Automation Tools]
- Alpha Testing och Beta Testing (En komplett guide)
- Testing Primer eBook Download
- Funktionell testning mot icke-funktionell testning
- Installera applikationer och förbereda dem för testning av appium