Stresstesting guide for nybegynnere

stress testing guide

En omfattende stresstestguide for nybegynnere:

Å understreke alt som ligger utenfor et poeng, resulterer i alvorlige konsekvenser for mennesker, maskiner eller et program. Det forårsaker enten alvorlige skader eller ødelegger det helt.

På samme måte vil vi i denne opplæringen lære hvordan du kan stresstest webapplikasjoner sammen med effekten.

For å unngå permanent skade på appene eller nettstedene dine når de er stresset, dvs. tungt belastet, må vi finne bristepunktet og i sin tur løsningen for å unngå slike forhold. Tenk bare hvordan det ville være når shoppingnettstedet ditt går ned under julesalget. Hvor mye ville være tapet?

Nedenfor er noen eksempler på reelle tilfeller der det er veldig viktig å stresstest en app eller et nettsted:

hvordan du viser en swf-fil

#1) Kommersielle shoppingapper eller nettsteder må utføre stresstesting da belastningen blir veldig høy i festivaler, salg eller spesialtilbud.

#to) Økonomiske apper eller nettsteder må utføre stresstest ettersom belastningen øker til tider som når en selskapsandel går opp, mange logger seg på kontoene sine for å kjøpe eller selge, nettbutikker som nettsteder omdirigerer nettbankere for betaling etc.

# 3) Nett- eller e-postapper må stresstestes.

# 4) Sosiale nettverk nettsteder eller apper, blogger etc., må stresstestes etc.

Hva du vil lære:

• Hva er stresstesting og hvorfor stresstester vi?
• Strategi for stresstesting
• Stresstesting for mobilapper
• Forskjellen mellom belastningstesting og stresstesting
• Eksempel på testtilfeller
• 5 beste programvaren for stresstesting
  • # 1) Load Runner:
  • # 2) Neoload:
  • # 3) JMeter:
  • # 4) Kvern:
  • # 5) WebLoad:
• Konklusjon
• Anbefalt lesing

Hva er stresstesting og hvorfor stresstester vi?

Stresstesting er definert som prosessen med å teste maskinvaren eller programvaren for stabilitet under tung belastning. Denne testingen er gjort for å finne det numeriske punktet når systemet vil gå i stykker (når det gjelder antall brukere og serverforespørsler etc.) og den relaterte feilhåndteringen for det samme.

Under stresstesting bombes applikasjonen under test (AUT) med tung belastning i en gitt periode for å verifisere bruddpunktet og for å se hvor godt feilhåndtering gjøres.

Eksempel: MS Word kan gi en feilmelding 'Ikke svarer' når du prøver å kopiere en 7-8 GB fil.

Du har bombardert Word med en enorm fil, og den kunne ikke behandle en så stor fil, og som et resultat blir den hengt. Vi dreper normalt apper fra Oppgavebehandling når de slutter å svare, årsaken bak det er at appene blir stresset og slutter å svare.

Følgende er noen tekniske årsaker til å utføre stresstesting:

• For å verifisere systemets oppførsel under unormal eller ekstrem belastning.
• For å finne den numeriske verdien til brukere, forespørsler etc., hvoretter systemet kan gå i stykker.
• Håndter feilen nådig ved å vise passende meldinger.
• Å være godt forberedt på slike forhold og ta forholdsregler som kode rengjøring, DB rengjøring, etc.
• For å verifisere datahåndtering før systemet går i stykker, dvs. for å se om data ble slettet, lagret eller ikke etc.
• For å verifisere sikkerhetstrussel under slike bruddforhold etc.

Strategi for stresstesting

Dette er en type ikke-funksjonell testing, og denne testingen gjøres vanligvis når funksjonstesten av et nettsted eller en app er fullført. Testtilfellene, måten å teste og til og med verktøyene for å teste kan variere til tider.

Følgende er noen tips som kan hjelpe deg med å strategisere testprosessen:

