Volume Testing Tutorial: Eksempler og Volume Testing Tools

volume testing tutorial

Oversigt over volumenprøvning:

Korrelerer nedenstående billede med vores apps på en eller anden måde? Ja, dette sker præcis, når vi overbelaster vores servere, databaser, webservices osv.

Vi skal alle være opmærksomme på funktionel og ikke-funktionel test, men er du opmærksom på, at ikke-funktionel test er lige så vigtig som funktionel test? Til tider i kortvarige frigivelser har vi en tendens til at ignorere denne ikke-funktionelle test, som vi ideelt set ikke burde.

Det skal ikke have noget for os, om produktejeren har givet dette krav eller ej. Vi bør overveje denne test som en del af vores komplette testproces, selv for små udgivelser.

Denne tutorial om Volume Testing giver dig et komplet overblik over dets betydning, behov, betydning, tjekliste og nogle af dens værktøjer for at gøre det muligt for dig at forstå det på en bedre måde.

Hvad du lærer:

• Hvad er volumintest?
• Hvornår er denne test afgørende?
• Hvorfor skal jeg sigte mod volumenprøvning?
• Hvad er min tjekliste til denne test?
• Volume Testing vs Load Testing
• Hvordan udføres denne test?
• Volume Testing Tools
• Konklusion
• Anbefalet læsning

Hvad er volumintest?

Volume Testing er en type ikke-funktionel test. Denne test udføres for at kontrollere datamængden, der håndteres af databasen. Volumetest, også kaldet oversvømmelsestest, er ikke-funktionel test, der udføres for at kontrollere softwaren eller appen for dens ydeevne mod enorme data i databasen.

Databasen strækkes til et tærskelpunkt ved at tilføje en stor mængde data til den, og derefter testes systemet for dets svar.

Dette var teoridelen. Lad mig forklare dig med et par praktiske eksempler for at hjælpe dig med at forstå 'hvornår' del af volumintest.

Hvornår er denne test afgørende?

Ideelt set bør enhver software eller app testes for datavolumen, men i nogle tilfælde hvor dataene ikke er tunge, har vi en tendens til at undgå denne test. Men i nogle tilfælde, hvor data behandles i MB'er eller GB'er dagligt, skal der udføres volumintest.

Følgende er et par eksempler på min egen erfaring i 8 år, der forklarer 'når' delen:

Eksempel 1:

En af mine satsninger var et stort system, der bestod af både webapp og en mobilapp. Men selve webappen havde 3 moduler håndteret af 3 forskellige hold.

Til tider, selv hos os, plejede databasen at blive langsom, når vi alle sammen tilføjede data til vores test. Det var irriterende, og arbejdet plejede at blive hæmmet på grund af den enorme mængde data og for at lette det arbejde, vi var nødt til at rydde op i DB ganske ofte.

Dataene, som det 'live' system håndterede, var omkring GB, og derfor blev webappen meget ofte testet for datamængden sammenlignet med mobilappen. Webappens QA-hold havde deres egne automatiseringsskripter, der kørte om natten og udførte denne test.

Eksempel 2:

Et andet eksempel på min satsning var et økosystem, som ikke kun havde en webapp, men også en SharePoint-app og endda et installationsprogram. Alle disse systemer kommunikerede til den samme database til dataoverførsler. De data, der blev håndteret af dette system, var også meget store, og hvis DB af en eller anden grund bliver langsom, ville installationsprogrammet stoppe med at arbejde.

Derfor blev volumintest udført regelmæssigt, og DB-præstationen blev observeret minutiøst for eventuelle problemer.

Tilsvarende vi kan tageEksempleraf få apps, som vi bruger dagligt til shopping, booking af billetter, økonomiske transaktioner osv., der beskæftiger sig med tunge datatransaktioner og derfor har brug for en volumintest.

På den anden side kan en ideel volumenprøve muligvis ikke altid opnås, da den har sine egne begrænsninger og udfordringer.

Få af dens begrænsninger og udfordringer inkluderer:

• Det er vanskeligt at skabe den nøjagtige fragmentering af hukommelsen.
• Generering af dynamisk nøgle er vanskelig.
• Oprettelse af et ideelt rigtigt miljø, dvs. repliken af ​​den live server kan være vanskelig.
• Automatiseringsværktøjer, netværk osv. Påvirker også testresultaterne.

