Wat is volumetesten? Leer met voorbeelden
Thomas Hamilton
⚡ Slimme samenvatting
Volumetesten stellen een applicatie bloot aan een zeer grote hoeveelheid data om te zien hoe de opslag, query's en responstijden zich gedragen naarmate de database groeit. Het wordt ook wel floodtesten genoemd en schaalt de data in plaats van het aantal gebruikers.
Wat is volumetesten?
Volume testen is een vorm van softwaretesten, waarbij de software wordt onderworpen aan een enorme hoeveelheid gegevens. Het wordt ook wel genoemd overstroming testen. Volumetests worden uitgevoerd om de systeemprestaties te analyseren door het gegevensvolume in de database te vergroten.
Met behulp van volumetesten kan de impact op de responstijd en het systeemgedrag worden bestudeerd bij blootstelling aan een grote hoeveelheid gegevens.
Een muziekstreamingdienst zou bijvoorbeeld getest kunnen worden met een catalogus van 50 miljoen nummers. tracks en een tabel met luistergeschiedenis die miljarden rijen bevat, om te zien of zoek- en aanbevelingsvragen nog steeds binnen een acceptabele tijd resultaat opleveren.
Let op het onderscheid: volumetesten verhogen de hoeveelheid gegevens het systeem houdt stand. Het verhogen van de aantal gelijktijdige gebruikers Een belastingstest is een andere test met een ander doel.
Voordelen van volumetesten
- Door capaciteitsproblemen vroegtijdig te signaleren, worden de veel hogere kosten vermeden die gepaard gaan met het oplossen ervan tijdens de productie.
- Het helpt bij een snellere start van schaalbaarheidsplannen
- Vroegtijdige identificatie van knelpunten
- Het zorgt ervoor dat uw systeem nu geschikt is voor gebruik in de echte wereld
Waarom volumeberekeningen uitvoeren?
Het doel van het uitvoeren van de volumetesten is om
- Controleer de systeemprestaties bij toenemende gegevensvolumes in de database
- Identificeer de problemen die zich waarschijnlijk zullen voordoen zodra de dataset groot wordt.
- Om erachter te komen op welk punt de stabiliteit van het systeem afneemt
- Volumetests helpen bij het identificeren van de capaciteit van het systeem of de applicatie – normaal en zwaar volume
Hoe voer je volumetesten uit?
Bij volumetesten moeten de volgende zaken worden getest
- Test om te controleren of er gegevensverlies is
- Controleer de responstijd van het systeem
- Controleer of de gegevens correct zijn opgeslagen of niet
- Controleer of de gegevens zonder enige kennisgeving worden overschreven
- Controleer of er daadwerkelijk waarschuwingen en foutmeldingen verschijnen wanneer een volumelimiet is bereikt.
- Controleer of grote hoeveelheden gegevens de verwerkingssnelheid beïnvloeden
- Controleer of het systeem over voldoende geheugen en opslagcapaciteit beschikt voor het volume.
- Controleer of de volumetest het hele systeem omvat en niet slechts één component.
- Bestaat er een risico als het datavolume groter is dan gespecificeerd?
- Ga na of er een garantie bestaat dat het datavolume het opgegeven maximum niet zal overschrijden.
Beste werkwijzen voor testen met een hoog volume
Een aantal van de onderstaande werkwijzen komen overeen met die van belastingstesten, omdat beide doorgaans in dezelfde omgeving worden uitgevoerd. De werkwijzen die specifiek betrekking hebben op het volume, betreffen de dataset zelf:
- Stop alle servers en controleer alle logs
- Voer vóór de belastingstest het toepassingsscenario handmatig uit
- Voor de meest bruikbare resultaten spreidt u het aantal gebruikers
- Om licentiebeperkingen te overwinnen, moet u de denktijd in evenwicht brengen
- Wees voorzichtig met de nieuwbouw
- Analyseer de use case voor verbetering zodra er een basislijn is vastgesteld
- Een herhaling van bepaalde delen van volumetests wordt onvermijdelijk als er een prestatieknelpunt is
Volumetesten versus belastingstesten
| Volume testen | load Testen |
|---|---|
|
|
|
|
Uitdagingen bij volumetesten
- Fragmentatie van het geheugen is moeilijk te genereren
- Dynamische generatie van sleutels
- relationele Integrity van gegenereerde data
Hoe deze test zich verhoudt tot andere prestatietests
Prestatietesten vormen een verzameling testen die verschillen in de aard van de toegepaste belasting, waardoor ze zo gemakkelijk met elkaar verward kunnen worden.
| Testtype | Wat wordt verhoogd? | Vraag het beantwoordt |
|---|---|---|
| Load testen | Gelijktijdige gebruikers, tot het verwachte piekniveau | Voldoet het aan de doelstellingen bij normale piekbelasting? |
| Volume testen | Gegevens opgeslagen in de database | Kan het systeem de groei van de dataset aan? |
| Stress testen | Overbelasting tot het maximale vermogen, tot het bezwijkt. | Waar gaat het kapot, en hoe? |
| Spike-testen | Laad direct en extreem snel | Overleeft het een schok en herstelt het ervan? |
| Uithoudingsvermogen testen | Duur, bij normale belasting | Neemt de prestatie in de loop der tijd af? |
| Soak testen | Duur, kijkbronnen | Zijn er geheugen- of handle-lekken? |
| Stabiliteitstesten | Wisselende omstandigheden | Blijft het betrouwbaar als de omstandigheden veranderen? |
Het belangrijkste onderscheid hier is: Volumetesten schalen de data, belastingstesten schalen het aantal gebruikers. Een rapport dat in twee seconden wordt verwerkt met tienduizend rijen en in twee minuten met tien miljoen rijen, heeft een probleem met het volume, niet met de belasting, en geen enkele hoeveelheid extra servercapaciteit zal dit oplossen.
Hoe genereer je testgegevens voor volumetesten?
In het gedeelte over uitdagingen wordt opgemerkt dat het genereren van realistische gegevens het moeilijkste onderdeel is van volumetesten. In de praktijk worden vier benaderingen gebruikt, waarbij elke benadering een afweging met zich meebrengt.
| Aanpak | Realisme | Belangrijkste nadeel |
|---|---|---|
| Kopie van productiegegevens | Hoogst | Blootstelling aan privacy en naleving |
| Gemaskerd productie-exemplaar | Hoge | Maskering kan de referentiële integriteit aantasten. |
| Synthetische generatie | Medium | De verdeling komt mogelijk niet overeen met de werkelijkheid. |
| Opnieuw afgespeeld productieverkeer | Hoge | Vereist opname-infrastructuur |
Welke route je ook kiest, er moeten drie eigenschappen gelden, anders meet de test niets nuttigs.
- Referentiële integriteit. Elke externe sleutel moet worden opgelost. Een miljoen ongebruikte rijen belasten de opslagengine, maar nooit de koppelingspaden die de applicatie daadwerkelijk gebruikt.
- Realistische cardinaliteit. Als de productietabel tien miljoen rijen bevat, verdeeld over tweehonderd klanten, dan levert het genereren van tien miljoen rijen, verdeeld over tien miljoen klanten, compleet andere queryplannen op.
- Realistische verdeling. Echte data is scheef verdeeld. Uniform willekeurig verdeelde data verbergt de overbelaste partities en indexconflicten die productieproblemen veroorzaken.
Een praktische waarschuwing over privacy. Het kopiëren van productiedata naar een testomgeving is de meest voorkomende oorzaak van een datalek tijdens het testen. Maskeer persoonlijke velden vóórdat de kopie de productieomgeving verlaat, niet erna.