1. Identifiser scenarier, funksjoner osv. Som er mest tilgjengelig og kan ha en tendens til å bryte systemet. Som for en økonomisk app, er den mest brukte funksjonaliteten å overføre penger.
2. Identifiser belastningen som systemet kan oppleve på en gitt dag, dvs. både maksimum og minimum.
3. Lag et eget testplan , scenario, test case og test suite.
4. Bruk 3-4 forskjellige datasystemer for testing med forskjellig minne, prosessor etc.
5. Bruker 3-4 forskjellige nettlesere for nettapper med forskjellige versjoner.
6. Ideelt sett, finn verdien under brytpunktet, ved brytpunktet og verdien etter brytpunktet (når systemet ikke vil svare i det hele tatt), lag en testleie og data rundt disse.
7. I tilfelle av webapper, prøv å stresstest med et tregt nettverk også.
8. Ikke hopp til slutten av testene på bare en runde eller to, utfør de samme testene i minst 5 runder, og avslutt deretter funnene dine.
9. Finn den ideelle responstiden til webserveren, og hva som er klokkeslettet er i bruddpunktet.
10. Finn appens oppførsel ved bristepunktet på forskjellige punkter i appen, som når du bare starter appen, logger på, utfører noe påloggingsinnlegg osv.

Stresstesting for mobilapper

Stresstesting for innfødte mobilapper er litt annerledes enn for nettapper. I native apps utføres en stresstest for de ofte brukte skjermene ved å legge til enorme data.

Følgende er noen bekreftelser som gjøres som en del av denne testen for innfødte mobilapper:

• Appen krasjer ikke når enorme data vises. Som for en e-postapp, rundt 4-5 lakh mottatte e-postkort, for shoppingapper, samme mengde varekort etc.
• Rulling er feilfritt, og appen henger ikke mens du ruller opp eller ned.
• Brukeren skal kunne se detaljene på et kort eller utføre noen handlinger på kortet fra den enorme listen.
• Sende lakhs med oppdateringer fra appen til serveren, for eksempel å merke en vare som ‘Favoritt’, legge til en vare i handlekurven osv.
• Prøv å laste appen med enorme data på et 2G-nettverk. Når appen henger eller krasjer, bør den vise en passende melding.
• Prøv et slutt-til-slutt-scenario når det er enorme data og et tregt 2G-nettverk etc.

Følgende bør være din strategi for testing på mobilapper:

1. Identifiser skjermene som har kort, bilder osv. For å målrette skjermene med enorme data.
2. På samme måte, identifiser funksjonalitetene som vil bli brukt mest.
3. Mens du oppretter testsengen, kan du prøve å bruke mellomstore og lave telefoner.
4. Prøv å teste samtidig på parallelle enheter.
5. Unngå denne testen på emulator og simulatorer.
6. Unngå testing på Wifi-tilkoblinger da de er sterke.
7. Prøv å kjøre minst en stresstest ute i felt osv.

Forskjellen mellom belastningstesting og stresstesting

Stresstesting mot belastningstesting

Eksempel på testtilfeller

Testtilfellene du vil lage for testingen din, vil avhenge av applikasjonen og dens krav. Før du oppretter testtilfellene, må du sørge for at du kjenner til fokusområdene, dvs. funksjonalitetene som har en tendens til å bryte under en unormal belastning.

Følgende er noen eksempler på testtilfeller som du kan inkludere i testingen:

• Kontroller om det vises en riktig feilmelding når systemet når brytpunktet, dvs. krysser maks. av tillatte brukere eller forespørsler.
• Sjekk ovennevnte testtilfelle for forskjellige kombinasjoner av RAM, prosessor og nettverk etc.
• Kontroller om systemet fungerer som forventet når maks. av brukere eller forespørsler behandles. Sjekk også testtilfellet ovenfor for forskjellige kombinasjoner av RAM, prosessor og nettverk etc.
• Bekreft at mens mer enn tillatt nr. av brukere eller forespørsler utfører den samme operasjonen (som å kjøpe de samme varene fra et shoppingnettsted eller foreta en pengeoverføring osv.), og hvis systemet ikke svarer, vises en passende feilmelding om dataene (ikke lagret? - avhenger av gjennomføring).
• Sjekk om mer enn tillatt nr. av brukere eller forespørsler utfører forskjellige operasjoner (som en bruker logger på, en bruker starter appen eller nettkoblingen, en bruker velger et produkt osv.), og hvis systemet ikke svarer, vises en passende feilmelding om dataene (ikke lagret? - avhenger av implementeringen).
• Bekreft om responstiden for brytpunktbrukere eller forespørsler har en akseptverdi.
• Bekreft ytelsen til appen eller nettstedet når nettverket er veldig tregt, en riktig feilmelding skal vises for 'timeout' -tilstand.
• Bekreft alle ovennevnte testtilfeller for en server som har mer enn ett program som kjører for å sjekke om det andre programmet blir berørt osv.