Nu har vi forstået det hvornår vi er nødt til at udføre denne type test. Lad os også forstå 'hvorfor' vi skal udføre denne test som i, målet eller målet med at udføre denne test.

Hvorfor skal jeg sigte mod volumenprøvning?

Volumetest kan hjælpe dig med at forstå, hvordan dit system passer til den virkelige verden, og det hjælper også med at spare dine penge, som senere vil blive brugt på til vedligeholdelsesformål.

Følgende er få mulige grunde til at udføre denne test:

• Det mest basale behov er at analysere dit systems ydeevne mod øget data. Oprettelse af en enorm mængde data hjælper dig med at forstå ydeevnen på dit system med hensyn til responstid, datatab osv.
• Identificer de problemer, der vil opstå med enorme data og tærskelpunktet.
• Ud over det bæredygtige punkt eller tærskelpunktet bliver systemadfærden, dvs. hvis DB går ned, ikke svarer eller udløber.
• Implementering af løsninger til DB-overbelastning og endda verificering af dem.
• Find ud af det ekstreme punkt i din DB (som ikke kan løses) ud over hvilket systemet vil mislykkes, og der skal derfor træffes forsigtighed.
• I tilfælde af mere end en DB-server, at finde ud af problemerne med DB-kommunikation, dvs. den mest tilbøjelige til at mislykkes ud af dem osv.

Nu ved vi vigtigheden og grunden til at udføre denne test.

ELLER ne oplevelse, som jeg gerne vil dele her, er, at når det gælder mobilapps, er volumenprøvning muligvis ikke nødvendig, fordi kun en person bruger appen ad gangen, og mobilapps er designet til at være enkle .

Så medmindre du har en meget kompleks app med en masse datainddragelse, kan volumintest springes over.

Når du ved, hvad der skal verificeres til dit system eller din app, er den næste ting at gøre at lave en tjekliste, som din app kan definere 'hvad' skal testes.

Hvad er min tjekliste til denne test?

Før vi går ind i nogle eksempler til oprettelse af en tjekliste til din app eller et system, skal vi først forstå nogle få tip, som vi skal huske på, mens vi opretter en tjekliste til volumenprøvning eller fremgangsmåden, før testen startes.

Punkter, der skal huskes:

• Hold udviklerne løbende om din testplan, fordi de ved meget om systemet og kan give dig input og endda flaskehalse.
• Forstå det fysiske aspekt som i serverkonfigurationer, RAM, processor osv., Inden du strategiserer testen.
• Forstå kompleksiteten i DB, procedurerne, DB-scripts osv. I det mulige omfang, så du kan skitsere dit systems kompleksitet overordnet.
• Forbered informatik, dvs. grafer, datablad osv., Hvis det er muligt for den normale datamængde, og hvor godt systemet er, vil dette hjælpe dig med at sikre dig, at ydeevnen er god til normal datalæsning, før du stresser DB. Dette vil også hjælpe dig med at sikre, før du går videre til den stressende del, at der ikke er nogen problemer, der kræver en rettelse til din volumintest.

Følgende er nogle eksempler, som du kan tilføje eller bruge i din tjekliste:

• Kontroller, om datalagringsmetoderne er korrekte.
• Kontroller, om systemet har de nødvendige hukommelsesressourcer eller ej.
• Kontroller, om der er nogen risiko for datavolumen, der er større end en specificeret grænse.
• Kontroller og observer systemets reaktion på datamængden.
• Kontroller, om dataene går tabt under volumenprøvning.
• Kontroller, at hvis data overskrives, gøres det med forudgående information.
• Identificer de områder, der strækker sig ud over det normale interval som mange attributter (søgbar), stort nr. af opslagstabeller, mange placeringskort osv.
• Som tidligere nævnt skal du først oprette en basislinje ved at få resultater for den normale lydstyrke og derefter gå videre med stress.

Før vi går videre til de andre eksempler, testcases og værktøjer, skal vi først forstå, hvordan denne test adskiller sig fra belastningstest.

Volume Testing vs Load Testing

Nedenfor er nogle af de største forskelle mellem volumen- og belastningstest:

Hvordan udføres denne test?

Denne test kan udføres både manuelt eller ved hjælp af ethvert værktøj. Generelt vil brug af værktøjer spare vores tid og kræfter, men i tilfælde af lydstyrketest, som det er min erfaring Brug af værktøjer kan give dig mere nøjagtige resultater sammenlignet med manuel test.

Før du påbegynder din udførelse af testsagen, skal du sørge for at:

