I denne delen vil vi lære om ytelsestesting, hvorfor vi trenger det, typer ytelsestesting og ytelsestestingsprosessen.

Følgende er emnene som vi vil forstå i denne delen:

Hva er ytelsestesting?

Det er den viktigste delen av ikke-funksjonell testing.

Å sjekke oppførselen til en applikasjon ved å bruke en viss belastning er kjent som ytelsestesting.

Generelt sett definerer denne testen hvor raskt serveren svarer på brukerens forespørsel.

Mens vi utfører ytelsestesting av applikasjonen, vil vi konsentrere oss om de ulike faktorene som Responstid, belastning og stabilitet av søknaden.

Responstid: Responstid er tiden det tar for serveren å svare på klientens forespørsel.

Laste: Her betyr Load at når N-nummer av brukere som bruker applikasjonen samtidig eller sender forespørselen til serveren om gangen.

Stabilitet: For stabilitetsfaktoren kan vi si at når N-antall brukere bruker applikasjonen samtidig for en bestemt tid.

Når bruker vi ytelsestesting?

Vi vil utføre ytelsestesting når programvaren er stabil og flyttet til produksjonen, og den kan nås av flere brukere samtidig, av denne grunn kan det oppstå noen ytelsesproblemer. For å unngå disse ytelsesproblemene, utfører testeren én runde med ytelsestesting.

Siden det er ikke-funksjonell testing som ikke betyr at vi alltid bruker ytelsestesting, går vi kun til ytelsestesting når applikasjonen er funksjonelt stabil.

Merk: Ytelsestesting kan ikke utføres manuelt siden det kostbare og nøyaktige resultatet ikke kan opprettholdes.

Typer ytelsestesting

Følgende er typene ytelsestesting:

iskcon full form

Lasttesting Stresstesting Skalerbarhetstesting Stabilitetstesting

La oss diskutere en etter en for å gi deg en fullstendig forståelse av Belastning, stress, skalerbarhet, og Stabilitet ytelsestesting.

Lasttesting

Lasttestingen brukes til å kontrollere ytelsen til en applikasjon ved å påføre en belastning som enten er mindre enn eller lik den ønskede belastningen, kjent som belastningstesting.

For eksempel: På bildet nedenfor, 1000 brukere er de ønsket belastning , som er gitt av kunden, og 3/sekund er den mål som vi ønsker å oppnå mens vi utfører en lasttesting.

Stresstesting

Stresstestingen er testing, som sjekker oppførselen til en applikasjon ved å påføre belastning større enn ønsket belastning.

For eksempel: Hvis vi tok eksemplet ovenfor og økte ønsket belastning 1000 til 1100 brukere, og målet er 4/sekund. Mens du utfører stresstestingen i dette scenariet, vil den bestå fordi belastningen er større (100 opp) enn den faktiske ønskede belastningen.

Skalerbarhetstesting

Å kontrollere ytelsen til en applikasjon ved å øke eller redusere belastningen på bestemte vekter (ingen bruker) er kjent som skalerbarhetstesting . Skalerbarhetstesting oppover og nedadgående skalerbarhet kalles skalerbarhetstesting.

Skalerbarhetstesting er delt inn i to deler som er som følger:

Skalerbarhetstesting oppover Skalerbarhetstesting nedover

Skalerbarhetstesting oppover

Det tester hvor vi øke antall brukere på en bestemt skala til vi får et krasjpunkt. Vi vil bruke skalerbarhetstesting for å finne den maksimale kapasiteten til en applikasjon.

Skalerbarhetstesting nedover

Skalerbarhetstestingen nedover brukes når lasttestingen ikke er bestått, og start deretter redusere antall. av brukere i et bestemt intervall til målet er nådd. Slik at det er lett å identifisere flaskehalsen (feilen).

Stabilitetstesting

Kontrollere ytelsen til en applikasjon ved å å påføre belastningen i en bestemt tidsperiode er kjent som Stabilitetstesting .

Eksempel på ytelsestesting

La oss ta ett eksempel hvor vi vil test oppførselen til en applikasjon der ønsket belastning enten er mindre enn 1000 eller lik 1000 brukere .

På bildet nedenfor kan vi se at 100 opp brukere økes kontinuerlig for å sjekke maksimal belastning , som også kalles skalerbarhetstesting oppover .

jpa om våren

