Menu

Stresstestguide til begyndere

stress testing guide

Prøv Vores Instrument Til At Fjerne Problemer

En omfattende stresstestguide til begyndere:

Understrege noget ud over et punkt resulterer i alvorlige konsekvenser for mennesker, maskiner eller et program. Det forårsager enten alvorlige skader eller bryder det helt.

På samme måde lærer vi i denne vejledning, hvordan man stresstest webapplikationer sammen med dens effekt.

For at undgå permanent skade på dine apps eller websteder, når de er stressede, dvs. tungt belastede, er vi nødt til at finde brudpunktet og til gengæld løsningen for at undgå sådanne forhold. Tænk bare, hvordan det ville være, når dit shoppingwebsted går ned under julesalget. Hvor meget ville tabet være?

Stresstest

Nedenfor er nogle eksempler på reelle tilfælde, hvor det er meget vigtigt at stresstest en app eller et websted:

softwareudvikling livscyklus designfase

# 1) Kommercielle shopping-apps eller -websteder skal udføre stresstest, da belastningen bliver meget høj under festivaler, salg eller særtilbud.

#to) Finansielle apps eller websteder skal udføre stresstest, da belastningen stiger til tider som når en virksomheds aktie stiger, mange mennesker logger ind på deres konti for at købe eller sælge, online shoppingwebsteder omdirigerer 'Net-bankfolk' til betaling etc.

# 3) Web- eller e-mail-apps skal stresstestes.

# 4) Sociale netværkswebsteder eller apps, blogs osv. Skal stresstestes osv.

Hvad du lærer:

Hvad er stresstest og hvorfor stresstest?

Ikke-funktionelle testtyper

Stresstest defineres som processen med at teste hardware eller software for dets stabilitet under en tung belastningstilstand. Denne test udføres for at finde det numeriske punkt, når systemet går i stykker (med hensyn til et antal brugere og serveranmodninger osv.) Og den relaterede fejlhåndtering for det samme.

Under stresstest bombes applikationen under test (AUT) med en tung belastning i en given periode for at verificere brudpunktet og for at se, hvor godt fejlhåndtering udføres.

Eksempel: MS Word giver muligvis en 'Ikke svarer' fejlmeddelelse, når du prøver at kopiere en 7-8 GB fil.

Du har bombarderet Word med en enorm fil, og den kunne ikke behandle en sådan stor fil, og som et resultat hænges den. Vi dræber normalt apps fra Jobliste, når de holder op med at svare, årsagen bag det er, at apps bliver stressede og holder op med at svare.

Følgende er nogle tekniske grunde bag udførelse af stresstest:

  • For at kontrollere systemets opførsel under unormal eller ekstrem belastningstilstand.
  • For at finde den numeriske værdi af brugere, anmodninger osv., Hvorefter systemet muligvis går i stykker.
  • Håndter fejlen nådigt ved at vise passende meddelelser.
  • At være godt forberedt på sådanne forhold og tage forholdsregler som kode rengøring, DB rengøring osv.
  • At verificere datahåndtering inden systemet går i stykker, dvs. at se om data blev slettet, gemt eller ej osv.
  • At verificere sikkerhedstrussel under sådanne brud på betingelser osv.

Strategi til stresstest

Dette er en type ikke-funktionel test, og denne test udføres normalt, når den funktionelle test af et websted eller en app er afsluttet. Testcases, måden at teste og endda værktøjerne til at teste kan variere til tider.

Følgende er nogle punkter, der kan hjælpe dig med at strategisere din testproces:

  1. Identificer de scenarier, funktionaliteter osv., Der er mest adgang til og kan have tendens til at bryde systemet. Ligesom for en finansiel app er den mest anvendte funktionalitet at overføre penge.
  2. Identificer den belastning, som systemet kan opleve på en given dag, dvs. både maksimum og minimum.
  3. Opret en separat testplan , scenario, test case og test suite.
  4. Brug 3-4 forskellige computersystemer til test med anden hukommelse, processor osv.
  5. Bruger 3-4 forskellige browsere til webapps med forskellige versioner.
  6. Ideelt set skal du finde værdien under pausepunktet, ved pausepunktet og værdien efter pausepunktet (når systemet slet ikke reagerer), opret en testbed og data omkring disse.
  7. I tilfælde af webapps, prøv også at stresstest med et langsomt netværk.
  8. Gå ikke til slutningen af ​​testene på bare en runde eller to, udfør de samme tests i mindst 5 runder, og afslut derefter dine fund.
  9. Find den ideelle responstid på webserveren, og hvad er klokkeslættet ved brudpunktet.
  10. Find appens adfærd ved bristepunktet på forskellige punkter i appen som når du bare starter appen, logger ind, udfører noget login efter login osv.

