Menu

Soak Testing Tutorial - Hvad er Soak Testing

soak testing tutorial what is soak testing

Prøv Vores Instrument Til At Fjerne Problemer

Denne omfattende guide til blødprøvning forklarer, hvad der er blødprøvning, hvorfor har vi brug for det, dets anvendelse, fordele, bedste praksis og ulemper:

Forskellige typer test skal udføres under test af en softwareapplikation. Funktionel og ikke-funktionel test er de to brede kategorier, hvor vi kan kategorisere testtyperne.

hvordan man finder netværkssikkerhedsnøgle på Android-telefon

Funktionstest, som navnet selv antyder, vedrører test af applikationens funktionalitet. Ikke-funktionel test dækker derimod alle andre test (brugervenlighed, ydeevne osv.) Bortset fra funktionstest.

Blødprøvning

Hvad du vil lære:

Soak Testing - En komplet guide

Denne tutorial introducerer dig til begreberne Soak-test, som er en type Performance-test.

Testtyper

Som det ses på billedet ovenfor, kan vi sige Soak-test er en type ikke-funktionel test.

Hvad er Soak Testing

Det er en type ydelsestest for at kontrollere, om en Application Under Test (AUT) kan modstå kontinuerlig belastning i en forudbestemt tidsramme. Dette er en ikke-funktionel type test. Det betegnes også som 'Udholdenhedstest' eller 'Test af lang levetid' .

Hvis du går under dets bogstavelige navn, har ordet 'blød' i sig selv betydningen af, hvad denne test har til hensigt at gøre. Således er det, denne test handler om at udsætte en ansøgning for en bestemt periode for høj belastning.

Man kan undre sig over, hvad der kan være forskellen, hvis en applikation belastes i en time eller måske 20 timer. Men ja, det har betydning.

Dette kan forklares bedre med et virkeligt scenarie. Hvis et reb trækkes fra begge ender af to personer i nogen tid, kan det måske bare modstå trykket, men hvis det samme fortsættes i flere dage, kan rebet måske bare bryde ved at give efter for trykket fra begge ender.

tryk1

(billede kilde )

Så er tilfældet med softwaren. Når vi udsætter en applikation for høj belastning (et par hundrede eller tusind brugere), kan det bare fungere fint i en time. Men når den samme applikation udsættes for belastningen i 20 timer, kan den kollapse helt.

Bryder sammen

(billede kilde )

Kontinuerlig tung trafik i lang tid kan forårsage forskellige problemer i applikationen. Der opstår således behovet for Soak Testing.

I denne test er det grundlæggende koncept at indlæse applikationen med forventede brugere, men i en længere periode. Dette hjælper med at identificere de forskellige underliggende problemer, der ellers ikke bliver opdaget, indtil det faktiske scenario opstår i live-applikationen.

Behov for blødprøvning

For at forstå behovet skal vi også være opmærksomme på de mulige problemer, som en applikation kan gennemgå, hvis den støder på tung belastning i lang tid.

Lad os gennemgå de forskellige grunde, der gør Soak-test nødvendig.

# 1) Det er primært nødvendigt at identificere problemer som forkert hukommelsesstyring, databaseforbindelsesproblemer, nedværdigende responstid for applikationer osv.

Hver af disse problemer er forklaret nedenfor:

  • Forkert hukommelsesadministration kan involvere problemer som en hukommelse, der tildeles til brug, men aldrig frigives, eller når ressourcer bruger mere hukommelse, end det kræves. Når sådanne scenarier fortsætter i lang tid, kan det føre til, at systemet løber tør for hukommelse, hvilket resulterer i, at et program stopper med at reagere.
  • Problemer med databaseforbindelse - Fejl, der opstår under lukning af en databaseforbindelse, kan i det lange løb resultere i, at applikationen går helt ned.
  • Forringelse af responstid for applikation - Til tider kan en applikation af en eller anden grund blive mindre effektiv, og dens responstid kan øges. I løbet af et stykke tid kan dette medføre, at applikationen holder op med at svare.

For at undgå, at sådanne situationer opstår, foretrækker vi at gennembløde test af vores ansøgning. Det hjælper med at identificere sådanne underliggende problemer, der ellers måske ikke bliver opdaget.

#to) Soak Test hjælper med at afgøre, om vores ansøgning er klar til at tage belastningen op i en vedvarende periode.

# 3) Det gør det muligt for teamet at træffe korrigerende handlinger baseret på, hvordan systemet reagerer på Soak-testene.

Hvornår skal man begynde med blødprøve?

Start af Soak Testing

(billede kilde )

Ideelt set skal denne test ligesom enhver anden præstationstest udføres under produktudvikling sammen med funktionstest. Dette gøres dog sjældent. Årsagen er indlysende, dvs. at styre projektomkostningerne.

Fokus ligger således hovedsageligt i funktionstestning, og alle former for Performance-test får generelt et bagsæde og tages op tæt på udgivelsesdatoen for applikationen.

Generelt tages Soak-test op lige før applikationen frigives til klienten. Men dette har en stor ulempe, der vedrører løsning af problemet.

Når der findes et ydeevneproblem på et senere tidspunkt, kan det være svært at rette det, da det kan involvere en større kodeændring, der muligvis ikke er mulig i betragtning af nærheden til applikationsleveringsdatoen.

