Hvad er volumentestning? Lær med eksempler

⚡ Smart opsummering

Volumentestning udsætter en applikation for en meget stor mængde data for at se, hvordan lagring, forespørgsler og svartider opfører sig, efterhånden som databasen vokser. Det kaldes også flood testing, og det skalerer dataene snarere end antallet af brugere.

💾 Kernedefinition: Datamængden øges, mens brugerbelastningen forbliver normal.
🔍 Primære kontroller: Datatab, lydløs overskrivning, lagringsnøjagtighed og svartid under et stort datasæt.
📈 Nedbrydningspunkt: Testen lokaliserer det volumen, hvor stabilitet og ydeevne begynder at falde.
⚖️ Ikke belastningstest: Volumen skalerer rækker og filstørrelser; indlæsning skalerer samtidige brugere. De to finder forskellige defekter.
🧪 Datarealisme: Genererede data skal respektere nøgler og relationel integritet, hvilket er den sværeste del af testen.
💰 Business Case: Kapacitetsbegrænsninger fundet før frigivelse koster en brøkdel af de samme begrænsninger, der findes i produktionen.

Læs mere

Hvad er volumentestning?

Volumentestning er en type softwaretest, hvor softwaren udsættes for en enorm mængde data. Det omtales også som oversvømmelsestest. Volumentest udføres for at analysere systemets ydeevne ved at øge mængden af data i databasen.

Ved hjælp af volumentestning kan indvirkningen på responstid og systemadfærd studeres, når de udsættes for en stor mængde data.

For eksempel kan en musikstreamingtjeneste testes med et katalog på 50 millioner tracks og en tabel med lyttehistorik, der indeholder milliarder af rækker, for at se, om søge- og anbefalingsforespørgsler stadig returneres inden for en acceptabel tid.

Bemærk forskellen: volumentestning øger mængden af data systemet holder. Øger antal samtidige brugere er belastningstest, som er en anden test med et andet formål.

Fordele ved volumentestning

Tidlig identifikation af kapacitetsproblemer undgår de langt højere omkostninger ved at løse dem i produktionen
Det hjælper med en hurtigere start for skalerbarhedsplaner
Tidlig identifikation af flaskehalse
Det sikrer, at dit system nu er i stand til brug i den virkelige verden

Hvorfor udføre volumentestning?

Formålet med at udføre volumentestningen er at

Tjek systemets ydeevne med stigende datamængder i databasen
Identificer de problemer, der sandsynligvis vil opstå, når datasættet bliver stort
For at finde ud af det punkt, hvor systemets stabilitet forringes
Volumentestning vil hjælpe med at identificere kapaciteten af systemet eller applikationen – normal og tung volumen

Sådan udfører du volumentestning

Ved volumentest skal følgende ting testes

Test for at kontrollere, om der er datatab
Tjek systemets responstid
Tjek, om dataene er lagret korrekt eller ej
Bekræft, om dataene er overskrevet uden nogen meddelelse
Kontroller, at advarsler og fejlmeddelelser rent faktisk vises, når en volumengrænse er nået
Kontroller, om data i høj volumen påvirker behandlingshastigheden
Bekræft, at systemet har de hukommelses- og lagerressourcer, som diskenheden kræver
Bekræft, at volumentesten dækker hele systemet i stedet for en enkelt komponent
Er der nogen risiko, hvis datamængden er større end specificeret
Fastslå, om der er nogen garanti for, at datamængden ikke vil overstige den angivne maksimale mængde

Bedste Practices for High Volume Testing

Flere af nedenstående fremgangsmåder deles med load testing, fordi de to normalt køres mod det samme miljø. De volumenspecifikke fremgangsmåder vedrører selve datasættet:

Stop alle servere og tjek alle logfiler
Før belastningstesten skal du udføre applikationsscenariet manuelt
For de mest nyttige resultater forskydes antallet af brugere
For at overvinde licensbegrænsninger, balancere tænketid
Vær forsigtig med det nye byggeri
Analyser use casen for forbedring, når en baseline er blevet etableret
En gentagelse af bestemte dele af volumentestning bliver uundgåelig, hvis der er en flaskehals i ydeevnen

Volumentest vs. belastningstest

