Blötprovning
Soak Testing är en typ av icke-funktionell testning som används för att mäta prestanda för en programvara under en enorm belastningsvolym under en längre tid. Målet med Soak-testning är att säkerställa om programvaran upprätthå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 Soak Testing ( Type of Performance Test ) utförs på en applikation.
I denna typ av testning är det som i princip övervakas minnesanvändningen av en applikation i ett system. Det testas på systemnivå för att ta reda på om systemet klarar en mycket hög användningsvolym och se vad som skulle hända utanför dess designförväntningar.
I den här handledningen lär du dig-
- Varför Soak Testing?
- När ska jag testa blöt?
- Blöt teststrategi
- Kännetecken för blötprovning
- EXEMPEL på blötprovning
- Vanliga problem som observerats under blötläggningstestning
Varför Soak Testing?
Ett system kan fungera 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 beter sig onormalt / slumpmässigt / det kan krascha. För att förutsäga ett sådant misslyckande utförs Blötestning.
När ska jag testa blöt?
Blötprovning bör göras i följande scenarier: -
- Innan den byggda distribueras till klienten, dvs. innan en applikation släpps på en specifik plattform, måste den genomgå en framgångsrik serie belastningstester vid höga eller likvärdiga trafiknivåer. Efter det utförs blötprovning . Det hjälper oss att avgöra hur vi ska köra en viss applikation under en längre period. Om problem som minnesläckage / minneskorruption upptäcks under perioden, dvs när det är i blötläggning, bör det rapporteras omedelbart.
- Den bästa tiden att göra en blötprovning är över 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ötprov är ett av de viktigaste kraven för efterlevnad som måste följas mycket strikt av varje företag.
Blöt teststrategi
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å det här sättet skapas mycket data. Det kan vara mycket belastning på systemet / databasservern vilket kan leda till att systemet / databasservern stannar / kraschar.
Under Long Session Soak Testing utförs flera dagars (säg 30 dagar) aktiviteter i 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 vara på antalet behandlade transaktioner. Den viktigaste delen av Soak Testing är att kontrollera tillgängligt minne i CPU: n och hur mycket minne som kommer att användas. Vi måste registrera minnesanvändningen i början och slutet av ett blötprov. Vid behov är minnesanvändningen av anläggningar som Java Virtual Machines också viktig och måste övervakas.
Nedan följer några fler kontroller som behöver göras av någon användare / testare innan de börjar med Blötestning:
a) Övervaka databasresursförbrukningen.
b) Övervaka serverresursförbrukningen (ex-CPU-användning).
c) Blötprov ska köras med realistisk användar samtidighet.
Kännetecken för blötprovning
En standardmetod för blötprovning bör ha följande egenskaper: -
- Varaktigheten för de flesta Soak Test bestäms ofta av den tillgängliga tiden.
- Varje ansökan måste köras utan avbrott om det kräver en längre tid.
- Den ska täcka alla scenarier som överenskommits av intressenterna.
- För det mesta har varje system en regelbunden tidsperiod för underhållsfönster och tiden mellan sådana fönsterperioder är en viktig drivkraft för att bestämma omfattningen av ett Soak Test.
EXEMPEL på blötprovning
- När det gäller bankdomän när det finns en stor mängd data från säljare kommer testaren att sätta systemet under belastning kontinuerligt under 70 till 150 timmar för att kontrollera hur applikationen beter sig under denna laddningsperiod.
- Antag att det finns 33 000 inloggningar som måste göras genom systemet, det representerar sju och en halv dagars aktivitet. I det här fallet kan ett 60-70 timmars Soak Test startas på fredagskvällen runt 18.00, vilket kan slutföras på måndag morgon klockan 6. Endast med ett sådant test är det möjligt att observera all försämring av prestanda under kontrollerade förhållanden.
- När det gäller videospel innebär mobilapplikationer etc. att lämna spelet eller applikationen i ett körande tillstånd under en längre tidsperiod, i olika driftsätt - såsom tomgång, pausad vid titelskärmen och så vidare för att ta reda på en applikation kan hantera den kontinuerligt förväntade belastningen.
Vanliga problem som observerats under blötläggningstestning
- Minnesallokering (minnesläckor som så småningom skulle leda till en minneskris eller avrundningsfel som bara manifesteras över tid).
- Databasresursanvändning (misslyckande med att stänga databasmarkörer under vissa förhållanden som så småningom skulle resultera i att hela systemet stannar).
- Det kan också leda till försämrad prestanda, dvs för 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.
- Det går inte att stänga förbindelserna mellan nivåerna i ett system med flera nivåer under vissa omständigheter som kan stoppa vissa eller alla moduler i systemet.
- Den gradvisa nedbrytningen av svarstiden för vissa funktioner som interna datastrukturer blir mindre effektiva under ett långt test.
Sammanfattning
- I mjukvaruteknik görs blötprovning för att avgöra om applikationen som testas kan hålla den kontinuerliga belastningen.
- Det är en typ av prestandatest.
- Det hjälper systemet att avgöra om det klarar en mycket hög användningsvolym
- I denna typ av testning är det som i princip övervakas minnesanvändningen av en applikation i ett system
- Kontroller som måste göras av någon användare / testare innan de börjar med Soak Testing inkluderar
- Övervaka databasresursförbrukningen.
- Övervaka serverresursförbrukningen (ex-CPU-användning).
- Soak-testet bör köras med realistisk användar samtidighet.
Denna artikel har bidragit av Pallavi De