Før du utfører tester, må du sørge for at:

• Alle funksjonelle feil i applikasjonen som testes er løst og bekreftet.
• Hele end-to-end-systemet er klart og integrasjonstestet.
• Ingen nye kodeinnsjekk som vil påvirke testingen er utført.
• Andre lag blir informert om testplanen din.
• Sikkerhetskopieringssystemer opprettes i tilfelle noen alvorlige problemer.

5 beste programvaren for stresstesting

Når stresstesting utføres manuelt, er det også en veldig komplisert og kjedelig jobb. Det kan heller ikke gi deg de forventede resultatene.

Automatiseringsverktøy kan gi deg de forventede resultatene, og det er relativt enkelt å lage den nødvendige testsengen ved hjelp av dem. Det kan hende at verktøyene du bruker til din normale funksjonstesting, kanskje ikke er tilstrekkelig for stresstesting.

Derfor er det for deg og teamet ditt å bestemme om de vil ha et eget verktøy eksklusivt for denne testen. Det er også gunstig for andre at du driver suiten om natten, slik at arbeidet deres ikke blir hindret. Ved hjelp av automatiseringsverktøy kan du planlegge at suiten skal kjøre om natten, og resultatene vil være klare for deg neste dag.

Følgende er en liste over mest anbefalte verktøy:

selen webdriver intervju spørsmål og svar

# 1) Load Runner:

LoadRunner er et verktøy designet av HP for belastningstesting, men det kan også brukes til stresstester.

Den bruker VuGen dvs. Virtual User Generator for å opprette brukere og forespørsler om belastning og stresstesting. Dette verktøyet har gode analyserapporter som kan bidra til å tegne resultatene i form av grafer, diagrammer etc.

# 2) Neoload:

Neoload er et betalt verktøy som er nyttig for å teste nett- og mobilapper.

Det kan simulere mer enn 1000 brukere for å verifisere ytelsen til systemet og finne responstiden til serveren. Den integreres også med Cloud for både belastning og stresstesting. Det gir god skalerbarhet og er veldig enkelt å bruke.

# 3) JMeter:

JMeter er et open source-verktøy som fungerer med JDK 5 og nyere versjoner. Fokuset for dette verktøyet er for det meste på testing av webapplikasjoner. Den kan også brukes til å teste LDAP-, FTP-, JDBC-databaseforbindelser osv.

# 4) Kvern:

Grinder er et åpen kildekode og Java-basert verktøy som brukes til belastning og stresstesting.

Parameteriseringen kan gjøres dynamisk mens testene kjører. Den har god rapportering og påstander som hjelper deg med å analysere resultatene på en bedre måte. Den har en konsoll som kan brukes som IDE for å opprette og redigere testene og agenter for å skape belastningen for testformål.

# 5) WebLoad:

Webload verktøyet har både en gratis og en betalt utgave. Denne gratis utgaven tillater opptil 50 brukeropprettelser.

Dette verktøyet støtter både nettkontroll og mobilapps stresskontroll. Den støtter forskjellige protokoller som HTTP, HTTPS, PUSH, AJAX, HTML5, SOAP osv. Den har en IDE, lastgenereringskonsoll, analysedashboard og integrasjoner (for å integrere med Jenkins, APM-verktøy osv.).

Konklusjon

Stresstesting fokuserer fullstendig på å teste systemet under ekstreme belastningsforhold for å finne bruddpunktet og se om passende meldinger vises når systemet ikke reagerer. Det understreker minnet, prosessoren osv under testingen og sjekker hvor godt de kommer seg.

Stresstesting er en type ikke-funksjonell testing og gjøres vanligvis etter funksjonstesting. Når det også er krav om belastningstesting, kan denne testingen gjøres som det ekstreme tilfellet med belastningstesting. 90% av tiden kan det samme automatiseringsverktøyet brukes til både belastning og stresstesting.

Håper du ville ha fått et godt innblikk i begrepet stresstesting !!

Anbefalt lesing

• Lastetesting med HP LoadRunner-veiledninger
• Ytelsestesting vs belastningstesting vs stresstesting (forskjell)
• Lastetesting komplett guide for nybegynnere
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Alpha Testing og Beta Testing (En komplett guide)
• Nybegynnerveiledning for penetreringstesting av webapplikasjoner
• Nettapplikasjonsbelastning, stress og ytelsestesting ved bruk av WAPT
• Funksjonstesting mot ikke-funksjonell testing