Volumentestning	Load Testing
Volumentestning kontrollerer, hvordan en applikation opfører sig, når databasen indeholder en meget stor mængde data.	Under belastningstestning udsættes applikationen for et vist belastningsniveau for at analysere applikationens adfærd
Volumentestning verificerer, at systemet stadig reagerer korrekt ved en given datamængde. Det øger typisk størrelsen på filer og tabeller.	Load testing kontrollerer ydeevnen, når belastningen fra samtidige brugere øges. Det øger typisk antallet af samtidige anmodninger.

Udfordringer i volumentestning

Fragmentering af hukommelse vanskelig at generere
Dynamisk generering af nøgler
Relationel Integrity af genererede data

Hvordan denne test sammenlignes med andre præstationstests

Ydelsestestning er en familie af tests, der adskiller sig i formen af den påførte belastning, hvilket er grunden til, at de så let forveksles.

Testtype	Hvad er øget	Spørgsmål det besvarer
Belastningstest	Samtidige brugere, til den forventede top	Opfylder det målene under normal spidsbelastning?
Volumentest	Data opbevaret i databasen	Klarer den sig, når datasættet vokser?
Stresstest	Belast ud over kapacitet, indtil fejl	Hvor går den i stykker, og hvordan?
Spike test	Indlæs, øjeblikkeligt og ekstremt	Overlever den og kommer den sig efter et chok?
Udholdenhedstest	Varighed ved normal belastning	Forringes ydeevnen over tid?
Soak-test	Varighed, observationsressourcer	Er der hukommelses- eller handle-lækager?
Stabilitetstest	Varierende forhold	Forbliver den pålidelig, når forholdene ændrer sig?

Den mest betydningsfulde forskel her: Volumentest skalerer dataene, belastningstest skalerer brugerne. En rapport, der kører på to sekunder mod ti tusinde rækker og to minutter mod ti millioner rækker, har et volumenproblem, ikke et belastningsproblem, og ingen ekstra serverkapacitet vil løse det.

Sådan genereres testdata til volumentestning

Afsnittet om udfordringer bemærker, at generering af realistiske data er den vanskelige del af volumentestning. Fire tilgange anvendes i praksis, og hver især involverer et kompromis.

Tilgang	Realisme	Vigtigste ulempe
Kopi af produktionsdata	Højeste	Eksponering for privatliv og overholdelse af regler
Maskeret produktionseksemplar	Høj	Maskering kan ødelægge referentiel integritet
Syntetisk generation	Medium	Fordelinger stemmer muligvis ikke overens med virkeligheden
Genafspillet produktionstrafik	Høj	Kræver opsamlingsinfrastruktur

Uanset hvilken vej du vælger, skal tre egenskaber være gældende, ellers måler testen intet brugbart.

Referentiel integritet. Enhver fremmednøgle skal fortolkes. En million forældreløse rækker bruger lagringsprogrammet, men aldrig de join-stier, som applikationen rent faktisk bruger.
Realistisk kardinalitet. Hvis produktionstabellen har ti millioner rækker på tværs af to hundrede kunder, vil generering af ti millioner rækker på tværs af ti millioner kunder producere helt andre forespørgselsplaner.
Realistisk fordeling. Reelle data er skæve. Ensartet tilfældige data skjuler de aktive partitioner og indekskonflikter, der forårsager produktionshændelser.

En praktisk advarsel om privatliv. Kopiering af produktionsdata til et testmiljø er den mest almindelige årsag til databrud i forbindelse med test. Maskér personlige felter, før kopien forlader produktionen, ikke bagefter.

Ofte Stillede Spørgsmål

Volumentest øger mængden af data i systemet, mens brugerbelastningen forbliver normal. Belastningstest øger mængden af samtidige brugere, mens datasættet forbliver normalt. De afslører forskellige flaskehalse, så begge er nødvendige.

Start med den forventede datamængde ved udgangen af den planlagte kapacitetshorisont, typisk to til tre års vækst, test derefter ved dette tal og fordoble det for at finde ud af, hvor forringelsen begynder.

Manglende eller ineffektive indeks, forespørgsler, der skalerer ikke-lineært, lagerudtømning, lydløs afkortning af felter og batchjob, hvis kørselstid overstiger det vindue, der er tilgængeligt for dem.

AI-modeller lærer den statistiske fordeling og relationer mellem produktionsdata at kende og genererer derefter syntetiske poster, der bevarer disse egenskaber uden at eksponere nogen reel kundepost.

Ja, til en vis grad. Modeller tilpasset målte nedbrydningskurver ekstrapolerer fejlpunktet, men fremskrivningen skal bekræftes af en faktisk kørsel, før den danner grundlag for en kapacitetsbeslutning.