Vad är volymtestning? Lär dig med exempel
Redaktionellt team
⚡ Smart sammanfattning
Volymtestning utsätter en applikation för en mycket stor mängd data för att se hur lagring, frågor och svarstider beter sig när databasen växer. Det kallas också översvämningstestning och det skalar data snarare än antalet användare.
Vad är volymtestning?
Volymtestning är en typ av mjukvarutestning, där programvaran utsätts för en enorm mängd data. Det kallas också översvämningstestning. Volymtestning görs för att analysera systemets prestanda genom att öka mängden data i databasen.
Med hjälp av volymtestning kan påverkan på svarstid och systembeteende studeras vid exponering för en stor mängd data.
Till exempel kan en musikstreamingtjänst testas med en katalog på 50 miljoner tracks och en tabell med lyssningshistorik som innehåller miljarder rader, för att se om sök- och rekommendationsfrågor fortfarande returnerar inom acceptabel tid.
Observera skillnaden: volymtestning ökar mängd data systemet håller. Öka antal samtidiga användare är belastningstestning, vilket är ett annat test med ett annat mål.
Fördelar med volymtestning
- Att identifiera kapacitetsproblem tidigt undviker den betydligt högre kostnaden för att åtgärda dem i produktionen
- Det hjälper till en snabbare start för skalbarhetsplaner
- Tidig identifiering av flaskhalsar
- Det försäkrar att ditt system nu kan användas i verkligheten
Varför göra volymtestning?
Syftet med att utföra volymtestningen är att
- Kontrollera systemets prestanda med ökande datavolymer i databasen
- Identifiera de problem som sannolikt kommer att uppstå när datamängden blir stor
- För att ta reda på när systemets stabilitet försämras
- Volymtestning hjälper till att identifiera systemets eller applikationens kapacitet – normal och tung volym
Hur man gör volymtestning
Vid volymtestning måste följande saker testas
- Testa för att kontrollera om det finns någon dataförlust
- Kontrollera systemets svarstid
- Kontrollera om data lagras korrekt eller inte
- Verifiera om data skrivs över utan något meddelande
- Kontrollera att varningar och felmeddelanden faktiskt visas när en volymgräns uppnås
- Kontrollera om högvolymdata påverkar bearbetningshastigheten
- Bekräfta att systemet har tillräckligt med minne och lagringsresurser för volymen.
- Bekräfta att volymtestet täcker hela systemet snarare än en enda komponent
- Finns det någon risk om datavolymen är större än vad som anges
- Fastställ om det finns någon garanti för att datavolymen inte kommer att överstiga det angivna maximumet
Bästa praxis för testning av hög volym
Flera av metoderna nedan delas med belastningstestning, eftersom de två vanligtvis körs mot samma miljö. De volymspecifika metoderna rör själva datamängden:
- Stoppa alla servrar och kontrollera alla loggar
- Innan belastningstestet körs applikationsscenariot manuellt
- För de mest användbara resultaten ska du växla antalet användare
- För att övervinna licensbegränsningar, balansera tänketiden
- Var försiktig med nybygget
- Analysera användningsfallet för förbättring när en baslinje har fastställts
- En upprepning av vissa delar av volymtestning blir oundviklig om det finns en prestandaflaskhals
Volymtestning kontra belastningstestning
| Volymtestning | Lasttestning |
|---|---|
|
|
|
|
Utmaningar i volymtestning
- Fragmentering av minne svår att generera
- Dynamisk generering av nycklar
- Relations Integrity av genererad data
Hur detta test står sig i jämförelse med andra prestationstester
Prestandatestning är en familj av tester som skiljer sig åt i formen av den applicerade belastningen, vilket är anledningen till att de så lätt förväxlas.
| Testtyp | Vad som ökas | Fråga den svarar |
|---|---|---|
| Lasttestning | Samtidiga användare, till den förväntade toppen | Uppfyller den målen under normal trafiktopp? |
| Volymtestning | Data som lagras i databasen | Klarar den sig av att datamängden växer? |
| Stresstestning | Belastning över kapacitet, tills fel uppstår | Var går den sönder, och hur? |
| Spike testning | Ladda, omedelbart och extremt | Överlever den och återhämtar sig från en chock? |
| Uthållighetstestning | Varaktighet, vid normal belastning | Försämras prestandan med tiden? |
| Blötläggningstestning | Varaktighet, tittar på resurser | Finns det minnes- eller handle-läckor? |
| Stabilitetstestning | Varierande förhållanden | Förblir den tillförlitlig även när förhållandena förändras? |
Den skillnad som är viktigast här: Volymtestning skalar data, belastningstestning skalar användarna. En rapport som körs på två sekunder mot tiotusen rader och två minuter mot tio miljoner rader har ett volymproblem, inte ett belastningsproblem, och ingen extra serverkapacitet kommer att åtgärda det.
Hur man genererar testdata för volymtestning
I avsnittet om utmaningar noteras att generering av realistiska data är den svåra delen av volymtestning. Fyra metoder används i praktiken, och var och en innebär en avvägning.
| Tillvägagångssätt | Realism | Huvudsaklig nackdel |
|---|---|---|
| Kopia av produktionsdata | Högsta | Integritets- och efterlevnadsexponering |
| Maskerad produktionskopia | Hög | Maskering kan bryta referensintegriteten |
| Syntetisk generation | Medium | Fördelningar kanske inte stämmer överens med verkligheten |
| Återuppspelad produktionstrafik | Hög | Kräver infrastruktur för insamling |
Oavsett vilken väg du väljer måste tre egenskaper gälla, annars mäter testet ingenting användbart.
- Referensintegritet. Varje främmande nyckel måste lösas. En miljon föräldralösa rader använder lagringsmotorn men aldrig de kopplingsvägar som applikationen faktiskt använder.
- Realistisk kardinalitet. Om produktionstabellen har tio miljoner rader över tvåhundra kunder, kommer generering av tio miljoner rader över tio miljoner kunder att producera helt andra frågeplaner.
- Realistisk fördelning. Verkliga data är snedvridna. Enhetligt slumpmässiga data döljer de heta partitionerna och indexkonflikter som orsakar produktionsincidenter.
En praktisk varning om integritet. Att kopiera produktionsdata till en testmiljö är den vanligaste orsaken till dataintrång vid testning. Maskera personliga fält innan kopian lämnar produktionen, inte efteråt.