Stresstest til mobilapps

Stresstestning af native mobilapps er lidt anderledes end for webapps. I native apps udføres en stresstest for de almindeligt anvendte skærme ved at tilføje enorme data.

Følgende er nogle verifikationer, der udføres som en del af denne test for native mobilapps:

  • Appen går ikke ned, når der vises enorme data. Ligesom for en e-mail-app, omkring 4-5 lakhs modtagne e-mail-kort, til shopping-apps, den samme mængde varekort osv.
  • Rulning er fejlfri, og appen hænger ikke, mens du ruller op eller ned.
  • Brugeren skal være i stand til at se detaljerne på et kort eller udføre en eller anden handling på kortet fra den enorme liste.
  • Sende lakhs af opdateringer fra appen til serveren som at markere en vare som 'Favorit', tilføje en vare til indkøbskurven osv.
  • Prøv at indlæse appen med enorme data på et 2G-netværk, når appen hænger eller går ned, skal den vise en passende besked.
  • Prøv et ende-til-slut-scenarie, når der er enorme data og et langsomt 2G-netværk osv.

Følgende skal være din strategi til test på mobilapps:

  1. Identificer de skærme, der har kort, billeder osv., For at målrette mod disse skærme med enorme data.
  2. Identificer ligeledes de funktionaliteter, der vil blive brugt mest almindeligt.
  3. Mens du opretter testsengen, skal du prøve at bruge mellemstore og low-end telefoner.
  4. Prøv at teste samtidigt på parallelle enheder.
  5. Undgå denne test på emulator og simulatorer.
  6. Undgå test på Wifi-forbindelser, da de er stærke.
  7. Prøv at køre mindst en stresstest ude i marken osv.

Forskellen mellem belastningstest og stresstest

S. nr.StresstestBelastningstest
enDenne test er udført for at finde ud af systemets brudpunkt.Denne test udføres for at verificere systemets ydeevne under en forventet belastning.
toDenne test udføres for at finde ud af, om systemet vil opføre sig som forventet, hvis belastningen overskrider den normale grænse.Denne test udføres for at kontrollere serverens responstid for den forventede specifikke belastning.
3Fejlhåndtering er også verificeret i denne test.Fejlhåndtering er ikke testet intenst.
4Dette kontrollerer også for sikkerhedstrusler, hukommelseslækager osv.Ingen sådan test er obligatorisk.
5Kontrollerer systemernes stabilitet.Kontrollerer systemets pålidelighed.
6Test udføres med mere end max. mulig antal brugere, anmodninger osv.Test udføres med det maksimale antal brugere, anmodninger osv.

Stresstest mod belastningstest

StessTest vs LoadTest

Eksempel på testtilfælde

De testsager, du opretter til din test, afhænger af applikationen og dens krav. Før du opretter testsagerne, skal du sørge for at kende fokusområderne, dvs. funktionaliteterne, der har tendens til at bryde under en unormal belastning.

Følgende er nogle eksempler på testtilfælde, som du kan medtage i din test:

  • Kontroller, om der vises en korrekt fejlmeddelelse, når systemet når brudpunktet, dvs. krydser det maksimale nr. af tilladte brugere eller anmodninger.
  • Kontroller ovenstående testcase for forskellige kombinationer af RAM, processor og netværk osv.
  • Kontroller, om systemet fungerer som forventet, når maksimum nr. af brugere eller anmodninger behandles. Kontroller også ovenstående testsag for forskellige kombinationer af RAM, processor og netværk osv.
  • Kontroller, at mens mere end det tilladte nr. af brugere eller anmodninger udfører den samme handling (som at købe de samme varer fra et shoppingwebsted eller foretage en pengeoverførsel osv.), og hvis systemet ikke reagerer, vises en passende fejlmeddelelse om dataene (ikke gemt? - afhænger af implementering).
  • Kontroller, om mere end det tilladte nr. af brugere eller anmodninger udfører forskellige handlinger (som en bruger logger ind, en bruger starter appen eller weblinket, en bruger vælger et produkt osv.), og hvis systemet ikke reagerer, vises en passende fejlmeddelelse om dataene (ikke gemt? - afhænger af implementeringen).
  • Kontroller, om responstiden for brydepunktsbrugere eller anmodninger er i en acceptværdi.
  • Bekræft ydeevnen for appen eller webstedet, når netværket er meget langsomt, en korrekt fejlmeddelelse skal vises i tilstanden 'timeout'.
  • Kontroller alle ovennævnte testtilfælde for en server, der har mere end en applikation, der kører for at kontrollere, om den anden applikation bliver berørt osv.