Scenario 1:Når vi har de 1000 brukerne som ønsket belastning, og 2,7/sek er måltid, vil disse scenariene passere mens vi utfører belastningstesten fordi i belastningstesting vil vi konsentrere oss om nr. antall brukere, og i henhold til kravet er det lik 1000 brukere.Scenario 2:I neste scenario øker vi ønsket belastning med 100 brukere, og måltiden vil gå opp til 3,5sek. Dette scenariet vil passere hvis vi utfører stresstesting fordi her er den faktiske belastningen større enn (1100) ønsket belastning (1000).Scenario 3:I dette, hvis vi øker ønsket belastning tre ganger som
1200 → 3,5sek: [den er ikke mindre enn eller lik ønsket belastning, det er derfor den vil Mislykket ]
1300 → 4sek: [den er ikke mindre enn eller lik ønsket belastning. dvs., Mislykket ]
1400 → Krasjet

Merknad 1: Volum- og bløtleggingstesting er en type testing, men ikke ytelsestesting.

Volumtesting

Volumtesting er testing, som hjelper oss å sjekke oppførselen til en applikasjon ved å sette inn et massivt volum av belastningen når det gjelder data er kjent som volumtesting, og her vil vi konsentrere oss om antall datahastigheter enn antall brukere .

Notat 2:
Volum er en kapasitet mens Load er en mengde, dvs. lasttesting betyr nei. av brukere, og volumtesting betyr mengde data.

Soak testing

I denne typen testing vil vi sjekke oppførselen til en applikasjon på miljøet, som ikke er støttende i lang tid, kalles bløtleggingstesting.

Vanligvis er soak-testing en negativ type testing siden vi allerede vet at serveren eller miljøet ikke støtter.

Ytelsestestingsprosess

Ytelsestestingen kan ikke gjøres manuelt siden:

• Vi trenger mye ressurser, og det ble en dyrere tilnærming.
• Og nøyaktigheten kan ikke opprettholdes når vi sporer responstid manuelt.

Ytelsestestingsprosessen vil bli fullført i følgende trinn:

• Identifiser ytelsesscenarier
• Planlegg og design ytelsestestskript
• Konfigurer testmiljøet og fordel belastningen
• Utfør testskript
• Resultat
• Analyseresultat
• Identifiser flaskehalsen
• Kjør testen på nytt

Hvis vi utfører en positiv flyt av ytelsestestingsprosessen, kan den følge prosessen nedenfor:

Identifiser ytelsesscenarier

Først vil vi identifisere ytelsesscenarioene basert på disse faktorene nedenfor:

Vanligste scenarier: Det betyr at vi kan finne ytelsesscenariene basert på scenariene, som vanligvis brukes som i Gmail-applikasjon; vi skal opptre logg inn, innboks, send elementer og skriv en e-post og logg ut .

Mest kritiske scenarier: Kritiske scenarier betyr regelmessig brukt og viktig for den forretningsmessige i Gmail-applikasjonen logg inn, skriv, innboks og utlogging .

Enorme datatransaksjoner: Hvis vi har store data betyr at n-antall brukere som bruker applikasjonen samtidig.

Når vi har identifisert ytelsesscenarioene, går vi til neste trinn.

Planlegg og design ytelsestestskript

I dette trinnet vil vi installere verktøyene i Test Engineer Machine og få tilgang til testserveren, og så skriver vi noe skript i henhold til testscenarioene og kjører verktøyet.

Når vi er ferdige med å skrive manuset, går vi til neste trinn.

Konfigurer testmiljøet og fordel belastningen

Etter å ha skrevet testskriptene vil vi ordne testmiljøet før utførelse. Og administrer også verktøyene, andre ressurser og fordel belastningen i henhold til 'Bruksmønsteret' eller nevne varigheten og stabiliteten.

Utfør testskript

Når vi er ferdige med å distribuere lasten, vil vi kjøre, validere og overvåke testskriptene.

Resultat

Etter å ha utført testskriptene vil vi få testresultatet. Og sjekk at resultatet oppfyller målet i den gitte responstiden eller ikke, og at responstiden kan være maksimum, gjennomsnitt og minimum.

Hvis svaret ikke oppfyller det påkrevde tidssvaret, vil vi gå for negativ strømning hvor utfører trinnene nedenfor:

Analyseresultat

Først vil vi analysere testresultatet om det møter responstiden eller ikke.

fibonacci-serien i java

Identifiser flaskehalsen

Etter det vil vi identifisere flaskehals (feil eller ytelsesproblem ). Og flaskehalsen kan oppstå på grunn av disse aspektene som problem med kode, maskinvareproblem (harddisk, RAM-prosessor), nettverksproblemer, og programvareproblem (operativsystem) . Og etter å ha funnet flaskehalsen skal vi prestere tuning (fiks eller justering) for å løse denne flaskehalsen.