• Holdet har aftalt testplanen for denne test.
• Andre teams i dit projekt er velinformerede om databaseændringerne og dens indvirkning på deres arbejde.
• Testsengene er indstillet til de angivne konfigurationer.
• Basislinjen til test er udarbejdet.
• De specifikke datamængder til testning (datascript eller procedurer osv.) Er klar. Du kan læse om dataoprettelsesværktøjer på vores datagenereringsside.

Lad os se få eksempler på testtilfælde, som du kan bruge til udførelse:

Bekræft dette for alle de valgte datavolumener til volumetest:

1. Kontroller, om tilføjelse af data kan udføres med succes, og om det afspejles i appen eller webstedet.
2. Kontroller, om sletning af data kan udføres med succes, og om det afspejles i appen eller webstedet.
3. Kontroller, om opdatering af data kan udføres med succes, og om det afspejles i appen eller webstedet.
4. Kontroller, at der ikke er noget datatab, og at alle oplysninger vises som forventet i appen eller webstedet.
5. Kontroller, at appen eller websiderne ikke udløber på grund af den høje datamængde.
6. Kontroller, at nedbrudte fejl ikke vises på grund af høj datavolumen.
7. Kontroller, at data ikke overskrives, og at korrekte advarsler vises.
8. Bekræft, at andre moduler på dit websted eller din app ikke går ned eller tidsindstilles med høj datavolumen.
9. Kontroller, at responstiden for DB er inden for det acceptable interval.

Volume Testing Tools

Som tidligere omtalt sparer automatiseringstest tid og giver endda nøjagtige resultater sammenlignet med manuel test. En anden fordel ved at bruge værktøjer til volumenafprøvning er, at vi kan køre testene om natten, og på den måde vil arbejde fra de andre teams eller teammedlemmer ikke blive påvirket af DB'ens datamængde.

Vi kan planlægge testene om morgenen, og resultaterne vil være klar.

Følgende er en liste over få open source-volumen testværktøjer:

# 1) DbFit:

Dette er et open source-værktøj, der understøtter testdrevet udvikling.

DbFit testrammen er skrevet oven på Fitness, testene er skrevet ved hjælp af tabeller og kan udføres ved hjælp af ethvert Java IDE- eller CI-værktøj.

#2) HammerDb:

HammerDb er også et open source-værktøj, der kan automatiseres, multi-threaded og endda tillader run-time scripting. Det kan arbejde med SQL, Oracle, MYSQL osv.

# 3) JdbcSlim:

JdbcSlim kommandoer kan let integreres i Slim Fitness, og den understøtter alle databaser, der har en JDBC-driver. Fokus er på at holde konfigurationen, testdata og SQL-forespørgsler separat.

# 4) NoSQLMap:

Det her er et open source Python-værktøj, der er designet til automatisk at injicere angreb og forstyrre DB-konfigurationerne for at analysere truslen. Det fungerer kun for MongoDB.

# 5) Ruby-PLSQL-spec:

PLSQL kan enhedstestes ved hjælp af Ruby, da Oracle fås som et open source-værktøj. Det her bruger dybest set to biblioteker: Ruby-PLSQLog Rspec.

Konklusion

Volumetest er ikke-funktionel test, der udføres for at analysere databasens ydeevne. Det kan gøres manuelt såvel som ved hjælp af nogle værktøjer.

Hvis du er en kvalitetssikring, der er ny med denne test, vil jeg foreslå at lege med værktøjet eller udføre nogle testsager først. Dette hjælper dig med at forstå begrebet volumenprøvning, inden du springer i test.

spørgsmål og svar til adfærdssamtaler for forretningsanalytikere

Denne test er ret vanskelig, og den har sine egne udfordringer, og derfor er det meget vigtigt at have en grundig viden om konceptet, oprettelse af testbed og DB-sproget, før du udfører det.

Håber denne tutorial ville have øget din videnmængde om dette emne :)

Anbefalet læsning

• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Parvis test eller test af selvstudier med værktøjer og eksempler
• Funktionel testning mod ikke-funktionel testning
• Konfigurationstestvejledning med eksempler
• Test af Primer eBook Download
• Destruktiv test og ikke-destruktiv testvejledning
• 11 bedste automatiseringsværktøjer til test af Android-applikationer (Android App-testværktøjer)
• Bedste IVR-testværktøjer: CYARA og HAMMER-testvejledning