Hvad er Soak Testing? Definition, betydning, eksempler
Soak test
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: –
- 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.
- 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å iblødsætningstest
- 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
- Hukommelsesallokering (hukommelseslækager, der i sidste ende ville resultere i en hukommelseskrise eller afrundingsfejl, der kun viser sig over tid).
- Databaseressourceudnyttelse (manglende lukning af databasemarkører under nogle forhold, hvilket i sidste ende ville resultere i, at hele systemet går i stå).
- 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.
- 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.
- Den gradvise forringelse af en responstid for nogle funktioner, efterhånden som interne datastrukturer bliver mindre effektive under en lang test.
Resumé
- In Software Engineering, Iblødsætningstest udføres for at afgøre, om applikationen under test kan tåle den kontinuerlige belastning.
- Det er en form for præstationstest.
- Det hjælper systemet med at afgøre, om det kan klare en meget høj forbrugsmængde
- I denne type test er det, der grundlæggende overvåges, hukommelsesudnyttelsen af en applikation i et system
- Kontrol, der skal udføres af enhver bruger/tester, før de begynder med Soak Testing inkluderer
- Overvåg databaseressourceforbruget.
- Overvåg serverressourceforbruget (ex CPU-brug).
- Soak-testen bør køre med realistisk brugersamtidighed.