Soak Test i programvare: Betydning og eksempler

Hva er Soak Testing?

Bløtleggingstesting er en type ikke-funksjonell testing som brukes til å måle ytelsen til en programvareapplikasjon under et stort belastningsvolum over en lengre periode. Målet med Soak-testing er å sikre om programvareapplikasjonen opprettholder høy bruksvolum og å sjekke hva som ville skje utenfor designforventningene.

Bildet nedenfor viser en testsyklus som viser på hvilket stadium bløtleggingstestingen (Type ytelsestest) utføres på en applikasjon.

I denne typen testing er det som i utgangspunktet overvåkes minneutnyttelsen av en applikasjon i et system. Det testes på systemnivå for å finne ut om systemet vil tåle et svært høyt bruksvolum og for å se hva som ville skje utenom designforventningene.

Hvorfor gjør man bløtleggingstesting?

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 svikte eller oppføre seg unormalt/tilfeldig/det kan krasje. For å forutsi slik svikt utføres bløtleggingstesting.

Når skal man gjøre bløtleggingstesting?

Bløtleggingstesting bør utføres i følgende scenarier: –

1. Før den bygget blir distribuert til klienten, dvs. før utgivelsen av en applikasjon på en spesifikk plattform, må den gjennom en vellykket serie belastningstester på høye eller tilsvarende trafikknivåer. Etter det bløtleggingstesting utføres. Det hjelper oss å finne ut hvordan vi skal kjøre en bestemt applikasjon over en lengre periode. Hvis det oppdages problemer som minnelekkasjer/minnekorrupsjon i løpet av perioden, dvs. når den er på Soak, bør det rapporteres umiddelbart.
2. Den beste tiden å gjøre en bløtleggingstesting er i helgene, da et program må være i drift så lenge som over en dag eller natt. Det avhenger helt av begrensningene i testsituasjonen. Bløtleggingstester er et av de viktigste samsvarskravene som må følges svært strengt av hvert selskap.

Bløtleggingsteststrategi

Long Session Soak Testing er en strategi der et system er under belastning over lengre tid.

Et enkelt eksempel er hvor brukeren forblir pålogget et system i mange timer og utfører en rekke forretningstransaksjoner. På denne måten skapes mye data. Det kan være mye belastning på systemet/databaseserveren som kan føre til at systemet/databaseserveren stopper opp/krasj.

Under Long Session Soak Testing utføres flere dagers (f.eks. 30 dager) aktiviteter i en begrenset tidsramme (f.eks. 2 dager). Antall transaksjoner i denne begrensede tidsrammen skal samsvare med eller overgå flere dagers transaksjoner. Fokuset bør være på antall transaksjoner som behandles. Den viktigste delen av Soak Testing er å sjekke tilgjengelig minne i CPU og hvor mye minne som vil være i bruk. Vi må registrere minnebruken ved starten og slutten av en bløtleggingstest. Om nødvendig kan minnebruken til fasiliteter som f.eks Java Virtuelle maskiner er også viktige og må overvåkes.

Nedenfor er noen flere kontroller som må gjøres av enhver bruker/tester før de begynner med Soak Testing:

a) Overvåk databaseressursforbruket.

b) Overvåk serverressursforbruket (eks CPU-bruk).

c) Soak-testen bør kjøres med realistisk brukersamtidighet.

Kjennetegn ved Soak Testing

En standard bløtleggingstestmetode bør ha følgende egenskaper: –

• Varigheten av de fleste Soak Tester bestemmes ofte av tiden som er tilgjengelig.
• Enhver applikasjon må kjøres uten avbrudd hvis den krever en lengre periode.
• Den bør dekke alle scenariene som er blitt enige om av interessentene.
• Stort sett har hvert system et regelmessig vedlikeholdsvindu, og tiden mellom slike vinduer er en nøkkeldriver for å bestemme omfanget av en Soak Test.

Eksempler på soak-testing

• Når det gjelder bankdomene når det er en stor mengde data fra selgere, vil testeren sette systemet under belastning kontinuerlig i 70 timer til 150 timer for å sjekke hvordan applikasjonen oppfører seg i denne lasteperioden.
• Anta at det er 33,000 60 pålogginger som må settes gjennom systemet, det representerer syv og en halv dag med aktivitet. I dette tilfellet kan en 70-6 timers sugetest startes innen fredag ​​kveld rundt kl. XNUMX, som kan fullføres innen Monday morgen kl 6. Bare med en slik test vil det være mulig å observere eventuell forringelse av ytelsen under de kontrollerte forholdene.
• Når det gjelder videospill, Mobil applikasjoner osv. involverer å la spillet eller applikasjonen kjøre i en lengre tidsperiode, i ulike driftsmoduser - som tomgang, pause på tittelskjermen og så videre for å finne ut om en applikasjon kan håndtere den kontinuerlige forventede belastningen .

Vanlige problemer observert under bløtleggingstesting

1. Minneallokering (minnelekkasjer som til slutt vil resultere i en minnekrise eller avrundingsfeil som bare viser seg over tid).
2. Databaseressursutnyttelse (unnlatelse av å lukke databasemarkører under noen forhold som til slutt vil føre til at hele systemet stopper opp).
3. Det kan også føre til prestasjonsforringelse, dvs. å sikre at responstiden etter en lang periode med vedvarende aktivitet er like god som den var i begynnelsen av testen.
4. Unnlatelse av å lukke forbindelser mellom nivåer i et flerlagssystem under noen omstendigheter som kan stoppe noen eller alle moduler i systemet.
5. Den gradvise degraderingen av responstiden for noen funksjoner ettersom interne datastrukturer blir mindre effektive under en lang test.

Hvordan denne testen passer inn i ytelsestestingfamilien

Ytelsestesting er en paraplybetegnelse. Variantene nedenfor skiller seg bare i formen på den påførte belastningen og varigheten den holdes i, og det er derfor de så ofte forveksles med hverandre.

Utholdenhetstesting og gjennomvåtningstesting blir ofte behandlet som synonymer. Vanligvis brukes de slik: begge holder en vedvarende belastning over lengre tid. Der team skiller dem fra hverandre, fokuserer utholdenhetstesting på om responstidene stiger, mens soak-testing fokuserer på ressursforbruk som minne, filhåndtak og tilkoblingspooler. Å kjøre én gir deg vanligvis bevis for begge.

Viktige målinger å fange opp under testen

En ytelsesbasert kjøring er bare så god som det du registrerer mens den kjører. Registrer disse seks på server- og klientsiden, og sammenlign dem deretter med grunnlinjen i stedet for mot en magefølelse.

Les gjennomsnittet og persentilen sammen. Et gjennomsnitt på 800 ms med en 95. persentil på 900 ms beskriver et konsistent system. Det samme gjennomsnittet med en 95. persentil på 9 sekunder betyr at én av tjue brukere har det dårlig, og gjennomsnittet skjuler det.

Se på formen, ikke bare verdien. I enhver langvarig test er en flat ressurslinje et bestått resultat og en stigende en er en lekkasje, selv når det absolutte tallet fortsatt er komfortabelt innenfor grensen i det øyeblikket kjøringen avsluttes.

Spørsmål og svar