Soaktest in software: betekenis en voorbeelden
Redactie
⚡ Slimme samenvatting
Bij een 'soak test' wordt een applicatie gedurende een langere periode aan een realistische belasting blootgesteld om problemen aan het licht te brengen die pas na verloop van tijd aan het licht komen. Geheugenlekken, overbelasting van verbindingen en een trage prestatiedaling zijn de defecten die met deze test worden opgespoord.
Wat is Soak Testing?
Soak-testen is een vorm van niet-functioneel testen dat wordt gebruikt om de prestaties van een softwareapplicatie gedurende een langere periode onder een enorme belasting te meten. Het doel van Soak-testen is om ervoor te zorgen dat de softwareapplicatie een hoog gebruiksvolume aankan en om te controleren wat er buiten de ontwerpverwachtingen zou gebeuren.
De onderstaande afbeelding toont een testcyclus die laat zien in welk stadium de Soak Testing (Type prestatietest) wordt uitgevoerd op een toepassing.
Bij dit soort testen wordt in principe het geheugengebruik door een applicatie in een systeem gecontroleerd. Er wordt getest op systeemniveau, om na te gaan of het systeem bestand is tegen een zeer hoog gebruiksvolume en om te zien wat er zou gebeuren buiten de ontwerpverwachtingen.
Waarom een Soak-test doen?
Een systeem kan zich normaal gedragen als het 2 uur wordt gebruikt, maar als hetzelfde systeem 10 uur of langer continu wordt gebruikt, kan het falen of abnormaal/willekeurig/crashend gedrag vertonen. Om een dergelijk falen te voorspellen, wordt Soak Testing uitgevoerd.
Wanneer moet u een Soak-test uitvoeren?
Soak-testen moeten worden uitgevoerd in de volgende scenario's: –
- Voordat de build wordt geïmplementeerd op de client, dat wil zeggen vóór de release van een applicatie op een specifiek platform, moet deze een succesvolle reeks belastingstests ondergaan op hoge of gelijkwaardige verkeersniveaus. Daarna Er wordt een weektest uitgevoerd. Het helpt ons te bepalen hoe we een bepaalde applicatie voor een langere periode kunnen gebruiken. Als er problemen zoals geheugenlekken/geheugenbeschadiging worden aangetroffen tijdens de periode, dat wil zeggen wanneer de Soak actief is, dan moet dit onmiddellijk worden gemeld.
- De beste tijd om een soak-test uit te voeren is in het weekend, omdat een applicatie wel een dag of nacht actief moet zijn. Het hangt volledig af van de beperkingen van de testsituatie. Soaktests zijn een van de belangrijkste compliance-eisen die door elk bedrijf zeer strikt moeten worden nageleefd.
Soak-teststrategie
Long Session Soak Testing is een strategie waarbij een systeem langere tijd onder belasting staat.
Een eenvoudig voorbeeld is wanneer de gebruiker vele uren ingelogd blijft op een systeem om een aantal zakelijke transacties uit te voeren. Op deze manier worden er veel gegevens gecreëerd. Er kan veel belasting zijn op het systeem/de databaseserver, wat kan resulteren in vastlopen/crashen van het systeem/de databaseserver.
Bij Long Session Soak Testing worden activiteiten van meerdere dagen (bijvoorbeeld 30 dagen) uitgevoerd in een beperkt tijdsbestek (bijvoorbeeld 2 dagen). Het aantal transacties in dit beperkte tijdsbestek moet de hoeveelheid transacties van meerdere dagen evenaren of overtreffen. De nadruk moet liggen op het aantal verwerkte transacties. Het belangrijkste onderdeel van Soak Testing is het controleren van het beschikbare geheugen in de CPU en de hoeveelheid geheugen die in gebruik zal zijn. We moeten het geheugengebruik aan het begin en het einde van een soak-test registreren. Indien nodig wordt het geheugengebruik van faciliteiten zoals Java Virtuele machines zijn ook belangrijk en moeten worden gemonitord.
Hieronder staan nog enkele controles die elke gebruiker/tester moet uitvoeren voordat hij of zij met Soak Testing begint:
a) Bewaak het verbruik van databasebronnen.
b) Controleer het verbruik van serverbronnen (ex. CPU-gebruik).
c) De Soak-test moet worden uitgevoerd met realistische gelijktijdigheid van gebruikers.
Kenmerken van Soak-testen
Een standaard Soak-testmethode moet de volgende kenmerken hebben: –
- De duur van de meeste Soak Tests wordt vaak bepaald door de beschikbare tijd.
- Elke applicatie moet zonder enige onderbreking draaien als deze een langere periode nodig heeft.
- Het moet alle scenario's omvatten waarover de belanghebbenden het eens zijn.
- Bijna elk systeem heeft een reguliere onderhoudsperiode en de tijd tussen deze periodes is een belangrijke factor bij het bepalen van de reikwijdte van een Soak Test.
Voorbeelden van weektesten
- In het geval van een bankdomein waarbij er een grote hoeveelheid gegevens van verkopers is, zal de tester het systeem gedurende 70 tot 150 uur continu belasten om te controleren hoe de applicatie zich tijdens deze laadperiode gedraagt.
- Stel dat er 33,000 logins zijn, die door het systeem moeten worden gehaald, dan vertegenwoordigt dat zeven en een halve dag aan activiteit. In dit geval kan er vrijdagavond rond 60:70 uur een Soak Test van 6-XNUMX uur worden gestart, die kan worden afgerond door Monday ochtend om 6 uur. Alleen met een dergelijke test zal het mogelijk zijn om eventuele verslechtering van de prestaties onder gecontroleerde omstandigheden waar te nemen.
- In het geval van videogames Mobile Bij het uitvoeren van dergelijke taken wordt het spel of de toepassing gedurende een langere periode in verschillende bedrijfsmodi gelaten, zoals inactief, gepauzeerd bij het titelscherm, enzovoort, om te bepalen of een toepassing de verwachte continue belasting aankan.
Veelvoorkomende problemen waargenomen tijdens Soak Tests
- Geheugentoewijzing (geheugenlekken die uiteindelijk zouden resulteren in een geheugencrisis of afrondingsfouten die zich pas in de loop van de tijd manifesteren).
- Gebruik van databasebronnen (het onvermogen om databasecursors onder bepaalde omstandigheden te sluiten, wat er uiteindelijk toe zou leiden dat het hele systeem vastloopt).
- Het kan ook leiden tot prestatievermindering, dat wil zeggen om ervoor te zorgen dat de responstijd na een lange periode van aanhoudende activiteit net zo goed is als aan het begin van de test.
- Het niet sluiten van verbindingen tussen lagen van een systeem met meerdere lagen onder bepaalde omstandigheden, waardoor sommige of alle modules van het systeem zouden kunnen vastlopen.
- De geleidelijke verslechtering van de responstijd van sommige functies, omdat interne datastructuren tijdens een lange test minder efficiënt worden.
Hoe deze test past binnen de familie van prestatietests.
Prestatietesten is een overkoepelende term. De onderstaande varianten verschillen alleen in de vorm van de toegepaste belasting en de duur ervan, waardoor ze vaak met elkaar worden verward.
| Testtype | Belastingspatroon | Vraag het beantwoordt |
|---|---|---|
| Load testen | Verwachte piekbelasting, korte duur | Voldoet het systeem aan de doelstellingen bij normale piekbelasting? |
| Stress testen | Verhoogd tot boven de capaciteit tot het faalt | Waar gaat het mis, en verloopt het falen op een elegante manier? |
| Spike-testen | Plotselinge, extreme stijging, gevolgd door terugtrekking. | Kan het een verkeersschok overleven en ervan herstellen? |
| Uithoudingsvermogen testen | Normale belasting gedurende vele uren aangehouden | Neemt de prestatie in de loop der tijd af? |
| Soak testen | Langdurige belasting gedurende een langere periode | Zijn er geheugenlekken of is er sprake van uitputting van de systeembronnen? |
| Stabiliteitstesten | Variërende belasting onder verschillende omstandigheden | Blijft het systeem betrouwbaar bij veranderende omstandigheden? |
| Volume testen | Normale gebruikers, zeer grote hoeveelheden data | Kan het de groei van de database aan? |
Duurzaamheidstesten en weektesten worden vaak als synoniemen beschouwd. In de volksmond worden ze als volgt omschreven: beide tests houden een constante belasting gedurende een lange periode vol. Waar teams wel onderscheid maken tussen beide, richt duurtesten zich op de vraag of de responstijden toenemen, terwijl duurtesten zich richten op het resourceverbruik, zoals geheugen, bestandsdescriptors en verbindingspools. Het uitvoeren van één test levert meestal bewijs voor beide.
Belangrijke meetwaarden om vast te leggen tijdens de test
Een prestatietest is slechts zo goed als wat je vastlegt tijdens de uitvoering. Leg deze zes gegevens vast, zowel aan de server- als aan de clientzijde, en vergelijk ze vervolgens met de basislijn in plaats van af te gaan op je onderbuikgevoel.
| metrisch | Wat het je vertelt | Waarschuwingsbord |
|---|---|---|
| Gemiddelde reactietijd | Typische gebruikerservaring | Elke opwaartse afwijking gedurende de run |
| 95e percentiel reactietijd | De ervaring van de traagste gebruikers | Ver boven het gemiddelde, wat duidt op inconsistentie. |
| Doorvoer | Verzoeken verwerkt per seconde | Dalend terwijl de belasting constant blijft |
| Foutpercentage | Aandeel van mislukte of verlopen aanvragen | Elke stijging boven de overeengekomen drempelwaarde |
| CPU- en geheugengebruik | Servercapaciteit | Een herinnering die opstijgt en nooit meer terugkeert. |
| Databaseverbindingen en threads | zwembaduitputting | Aantallen die gestaag groeien zonder vrijgave |
Lees het gemiddelde en het percentiel samen. Een gemiddelde van 800 ms met een 95e percentiel van 900 ms beschrijft een consistent systeem. Datzelfde gemiddelde met een 95e percentiel van 9 seconden betekent dat één op de twintig gebruikers een slechte ervaring heeft, en dat het gemiddelde dit verbergt.
Let op de vorm, niet alleen op de waarde. Bij elke langdurige test is een vlakke lijn voor de resources een teken van voldoende resultaat en een stijgende lijn een teken van een overschrijding, zelfs als het absolute aantal op het moment dat de test eindigt nog ruim binnen de limiet ligt.