Før du udfører tests, skal du sørge for at:

  • Alle de funktionelle fejl i den testede applikation er løst og verificeret.
  • Det komplette ende-til-slut-system er klar og integrationstestet.
  • Der foretages ingen nye kodeindtjekninger, der påvirker testningen.
  • Andre hold informeres om din testplan.
  • Backup-systemer oprettes i tilfælde af alvorlige problemer.

5 bedste software til stresstest

Når stresstest udføres manuelt, er det også et meget kompliceret og kedeligt job. Det kan heller ikke give dig de forventede resultater.

Automatiseringsværktøjer kan give dig de forventede resultater, og det er relativt let at oprette den krævede testseng ved hjælp af dem. Det kan ske, at de værktøjer, du bruger til din normale funktionelle test, måske ikke er tilstrækkelige til stresstest.

Derfor er det op til dig og dit team at beslutte, om de udelukkende ønsker et separat værktøj til denne test. Det er også gavnligt for andre, at du kører suiten om natten, så deres arbejde ikke bliver hæmmet. Ved hjælp af automatiseringsværktøjer kan du planlægge, at pakken skal køre om natten, og resultaterne vil være klar til dig den næste dag.

Følgende er en liste over mest anbefalede værktøjer:

# 1) Load Runner:

LoadRunner er et værktøj designet af HP til belastningstest, men det kan også bruges til stresstest.

Det bruger VuGen dvs. Virtual User Generator til at oprette brugerne og anmodninger om belastning og stresstest. Dette værktøj har gode analyserapporter, som kan hjælpe med at tegne resultaterne i form af grafer, diagrammer osv.

# 2) Neoload:

Neoload er et betalt værktøj, der er nyttigt ved test af web- og mobilapps.

Det kan simulere mere end 1000 brugere for at kontrollere systemets ydeevne og finde svartiden på serveren. Det integreres også med Cloud til både belastning og stresstest. Det giver god skalerbarhed og er meget let at bruge.

# 3) JMeter:

JMeter er et open source-værktøj, der fungerer med JDK 5 og nyere versioner. Fokus for dette værktøj er hovedsageligt på test af webapplikationer. Det kan også bruges til test af LDAP-, FTP-, JDBC-databaseforbindelser osv.

# 4) Kværn:

Grinder er et open source og Java-baseret værktøj, der bruges til belastning og stresstest.

Parameteriseringen kan udføres dynamisk, mens testene kører. Det har god rapportering og påstande, der hjælper dig med at analysere resultaterne på en bedre måde. Den har en konsol, der kan bruges som en IDE til at oprette og redigere testene og agenter for at oprette belastningen til testformål.

hvordan man åbner torrentfiler på Android

# 5) WebLoad:

Webload værktøj har en gratis såvel som en betalt udgave. Denne gratis udgave tillader op til 50 brugeroprettelser.

Dette værktøj understøtter både web- og mobilapps stresskontrol. Den understøtter forskellige protokoller som HTTP, HTTPS, PUSH, AJAX, HTML5, SOAP osv. Den har en IDE, load generationskonsol, analysedashboard og integrationer (integreres med Jenkins, APM-værktøjer osv.).

Konklusion

Stresstest fokuserer fuldstændigt på at teste systemet under ekstreme belastningsforhold for at finde dets brudpunkt og se, om passende meddelelser vises, når systemet ikke reagerer. Det understreger hukommelsen, processoren osv. Under testen og kontrollerer, hvor godt de kommer sig.

Stresstest er en type ikke-funktionel test og udføres normalt efter funktionstesten. Når der også er krav om belastningstest, kan denne test udføres som det ekstreme tilfælde af belastningstest. 90% af tiden kan det samme automatiseringsværktøj bruges til både belastning og stresstest.

Håber du ville have fået en god indsigt i begrebet stresstest !!

Anbefalet læsning

^