Således anbefales det altid, at denne test udføres i god tid, så de identificerede problemer kan løses.

Blødgør teststrategi

Blødgør teststrategi

(billede kilde )

Ligesom en teststrategi er forberedt til at teste en applikation, udarbejdes en strategi på forhånd til at udføre Soak-test, og det er meget nødvendigt.

hvordan man åbner en bittorrent-fil

Lad os se på, hvad der indgår i Soak Testing Strategy-forberedelsen.

Inden du starter Soak-testen, skal holdet bestemme den belastning, som applikationen skal testes med Soak. Varigheden, for hvilken den skal testes, skal også være forudbestemt. Generelt leveres dette af udviklingsteamet.

Testteamet skal beslutte, hvilke scenarier de planlægger til Soak Test. Dette vil til gengæld afhænge af kundens forpligtelse og krav til applikationen under test.

Da Soak-test hovedsagelig er fokuseret på at identificere problemer med hukommelse og ressourcelækage, er det vigtigt at kende hukommelsen og databaseforbruget på forhånd mod de tilgængelige.

Miljøoplysningerne som OS, enheden osv., Som Soak-test ville blive udført på, bør også afgøres.

Sidst men ikke mindst skal de (n) risiko (r) inddrages. En backupplan skal altid laves til sådanne situationer. For eksempel, hvis databasen går ned under test, hvilke andre alternativer er der i stedet for og så videre.

Scenarier til blødprøvning

Når et e-handelswebsted annoncerer et online-salg af sine produkter, er det naturligt, at webstedet bliver indlæst i løbet af salgsperioden, der kan strække sig over 3-5 dage. I en sådan situation skal hjemmesiden testes i blød for at undgå uventet nedbrud.

I løbet af afslutningen af ​​et regnskabsår kan et banks websted muligvis have en meget høj belastning i en sammenhængende periode. I en sådan situation skal webstedet være gennemblødtestet for at undgå ethvert uventet nedbrud af webapplikationen.

Når en applikation er designet til at håndtere en forudbestemt belastning i en kontinuerlig forudbestemt periode, bliver det nødvendigt at teste applikationen for en belastning mindst 2 gange dens kendte belastningshåndteringsevne.

For eksempel, hvis et websted er kendt for at håndtere en 500 brugerbelastning i en sammenhængende periode på 15 timer, så skal applikationen også være gennemblødtestet for 1000 brugere i 15 timer. Dette ville hjælpe os med at vide, om applikationen ville reagere unormalt, når den blev tvunget til at fordoble dens belastningskapacitet.

Bedste praksis

Soak Testing - Bedste praksis

(billede kilde )

  • Soak Testing skal altid udføres ved at kende applikationens tomgangsgrænse, både med hensyn til brugerne og varigheden. Dette kræves for at være kendt, da målet er at indlæse applikationen med de forventede brugere, men i lang varighed.
  • Det tilrådes at køre Soak-test om natten, eller hvis test af endnu længere varighed skal udføres, anbefales det at gøre det i weekenden. Årsagen er åbenbar, dvs. i løbet af arbejdstiden bliver ressourcer bundet, mens testserverne om natten eller ikke-arbejdstid kan være tilgængelige til brug i længere tid. Således er ikke arbejdstid det ideelle tidspunkt til sådanne tests.
  • Risici forbundet med Soak-test af en applikation skal altid analyseres, og en afbødningsplan skal være klar til den samme enhver hændelse.

Sug testbegrænsninger

Begrænsninger i Soak Testing

(billede kilde )

  • Den lange varighed, der kræves for at teste en applikation, er en stor begrænsning generelt på grund af tidens utilgængelighed. Således kan blødprøvning til tider undgås på grund af mangel på tid.
  • Testmiljøet skal vælges nøje, så enhver anden type test, der udføres på applikationen, ikke påvirkes. Dette kan ske, da test af applikationen til tung belastning i lang varighed kan resultere i problemer.
  • Tiden til Soak-test skal besluttes nøje og bør hovedsagelig være arbejdstid uden for arbejdet (som en weekend eller nat timer efter arbejdslukning).
  • Generelt kræves automatiseringsværktøjer til Soak-test, da testene skal køres i lange perioder med et stort antal brugere.

Ulemper ved Soak Testing

  • Projektets tidslinjer kan blive påvirket på grund af Soak-test, da den nødvendige tid til det samme generelt er høj.
  • Ressourcer bliver bundet i testvarigheden, da der er høj hukommelsesudnyttelse på grund af et stort antal brugere, der får adgang til applikationen.

Konklusion

Gennem denne vejledning lærte vi, hvad Soak-test er, og hvad der gør det nødvendigt at udføre denne test.

Nu med denne forståelse af, hvad Soak Testing er, og hvilken slags problemer det hjælper med at identificere, kan vi meget godt forstå behovet for at udføre det samme. Især i tider, hvor hele verden altid er forbundet, bliver denne test et must.

Vi så, hvornår vi skulle begynde at gennembløde test sammen med den tilgang, der skulle følges. Scenarier, bedste praksis og de begrænsninger, der er forbundet med det, blev også diskuteret her.

Vi håber, at denne tutorial hjalp dig med at forstå, hvad der er Soak-test, og skal have forbedret din viden om det samme.

Anbefalet læsning

^