Soak Test i programvara: Betydelse och exempel

Vad är Soak Testing?

Blötläggningstestning är en typ av icke-funktionell testning som används för att mäta prestanda för en mjukvaruapplikation under en enorm belastning under en längre tidsperiod. Målet med Soak-testning är att säkerställa om mjukvaruapplikationen håller hög användningsvolym och att kontrollera vad som skulle hända utanför dess designförväntningar.

Bilden nedan visar en testcykel som visar i vilket skede blötläggningstestningen (Typ av prestandatest) utförs på en applikation.

I denna typ av testning är det som i princip övervakas minnesutnyttjandet av en applikation i ett system. Det testar på systemnivå för att ta reda på om systemet kommer att klara en mycket hög användningsvolym och för att se vad som skulle hända utanför dess designförväntningar.

Varför gör man blötläggningstestning?

Ett system kan bete sig normalt när det används i 2 timmar, men när samma system används kontinuerligt i 10 timmar eller mer än så kan det misslyckas eller bete sig onormalt/slumpmässigt/det kan krascha. För att förutsäga ett sådant misslyckande utförs blötläggningstestning.

När ska man göra blötläggningstestning?

Blötläggningstestning bör göras i följande scenarier: –

1. Innan den byggda distribueras till klienten, dvs innan någon applikation släpps på en specifik plattform, måste den genomgå en framgångsrik serie belastningstester på höga eller likvärdiga trafiknivåer. Därefter blötläggningstestning utförs. Det hjälper oss att avgöra hur man kör en viss applikation under en längre period. Om problem som minnesläckor/minneskorruption upptäcks under perioden, dvs när den är på Soak, bör det omedelbart rapporteras.
2. Den bästa tiden att göra ett blötläggningstest är under helgerna eftersom en applikation måste vara igång så länge som över en dag eller natt. Det beror helt på testsituationens begränsningar. Blötläggningstester är ett av de viktigaste efterlevnadskraven som måste följas mycket strikt av varje företag.

Blötläggningsteststrategi

Long Session Soak Testing är en strategi där ett system är under belastning under en längre tid.

Ett enkelt exempel är där användaren förblir inloggad i ett system i många timmar och utför ett antal affärstransaktioner. På så sätt skapas mycket data. Det kan vara mycket belastning på systemet/databasservern vilket kan resultera i att systemet/databasservern stannar/kraschar.

Under Long Session Soak Testing utförs flera dagars (säg 30 dagar) aktiviteter inom en begränsad tidsram (säg 2 dagar). Antalet transaktioner inom denna begränsade tidsram bör matcha eller överträffa flera dagars transaktioner. Fokus bör ligga på antalet transaktioner som behandlas. Den viktigaste delen av Soak Testing är att kontrollera det tillgängliga minnet i CPU:n och mängden minne som kommer att användas. Vi måste registrera minnesanvändningen i början och slutet av ett blötläggningstest. Om det behövs, då minnesanvändningen av faciliteter som t.ex Java Virtuella maskiner är också viktiga och måste övervakas.

Nedan finns några fler kontroller som behöver göras av alla användare/testare innan de börjar med Soak Testing:

a) Övervaka databasresursförbrukningen.

b) Övervaka serverresursförbrukningen (ex CPU-användning).

c) Blötläggningstestet bör köras med realistisk användarsamverkan.

Egenskaper för blötläggningstestning

En standardmetod för blötläggningstestning bör ha följande egenskaper: –

• Varaktigheten av de flesta Soak Tester bestäms ofta av den tillgängliga tiden.
• Alla program måste köras utan avbrott om de kräver en längre tidsperiod.
• Den bör täcka alla scenarier som intressenterna kommit överens om.
• För det mesta varje system har en regelbunden underhållsperiod och tiden mellan sådana perioder är en nyckelfaktor för att bestämma omfattningen av ett blötläggningstest.

Exempel på blötläggningstestning

• När det gäller bankdomäner när det finns en stor mängd data från handlare, kommer testaren att belasta systemet kontinuerligt i 70 timmar till 150 timmar för att kontrollera hur applikationen beter sig under denna laddningsperiod.
• Anta att det finns 33,000 60 inloggningar som måste föras genom systemet, det representerar sju och en halv dag av aktivitet. I det här fallet kan ett 70-6 timmars blötläggningstest påbörjas senast fredag ​​kväll runt kl. XNUMX som kan slutföras av Monday morgon klockan 6. Endast med ett sådant test kommer det att vara möjligt att observera eventuell försämring av prestanda under kontrollerade förhållanden.
• När det gäller videospel, Mobil applikationer etc. innebär att spelet eller applikationen ska vara igång under en längre tidsperiod, i olika driftlägen - såsom tomgång, paus på titelskärmen och så vidare för att ta reda på om en applikation kan hantera den kontinuerligt förväntade belastningen .

Vanliga problem som observerats under blötläggningstestning

1. Minnesallokering (minnesläckor som så småningom skulle resultera i en minneskris eller avrundningsfel som bara visar sig över tiden).
2. Databasresursutnyttjande (misslyckande med att stänga databasmarkörer under vissa förhållanden som så småningom skulle resultera i att hela systemet stannar).
3. Det kan också leda till prestationsförsämring, dvs att säkerställa att svarstiden efter en lång period av ihållande aktivitet är lika bra som den var i början av testet.
4. Misslyckande med att stänga anslutningar mellan nivåer i ett system med flera nivåer under vissa omständigheter, vilket kan stoppa några eller alla moduler i systemet.
5. Den gradvisa försämringen av en svarstid för vissa funktioner eftersom interna datastrukturer blir mindre effektiva under ett långt test.

Hur detta test passar in i prestationstestfamiljen

Prestandatestning är ett paraplybegrepp. Varianterna nedan skiljer sig endast åt i formen av den applicerade belastningen och hur länge den hålls, vilket är anledningen till att de så ofta förväxlas med varandra.

Uthållighets- och blötläggningstestning behandlas ofta som synonymer. Vanligtvis används de som: båda håller en ihållande belastning under en lång period. Där team skiljer dem åt fokuserar uthållighetstestning på om svarstiderna glider uppåt, medan soak-testning fokuserar på resursförbrukning som minne, filreferenser och anslutningspooler. Att köra en ger dig vanligtvis bevis för båda.

Viktiga mätvärden att fånga upp under testet

En prestandakörning är bara så bra som vad du spelar in medan den körs. Registrera dessa sex på server- och klientsidan och jämför dem sedan mot baslinjen snarare än mot en magkänsla.

Läs av medelvärdet och percentilen tillsammans. Ett genomsnitt på 800 ms med en 95:e percentil på 900 ms beskriver ett konsekvent system. Samma genomsnitt med en 95:e percentil på 9 sekunder innebär att en användare av tjugo har det dåligt, och genomsnittet döljer det.

Titta på formen, inte bara på värdet. I alla långvariga tester är en platt resurslinje ett godkänt resultat och en stigande är en läcka, även om det absoluta antalet fortfarande ligger bekvämt inom gränsen när körningen avslutas.

Vanliga frågor