Soak Testing
Soak Testing er en type ikke-funksjonell testing som brukes til å måle ytelsen til en programvare under et enormt volum av belastning over lengre tid. Målet med Soak testing er å sikre om programvaren opprettholder høyt volum av bruk og å sjekke hva som ville skje utenfor designens forventninger.
Bildet nedenfor viser en testsyklus som viser på hvilket stadium Soak Testing ( Type of Performance Test ) utføres på en applikasjon.
I denne typen testing er det som i utgangspunktet overvåkes minnebruk av et program i et system. Den tester på systemnivå for å finne ut om systemet vil tåle et veldig høyt volum av bruk og for å se hva som vil skje utenfor designforventningene.
I denne veiledningen vil du lære-
- Hvorfor Soak Testing?
- Når skal du gjøre Soak Testing?
- Soak Testing Strategi
- Kjennetegn ved Soak Testing
- EKSEMPLER på Soak Testing
- Vanlige problemer observert under Soak Testing
Hvorfor Soak Testing?
Et system kan oppføre seg normalt når det brukes i 2 timer, men når det samme systemet brukes kontinuerlig i 10 timer eller mer enn det, kan det mislykkes eller oppføre seg unormalt / tilfeldig / det kan krasje. For å forutsi en slik svikt utføres Soak Testing.
Når skal du gjøre Soak Testing?
Soak Testing bør gjøres i følgende scenarier: -
- Før bygningen distribueres til klienten, dvs. før utgivelsen av en applikasjon på en bestemt plattform, må den gjennomgå en vellykket serie lastetester på høye eller tilsvarende trafikknivåer. Etter det utføres bløtprøving . Det hjelper oss å finne ut hvordan vi skal kjøre et bestemt program i en lengre periode. Hvis problemer som minnelekkasjer / minnekorrupsjon blir funnet i løpet av perioden, dvs. når det er på Soak, bør det rapporteres umiddelbart.
- Den beste tiden å gjøre en bløtprøving er over helgene, ettersom et program må være i en løpende tilstand så lenge som over en dag eller natt. Det avhenger helt av begrensningene i testsituasjonen. Soak-tester er et av de viktigste kravene til samsvar som må følges nøye av hvert selskap.
Soak Testing Strategi
Long Session Soak Testing er en strategi der et system er under belastning over lengre tid.
Et enkelt eksempel er hvor brukeren er logget på et system i mange timer med å utføre en rekke forretningstransaksjoner. På denne måten blir mye data opprettet. Det kan være mye belastning på systemet / databaseserveren som kan føre til at systemet / databaseserveren stopper / krasjer.
Under Long Session Soak Testing utføres flere dagers (si 30 dager) aktiviteter i en begrenset tidsramme (si 2 dager). Antall transaksjoner i denne begrensede tidsrammen skal samsvare med eller overgå flere dager med transaksjoner. Fokuset bør være på antall behandlede transaksjoner. Den viktigste delen av Soak Testing er å sjekke tilgjengelig minne i CPUen og hvor mye minne som vil være i bruk. Vi må registrere minnebruk i begynnelsen og slutten av en bløtprøve. Om nødvendig er også minnebruk av fasiliteter som Java Virtual Machines viktig og må overvåkes.
Nedenfor er det noen flere sjekker som må gjøres av noen brukere / tester før de begynner med Soak Testing:
a) Overvåke databaseressursforbruket.
b) Overvåk serverressursforbruket (tidligere CPU-bruk).
c) Soak test bør kjøres med realistisk brukers samtidighet.
Kjennetegn ved Soak Testing
En standard Soak Testing Method bør ha følgende egenskaper: -
- Varigheten av de fleste Soak Test bestemmes ofte av den tilgjengelige tiden.
- Enhver applikasjon må kjøre uten avbrudd hvis den krever lengre tid.
- Den skal dekke alle scenariene som er interessert i interessentene.
- For det meste har hvert system en jevnlig tidsperiode for vedlikeholdsvindu, og tiden mellom slike vindusperioder er en viktig driver for å bestemme omfanget av en Soak Test.
EKSEMPLER på Soak Testing
- I tilfelle bankdomene når det er store mengder data fra selgere, vil testeren legge systemet under belastning kontinuerlig i 70 til 150 timer for å sjekke hvordan applikasjonen oppfører seg i løpet av denne lastingsperioden.
- Anta at det er 33 000 pålogginger som må gjennom systemet, det representerer syv og en halv dags aktivitet. I dette tilfellet kan en 60-70 timers Soak Test startes fredag kveld rundt 18.00, som kan være ferdig mandag morgen klokka 6. Bare med en slik test vil det være mulig å observere forringelse av ytelsen under kontrollerte forhold.
- Når det gjelder videospill, innebærer mobilapplikasjoner osv. Å la spillet eller applikasjonen kjøre i en lengre periode, i forskjellige driftsmåter - som tomgang, pause på tittelskjermen og så videre for å finne ut om et program kan håndtere kontinuerlig forventet belastning.
Vanlige problemer observert under Soak Testing
- Minnetildeling (minnelekkasjer som til slutt vil resultere i en minnekrise eller avrundingsfeil som bare manifesterer seg over tid).
- Bruk av databaseressurser (unnlatelse av å lukke databasemarkører under noen forhold som til slutt vil resultere i at hele systemet stopper opp).
- Det kan også føre til ytelsesnedbrytning, dvs. for å sikre at responstiden etter en lang periode med vedvarende aktivitet er like god som den var i begynnelsen av testen.
- Unnlatelse av å lukke forbindelser mellom nivåene i et flerlags system under noen omstendigheter som kan stoppe noen eller alle modulene i systemet.
- Den gradvise nedbrytningen av responstiden til noen funksjoner som interne datastrukturer blir mindre effektiv under en lang test.
Sammendrag
- I programvareutvikling gjøres Soak-testing for å avgjøre om applikasjonen som testes kan bære kontinuerlig belastning.
- Det er en type ytelsestest.
- Det hjelper systemet med å avgjøre om det tåler et veldig høyt volum av bruk
- I denne typen testing er det som i utgangspunktet overvåkes minnebruk av et program i et system
- Kontroller som må utføres av en bruker / tester før de begynner med Soak Testing inkluderer
- Overvåke databaseressursforbruket.
- Overvåk serverressursforbruket (tidligere CPU-bruk).
- Soak test bør kjøres med realistisk brukers samtidighet.
Denne artikkelen er bidratt av Pallavi De