Hva er volumtesting? Lær med eksempler
Thomas Hamilton
⚡ Smart oppsummering
Volumtesting utsetter en applikasjon for en veldig stor mengde data for å se hvordan lagring, spørringer og responstider oppfører seg etter hvert som databasen vokser. Det kalles også flomtesting, og det skalerer dataene i stedet for antall brukere.
Hva er volumtesting?
Volumtesting er en type programvaretesting, hvor programvaren blir utsatt for et stort datavolum. Det er også referert til som flomtesting. Volumtesting gjøres for å analysere systemytelsen ved å øke volumet av data i databasen.
Ved hjelp av volumtesting kan innvirkningen på responstid og systematferd studeres når de utsettes for store datamengder.
For eksempel kan en musikkstrømmetjeneste testes med en katalog på 50 millioner tracks og en lyttehistorikktabell som inneholder milliarder av rader, for å se om søke- og anbefalingsspørsmål fortsatt returneres innen akseptabel tid.
Legg merke til forskjellen: volumtesting øker datamengde systemet holder. Øker antall samtidige brukere er belastningstesting, som er en annen test med et annet mål.
Fordeler med volumtesting
- Å identifisere kapasitetsproblemer tidlig unngår de langt høyere kostnadene ved å fikse dem i produksjonen
- Det hjelper med en raskere start for skalerbarhetsplaner
- Tidlig identifisering av flaskehalser
- Det sikrer at systemet ditt nå er i stand til bruk i den virkelige verden
Hvorfor utføre volumtesting?
Målet med å utføre volumtestingen er å
- Sjekk systemytelsen med økende datamengder i databasen
- Identifiser problemene som sannsynligvis vil oppstå når datasettet blir stort
- For å finne ut punktet hvor stabiliteten til systemet forringes
- Volumtesting vil bidra til å identifisere kapasiteten til systemet eller applikasjonen – normalt og tungt volum
Slik utfører du volumtesting
I volumtesting må følgende ting testes
- Test for å sjekke om det er tap av data
- Sjekk systemets responstid
- Sjekk om dataene er lagret riktig eller ikke
- Bekreft om dataene er overskrevet uten varsel
- Sjekk at advarsler og feilmeldinger faktisk vises når en volumgrense er nådd
- Sjekk om data med høyt volum påvirker behandlingshastigheten
- Bekreft at systemet har minne- og lagringsressursene som volumet krever
- Bekreft at volumtesten dekker hele systemet i stedet for én enkelt komponent
- Er det noen risiko hvis datavolumet er større enn spesifisert
- Undersøk om det finnes noen garanti for at datamengden ikke vil overstige den angitte maksimale
Beste praksis for testing av store mengder
Flere av fremgangsmåtene nedenfor deles med belastningstesting, fordi de to vanligvis kjøres mot samme miljø. De volumspesifikke gjelder selve datasettet:
- Stopp alle servere og sjekk alle logger
- Før belastningstesten utfør applikasjonsscenarioet manuelt
- For de mest nyttige resultatene forskyv antall brukere
- For å overvinne lisensbegrensninger, balanser tenketid
- Vær forsiktig med det nye bygget
- Analyser brukssaken for forbedring når en baseline er etablert
- En repetisjon av bestemte deler av volumtesting blir uunngåelig i tilfelle det er en flaskehals i ytelsen
Volumtesting kontra belastningstesting
| Volumtesting | Load Testing |
|---|---|
|
|
|
|
Utfordringer i volumtesting
- Fragmentering av minne vanskelig å generere
- Dynamisk generering av nøkler
- Relasjonelt Integrity av genererte data
Hvordan denne testen sammenlignes med andre ytelsestester
Ytelsestesting er en familie av tester som varierer i formen på den påførte belastningen, og det er derfor de så lett forveksles.
| Testtype | Hva er økt | Spørsmål den svarer |
|---|---|---|
| Lasttesting | Samtidige brukere, til forventet topp | Oppfyller den målene under normal rushtrafikk? |
| Volumtesting | Data lagret i databasen | Takler den det når datasettet vokser? |
| Stresstesting | Last utover kapasitet, inntil feil | Hvor går den i stykker, og hvordan? |
| Piggtesting | Last inn, umiddelbart og ekstremt | Overlever den og kommer den seg etter et sjokk? |
| Utholdenhetstesting | Varighet, ved normal belastning | Forringes ytelsen over tid? |
| Bløtleggingstesting | Varighet, overvåkingsressurser | Er det minne- eller håndtakslekkasjer? |
| Stabilitetstesting | Varierende forhold | Forblir den pålitelig når forholdene endrer seg? |
Det viktigste skillet her: Volumtesting skalerer dataene, belastningstesting skalerer brukerne. En rapport som kjører på to sekunder mot ti tusen rader og to minutter mot ti millioner rader har et volumproblem, ikke et belastningsproblem, og ingen mengde ekstra serverkapasitet vil fikse det.
Slik genererer du testdata for volumtesting
Utfordringsdelen bemerker at det å generere realistiske data er den vanskelige delen av volumtesting. Fire tilnærminger brukes i praksis, og hver innebærer en avveining.
| Tilnærming | Realisme | Hovedulempen |
|---|---|---|
| Kopi av produksjonsdata | Høyeste | Personvern og samsvarseksponering |
| Maskert produksjonskopi | Høyt | Maskering kan ødelegge referanseintegriteten |
| Syntetisk generering | Medium | Fordelingene stemmer kanskje ikke overens med virkeligheten |
| Avspilt produksjonstrafikk | Høyt | Krever infrastruktur for fangst |
Uansett hvilken vei du velger, må tre egenskaper holde, ellers måler testen ingenting nyttig.
- Referanseintegritet. Hver fremmednøkkel må løses. En million foreldreløse rader bruker lagringsmotoren, men aldri koblingsstiene applikasjonen faktisk bruker.
- Realistisk kardinalitet. Hvis produksjonstabellen har ti millioner rader på tvers av to hundre kunder, vil generering av ti millioner rader på tvers av ti millioner kunder produsere helt andre spørreplaner.
- Realistisk fordeling. Reelle data er skjeve. Ensartet tilfeldige data skjuler de aktive partisjonene og indekskonflikten som forårsaker produksjonshendelser.
En praktisk advarsel om personvern. Kopiering av produksjonsdata til et testmiljø er den vanligste årsaken til datainnbrudd i testing. Masker personlige felt før kopien forlater produksjonen, ikke etterpå.