Kjør testen på nytt

Når vi har fikset flaskehalsene, kjører du testskriptene på nytt og sjekker resultatet om det oppfyller det nødvendige målet eller ikke.

Problemet oppstår i ytelsestesting

Mens du utfører ytelsestesting på applikasjonen, kan det oppstå noen problemer, og disse problemene kalles også ytelsesproblem .

Ytelsesproblemene er som følger:

Problem med responstid Problem med skalerbarhet Flaskehals Hastighetsproblem

Problem med responstid

Svartiden betyr hvor raskt serveren svarer på klientens forespørsel. Hvis brukerens forespørsel ikke fullføres innen den gitte responstiden, kan det være mulig at brukeren mister interessen for den aktuelle programvaren eller applikasjonen. Det er derfor applikasjonen eller programvaren bør ha en perfekt responstid for å svare raskt på brukerens forespørsel.

Problem med skalerbarhet

Skalerbarhetsproblemene oppstår når applikasjonen ikke kan ta n-tall brukere og forventede brukerforespørsler på samme tid. Det er derfor vi vil gjøre det skalerbarhetstesting oppover (sjekk applikasjonens maksimale kapasitet) og skalerbarhetstesting nedover (når forventet tid ikke samsvarer med faktisk tid).

Flaskehals

Flaskehalsen er det uformelle navnet på feilen, som oppstår når applikasjonen er begrenset av en enkelt komponent og skaper en dårlig innvirkning på systemytelsen.

Hovedårsakene til flaskehals er programvareproblemer (problem relatert til operativsystemet), maskinvareproblemer (problemer knyttet til harddisken, RAM og prosessoren), og kodingsproblem, etc.

Følgende er de vanligste ytelsesflaskehalsene:

• Minneutnyttelse
• Diskbruk
• CPU-utnyttelse
• Operativsystembegrensninger
• Nettverksutnyttelse

Hastighetsproblemer

Når vi utfører ytelsestesting på applikasjonen, bør applikasjonen være raskere i hastighet for å få brukerens interesse og oppmerksomhet fordi hvis applikasjonens hastighet er lav, kan den miste brukerinteressen for applikasjonen.

Ytelsestestverktøy

Vi har ulike typer ytelsestestverktøy tilgjengelig i markedet, hvor noen er kommersielle verktøy og åpen kildekode-verktøy.

Kommersielle verktøy: LoadRunner[HP], WebLOAD, NeoLoad

Åpen kildekode-verktøy: JMeter

er lik streng i java

LoadRunner

Det er et av de kraftigste verktøyene for ytelsestesting, som brukes til å støtte ytelsestestingen for det omfattende spekteret av protokoller, antall teknologier og applikasjonsmiljøer.

Den identifiserer raskt de vanligste årsakene til ytelsesproblemer. Og forutsi også applikasjonens skalerbarhet og kapasitet nøyaktig.

JMeter

Apache JMeter-programvaren er et åpen kildekodeverktøy, som er en fullstendig Java-applikasjon designet for å laste den funksjonelle testatferden og måle ytelsen.

Generelt ble den designet for å teste webapplikasjonene, men nå utvidet til andre testfunksjoner også.

Apache JMeter brukes til å teste ytelse for både statiske og dynamiske ressurser og dynamiske webapplikasjoner.
Den kan brukes til å reprodusere den tunge belastningen på en server, nettverk eller objekt, gruppe servere for å teste styrken eller analysere den generelle ytelsen under forskjellige belastningstyper.

WebLOAD

WebLOAD testverktøy som brukes til å teste belastningstesting, ytelsestesting og stresstest webapplikasjoner.

WebLOAD-verktøyet kombinerer ytelse, skalerbarhet og integritet som en enkelt prosess for verifisering av nett- og mobilapplikasjoner.

NeoLoad

Neotys utvikler et testverktøy som kalles NeoLoad. NeoLoad brukes til å teste scenariene for ytelsestest. Ved hjelp av NeoLoad kan vi finne flaskehalsområdene på nettet og utviklingsprosessen for mobilapper.

NeoLoad-testverktøyet er raskere sammenlignet med tradisjonelle verktøy.

Bortsett fra dem er det noen andre verktøy Elektrisk belastning, nettstressverktøy, LoadUI Pro, StresStimulus, LoadView, LoadNinja og RedLine13, som hjelper til med å teste ytelsen til programvaren eller en applikasjon.