soak testing tutorial what is soak testing
Denne omfattende veiledningen om bløtprøving forklarer hva som er bløtprøving, hvorfor trenger vi det, dets anvendelse, fordeler, beste fremgangsmåter og ulemper:
Ulike typer testing må utføres mens du tester et program. Funksjonell og ikke-funksjonell testing er de to brede kategoriene vi kan kategorisere testtypene i.
Funksjonstesting, som navnet antyder, er relatert til testing av funksjonaliteten til applikasjonen. Ikke-funksjonell testing dekker derimot alle de andre testene (brukervennlighet, ytelse osv.), Unntatt funksjonstesting.
Hva du vil lære:
Soak Testing - En komplett guide
Denne opplæringen introduserer deg for begrepene Soak testing, som er en type ytelsestesting.
Som vist på bildet ovenfor, kan vi si at Soak testing er en type ikke-funksjonell testing.
Hva er Soak Testing
Det er en type ytelsestesting for å sjekke om en Application Under Test (AUT) tåler kontinuerlig belastning i en forhåndsbestemt tidsramme. Dette er en ikke-funksjonell type testing. Det blir også betegnet som 'Utholdenhetstesting' eller 'Longevity Testing' .
Hvis du går under det bokstavelige navnet, har ordet ‘suge’ i seg selv betydningen av hva denne testen har til hensikt å gjøre. Dermed er det å teste en applikasjon for en bestemt periode for høy belastning.
Man kan lure på hva som kan være forskjellen hvis en applikasjon belastes i en time eller kanskje 20 timer. Men ja, det har betydning.
Dette kan forklares bedre med et virkelig scenario. Hvis et tau blir trukket fra begge ender av to personer i en stund, kan det bare motstå trykket, men hvis det samme fortsetter i flere dager, kan tauet bare bryte ved å gi etter for trykket fra hver ende.
(bilde kilde )
Så er tilfellet med programvaren. Når vi utsetter en applikasjon for høy belastning (noen hundre eller tusen brukere), kan det bare fungere bra i en time. Men når den samme applikasjonen utsettes for belastning i 20 timer, kan den kollapse helt.
(bilde kilde )
Kontinuerlig tung trafikk over lang tid kan forårsake varierende problemer i applikasjonen. Dermed oppstår behovet for Soak Testing.
I denne testingen er det grunnleggende konseptet å laste applikasjonen med forventede brukere, men i en lengre periode. Dette hjelper til med å identifisere de forskjellige underliggende problemene som ellers ikke blir oppdaget til det faktiske scenariet oppstår i live-applikasjonen.
Behov for bløtprøving
For å forstå behovet må vi også være oppmerksom på de mulige problemene som en applikasjon kan gjennomgå i tilfelle den støter på tung belastning over lang tid.
La oss gå gjennom de forskjellige grunnene som gjør at Soak-testing er nødvendig.
#1) Det kreves hovedsakelig å identifisere problemer som feil minnehåndtering, databaseforbindelsesproblemer, nedverdigende responstid, etc.
Hver av disse problemene er forklart nedenfor:
beste mp3 nedlasting for android uten annonser
- Feil minneadministrasjon kan innebære problemer som et minne som blir tildelt for bruk, men aldri frigitt, eller når ressurser bruker mer minne enn det som kreves. Når slike scenarier fortsetter i lang tid, kan det føre til at systemet går tom for minne, noe som resulterer i at et program slutter å svare.
- Problemer med databasetilkobling - Feil som oppstod under lukking av en databaseforbindelse, kan på sikt føre til at applikasjonen krasjer helt.
- Nedbrytende responstid - Noen ganger kan en applikasjon bli mindre effektiv, og responstiden kan øke. I løpet av en tid kan dette føre til at applikasjonen slutter å svare.
For å unngå at slike situasjoner oppstår, foretrekker vi å Soak teste søknaden vår. Det hjelper med å identifisere slike underliggende problemer som ellers kan oppdages.
#to) Soak Test hjelper til med å avgjøre om søknaden vår er klar til å ta opp belastningen i en varig periode.
# 3) Det gjør det mulig for teamet å ta korrigerende tiltak basert på hvordan systemet reagerer på Soak-testene.
Når skal du begynne å suge testen?
(bilde kilde )
Ideelt sett, som alle andre ytelsestester, bør denne testingen gjøres under produktutvikling sammen med funksjonstesting. Dette blir imidlertid sjelden gjort. Årsaken er åpenbar, dvs. administrere prosjektkostnadene.
Dermed ligger fokuset hovedsakelig i funksjonell testing, og alle former for ytelsestesting får generelt et baksetet og tas opp nær utgivelsesdatoen for søknaden.
Generelt tas Soak-tester opp like før applikasjonen blir utgitt til klienten. Men dette har en stor ulempe som er knyttet til å løse problemet.
Når et hvilket som helst ytelsesproblem blir funnet på et senere tidspunkt, kan det være vanskelig å fikse det, da det kan innebære en større kodeendring som kanskje ikke er mulig med tanke på nærheten til applikasjonsleveringsdatoen.
Det er derfor alltid tilrådelig at denne testingen skal utføres i god tid, slik at de identifiserte problemene kan løses.
Soak Testing Strategi
(bilde kilde )
Akkurat som en teststrategi er utarbeidet for å teste en applikasjon, utarbeides en strategi på forhånd for å utføre Soak-testing, og dette er veldig nødvendig.
hva vr headset fungerer med xbox one
La oss ta en titt på hva som ligger i forberedelsen av Soak Testing Strategy.
Før du starter Soak Test, må teamet bestemme belastningen som applikasjonen må testes med Soak for. Varigheten det må testes for må også være forhåndsbestemt. Generelt leveres dette av utviklingsteamet.
Testteamet bør bestemme scenariene de planlegger til Soak Test. Dette vil igjen avhenge av kundens forpliktelse og kravet til applikasjonen under test.
Ettersom Soak-tester hovedsakelig er fokusert på å identifisere problemer med minne og ressurslekkasje, er det viktig å vite minnet og databaseforbruket på forhånd mot de tilgjengelige.
Miljøopplysningene som operativsystemet, enheten osv. Som Soak-testing skulle utføres på, bør også avgjøres.
Sist, men ikke minst, risikoen (e) som er involvert, bør også tas i betraktning. Det bør alltid lages en reserveplan for slike situasjoner. For eksempel, hvis databasen krasjer mens du tester, hvilke andre alternativer er tilgjengelige i stedet for og så videre.
Scenarier for bløtprøving
Når et e-handelsnettsted kunngjør et online salg av produktene sine, er det naturlig at nettstedet lastes inn i løpet av salgsperioden, som kan strekke seg i 3-5 dager. I en slik situasjon bør nettstedet testes i bløt for å unngå uventet krasj.
I løpet av avslutningen av et regnskapsår kan et banks nettsted ha en veldig stor belastning i en sammenhengende periode. I en slik situasjon må nettstedet ha blitt Soak-testet for å unngå uventet krasj av webapplikasjonen.
Når en applikasjon er designet for å håndtere en forhåndsbestemt belastning i en kontinuerlig forhåndsbestemt periode, blir det nødvendig å teste applikasjonen for en belastning minst 2 ganger dens kjente lasthåndteringsevne.
For eksempel, hvis et nettsted er kjent for å håndtere en 500 brukerbelastning i en sammenhengende periode på 15 timer, bør applikasjonen også være Soak-testet for 1000 brukere i 15 timer. Dette vil hjelpe oss å vite om applikasjonen vil svare unormalt når den blir tvunget til å doble belastningen.
Beste praksis
(bilde kilde )
- Soak Testing bør alltid gjøres ved å kjenne applikasjonsgrensen for tomgang, både når det gjelder brukere og varighet. Dette kreves for å være kjent som målet er å laste applikasjonen med de forventede brukerne, men i lang varighet.
- Det er tilrådelig å kjøre Soak-tester om natten, eller hvis det skal gjøres enda lengre varighetstesting, anbefales det å gjøre det i helgene. Årsaken er åpenbar, dvs. i løpet av arbeidstiden blir ressursene bundet, mens testserverne kan være tilgjengelige for bruk i lange perioder om natten eller ikke arbeidstid. Dermed er ikke arbeidstid den ideelle tiden for slike tester.
- Risikoer forbundet med Soak-testing av en applikasjon bør alltid analyseres, og en avbøtningsplan skal være klar for den samme enhver hendelse.
Sug testbegrensninger
(bilde kilde )
- Den lange varigheten som kreves for å teste en applikasjon er en stor begrensning på grunn av tidens utilgjengelighet. Dermed kan bløtprøving til tider unngås på grunn av mangel på tid.
- Testmiljøet må velges nøye slik at enhver annen type testing som utføres på applikasjonen ikke påvirkes. Dette kan skje, da testing av applikasjonen for tung belastning over lengre tid kan føre til problemer.
- Tiden for Soak-testing må avgjøres nøye og bør hovedsakelig være arbeidstiden utenfor arbeidstiden (som en helg eller natt timer etter arbeidsstenging).
- Generelt er automatiseringsverktøy nødvendig for Soak-testing, ettersom testene må kjøres i lange perioder med et stort antall brukere.
Ulemper ved Soak Testing
- Prosjektets tidslinjer kan bli påvirket på grunn av Soak-testing, da tiden som kreves for det generelt er høy.
- Ressurser blir bundet for testvarigheten, da det er høy minnebruk på grunn av et stort antall brukere som får tilgang til applikasjonen.
Konklusjon
Gjennom denne veiledningen lærte vi hva Soak testing er og hva som gjør det nødvendig å utføre denne testen.
Nå med denne forståelsen av hva Soak Testing er og hva slags problemer det hjelper med å identifisere, kan vi veldig godt forstå behovet for å utføre det samme. Spesielt i tider når hele verden alltid er koblet til, blir denne testingen et must.
Vi så når vi skulle begynne å Soak test sammen med tilnærmingen som skulle følges. Scenarier, beste praksis og begrensningene knyttet til det ble også diskutert her.
Vi håper denne opplæringen hjalp deg med å forstå hva som er Soak-testing, og må ha forbedret din kunnskap om det samme.
Anbefalt lesing
- Lastetesting med HP LoadRunner-opplæringsprogrammer
- Destruktiv testing og ikke-destruktiv testing
- Testing Primer eBook Download
- Korrelasjon - Lastetesting med LoadRunner
- Funksjonstesting mot ikke-funksjonell testing
- Forskjellen mellom Desktop, Client Server Testing og Web Testing
- Lastetesting ved hjelp av LoadUI - Et gratis og åpen kildekode lastetestingverktøy
- SOA Testing Tutorial: Testing Methodology For a SOA Architecture Model