Soak Test i software: Betydning og eksempler

Hvad er soak-testning?

Soak test er en type ikke-funktionel test, der bruges til at måle ydeevnen af ​​en softwareapplikation under en enorm mængde belastning i en længere periode. Målet med Soak-testen er at sikre, om softwareapplikationen opretholder en høj mængde brug og at kontrollere, hvad der ville ske uden for designforventningerne.

Billedet nedenfor viser en testcyklus, der viser, på hvilket stadium iblødsætningstestningen (Type præstationstest) udføres på en applikation.

I denne type test er det, der grundlæggende overvåges, hukommelsesudnyttelsen af ​​en applikation i et system. Det tester på systemniveau for at finde ud af, om systemet kan klare en meget høj brugsmængde, og for at se, hvad der ville ske uden for dets designforventninger.

Hvorfor laver Soak Test?

Et system kan opføre sig normalt, når det bruges i 2 timer, men når det samme system bruges uafbrudt i 10 timer eller mere end det, kan det fejle eller opføre sig unormalt/tilfældigt/det kan gå ned. For at forudsige en sådan fejl udføres Soak Testing.

Hvornår skal man lave soak test?

Iblødsætningstest bør udføres i følgende scenarier: –

1. Før det byggede implementeres til klienten, dvs. før udgivelsen af ​​en applikation på en specifik platform, skal den gennemgå en vellykket serie af belastningstests ved høje eller tilsvarende trafikniveauer. Efter det soak test udføres. Det hjælper os med at bestemme, hvordan vi skal køre en bestemt applikation i en længere periode. Hvis der findes problemer som hukommelseslækager/hukommelseskorruption i den periode, dvs. når den er på Soak, skal det straks rapporteres.
2. Det bedste tidspunkt at lave en iblødsætningstest er i weekenden, da en applikation skal være i kørende så længe som over en dag eller nat. Det afhænger helt af testsituationens begrænsninger. Soak-tests er et af de vigtigste overensstemmelseskrav, som skal følges meget nøje af enhver virksomhed.

Soak teststrategi

Long Session Soak Testing er en strategi, hvor et system er under belastning i længere tid.

Et simpelt eksempel er, hvor brugeren forbliver logget på et system i mange timer og udfører en række forretningstransaktioner. På denne måde bliver der skabt en masse data. Der kan være meget belastning på systemet/databaseserveren, hvilket kan resultere i at systemet/databaseserveren går i stå/kraser.

Under Long Session Soak Testing udføres flere dages (f.eks. 30 dage) aktiviteter i en begrænset tidsramme (f.eks. 2 dage). Antallet af transaktioner i denne begrænsede tidsramme bør matche eller overstige flere dages transaktioner. Fokus bør være på antallet af behandlede transaktioner. Den vigtigste del af Soak Testing er at kontrollere den tilgængelige hukommelse i CPU'en og mængden af ​​hukommelse, der vil være i brug. Vi skal registrere hukommelsesforbruget ved starten og slutningen af ​​en iblødsætningstest. Hvis det er nødvendigt, så hukommelsesbrugen af ​​faciliteter som f.eks Java Virtuelle maskiner er også vigtige og skal overvåges.

Nedenfor er nogle flere kontroller, der skal udføres af enhver bruger/tester, før de begynder med Soak Testing:

a) Overvåg databaseressourceforbruget.

b) Overvåg serverressourceforbruget (ex CPU-brug).

c) Soak-testen skal køre med realistisk brugersamtidighed.

Karakteristika for Soak Testing

En standard iblødsætningstestmetode skal have følgende egenskaber: –

• Varigheden af ​​de fleste Soak Test bestemmes ofte af den tid, der er til rådighed.
• Enhver applikation skal køre uden nogen afbrydelse, hvis den kræver en længere periode.
• Den bør dække alle de scenarier, som interessenterne er enige om.
• For det meste ethvert system har en regelmæssig vedligeholdelsesperiode, og tiden mellem sådanne vinduesperioder er en nøglefaktor for at bestemme omfanget af en Soak Test.

Eksempler på soak-testning

• I tilfælde af bankdomæne, hvor der er en stor mængde data fra handlende, vil testeren sætte systemet under belastning kontinuerligt i 70 timer til 150 timer for at kontrollere, hvordan applikationen opfører sig i denne indlæsningsperiode.
• Antag, at der er 33,000 logins, som skal føres gennem systemet, det repræsenterer syv en halv dags aktivitet. I dette tilfælde kan en 60-70 timers Soak Test startes fredag ​​aften omkring kl. 6, som kan afsluttes pr. Monday morgen klokken 6. Kun med en sådan test vil det være muligt at observere enhver forringelse af ydeevnen under de kontrollerede forhold.
• I tilfælde af videospil, Mobil applikationer osv. involverer at lade spillet eller applikationen køre i en længere periode, i forskellige driftstilstande - såsom tomgang, pause på titelskærmen og så videre for at finde ud af, om en applikation kan håndtere den løbende forventede belastning .

Almindelige problemer observeret under Soak Testing

1. Hukommelsesallokering (hukommelseslækager, der i sidste ende ville resultere i en hukommelseskrise eller afrundingsfejl, der kun viser sig over tid).
2. Databaseressourceudnyttelse (manglende lukning af databasemarkører under nogle forhold, hvilket i sidste ende ville resultere i, at hele systemet går i stå).
3. Det kan også føre til præstationsforringelse, dvs. at sikre, at responstiden efter en lang periode med vedvarende aktivitet er lige så god, som den var i begyndelsen af ​​testen.
4. Undladelse af at lukke forbindelser mellem niveauer i et system med flere niveauer under nogle omstændigheder, hvilket kan stoppe nogle eller alle moduler i systemet.
5. Den gradvise forringelse af en responstid for nogle funktioner, efterhånden som interne datastrukturer bliver mindre effektive under en lang test.

Hvordan denne test passer til præstationstestfamilien

Ydelsestest er en paraplybetegnelse. Varianterne nedenfor adskiller sig kun i formen af ​​den påførte belastning og den varighed, den holdes i, hvilket er grunden til, at de så ofte forveksles med hinanden.

Holdbarheds- og gennemvædningstestning behandles ofte som synonymer. I almindelig brug er de: begge holder en vedvarende belastning i en lang periode. Hvor teams adskiller dem, fokuserer udholdenhedstest på, om svartiderne stiger, mens soak-test fokuserer på ressourceforbrug såsom hukommelse, filhandles og forbindelsespuljer. At køre en giver dig normalt bevis for begge.

Nøglemålinger, der skal registreres under testen

En performancekørsel er kun så god som det, du optager, mens den udføres. Registrer disse seks på server- og klientsiden, og sammenlign dem derefter med baseline i stedet for med en mavefornemmelse.

Læs gennemsnittet og percentilen sammen. Et gennemsnit på 800 ms med en 95. percentil på 900 ms beskriver et konsistent system. Det samme gennemsnit med en 95. percentil på 9 sekunder betyder, at én ud af tyve brugere har det dårligt, og gennemsnittet skjuler det.

Se på formen, ikke kun værdien. I enhver langvarig test er en flad ressourcelinje et bestået resultat, og en stigende er en lækage, selv når det absolutte tal stadig er komfortabelt inden for grænsen i det øjeblik, kørslen slutter.

Ofte Stillede Spørgsmål