performance testing vs load testing vs stress testing
Forskellen mellem ydelsestest, belastningstest og stresstest - med eksempler
Vores tidligere tutorial i denne serie vil være den bedste Guide til præstationstest for enhver nybegynder.
I softwaretestfeltet støder vi på udtryk som præstationstest, belastningstest, stresstest osv. Disse udtryk misforstås ofte og fortolkes som de samme begreber.
Der er dog en signifikant forskel mellem disse tre testtyper, og det er vigtigt for en tester at forstå det samme.
=> Klik her for at få komplette præstationsprøvetutorials-serier
I denne vejledning vil vi diskutere hver af disse testtyper for at forstå de nøjagtige forskelle mellem dem.
Hvad du vil lære:
Forskellen mellem ydelsestest, belastningstest og stresstest
# 1) Test af ydeevne
Hvad er ydelsestest?
Ydelsestest er den test, der udføres for at fastslå, hvordan komponenterne i et system fungerer under en bestemt given situation.
Ressourceforbrug, skalerbarhed og pålidelighed af produktet valideres også under denne test. Denne testning er delmængden af performance engineering, som er fokuseret på at løse ydelsesproblemer i design og arkitektur af et softwareprodukt.
Ovenstående billede forklarer os klart det Performance Testing er superset til både belastning og stresstest. Andre typer af test inkluderet i præstationstest er Spike-test, Volumenprøvning, Udholdenhedstest og Test af skalerbarhed . Således er præstationstestning dybest set en meget bred sigt.
Mål for præstationstest:
Det primære mål med præstationstest inkluderer etablering af systemets benchmarkadfærd. Der er en række branchedefinerede benchmarks, der skal opfyldes under præstationstest.
Performance test har ikke til formål at finde mangler i applikationen. Det består heller ikke eller ikke bestå testen. Snarere adresserer den den kritiske opgave at indstille benchmark og standard for en applikation . Ydelsestest skal udføres meget nøjagtigt. Tæt overvågning af applikationens / systemets ydeevne er det primære kendetegn ved ydelsestest.
Benchmark og standard for applikationen skal indstilles med hensyn til attributter som hastighed, responstid, kapacitet, ressourceforbrug og stabilitet. Alle disse attributter testes i en præstationstest.
For eksempel,
For eksempel kan du teste applikationsnetværksydelsen gennem diagrammet 'Forbindelseshastighed vs. forsinkelse'. Latency er tidsforskellen mellem de data, der skal nås fra kilden til destinationen.
En side på 70 kb ville ikke tage mere end 15 sekunder at indlæse for den værste forbindelse på 28,8 kbps modem (latenstid = 1000 millisekunder), mens siden af samme størrelse ville vises inden for 5 sekunder for den gennemsnitlige forbindelse på 256 kbps DSL (latenstid = 100 millisekunder).
En T1-forbindelse på 1,5 Mbps (latens = 50 millisekunder) ville have præstationsbenchmark sat til 1 sekund for at nå dette mål.
En anden eksempel ville være en anmodnings-svarmodel. Vi kan sætte et benchmark for, at tidsforskellen mellem generering af anmodning og bekræftelse af svar skal være i området x ms (millisekunder) og y ms, hvor x og y er standardcifrene.
En vellykket ydelsestest skulle projicere de fleste af ydeevneproblemerne, som kunne være relateret til database, netværk, software, hardware osv.
# 2) Load Testing
Belastningstestning er beregnet til at teste systemet ved konstant og støt at øge belastningen på systemet, indtil det når tærskelgrænsen. Det er en delmængde af ydelsestest.
Belastningstest kan let udføres ved at anvende et hvilket som helst af de passende automatiseringsværktøjer, der er tilgængelige på markedet. WAPT og LoadRunner er to sådanne berømte værktøjer, der hjælper med belastningstest. Belastningstest er også berømt af navne som Volumen test og Udholdenhedstest .
Volumetest fokuserer dog primært på databaser. Udholdenhedstest tester systemet ved at holde det under en betydelig belastning i en vedvarende periode.
Det eneste formål med belastningstestning er at tildele systemet det største job, det muligvis kan håndtere for at teste systemets udholdenhed og overvåge resultaterne. En interessant kendsgerning her er, at systemet undertiden får en tom opgave for at bestemme systemets opførsel i nul-belastningssituationen.
De attributter, der overvåges i en belastningstest, inkluderer topydelse, servergennemstrømning, responstid under forskellige belastningsniveauer (under grænseværdien for pause), tilstrækkelighed af H / W-miljø, hvor mange brugerapplikationer den kan håndtere uden at påvirke ydeevnen.
Belastningstestmål:
Målet med belastningstest inkluderer:
- Eksponering af manglerne i et program relateret til bufferoverløb, hukommelseslækage og misadministration af hukommelsen. De problemer, der i sidste ende ville komme ud som et resultat af belastningstest, kan omfatte problemer med afbalancering af belastning, problemer med båndbredde, kapaciteten i det eksisterende system osv.
- At bestemme den øvre grænse for alle komponenter i en applikation som en database, hardware, netværk osv., Så applikationen kan styre den forventede belastning i fremtiden.
- For at indstille SLA'er til applikationen.
For eksempel,
Lad os overveje at kontrollere e-mail-funktionaliteten i en applikation, der kan blive oversvømmet med 1000 brugere ad gangen. Nu kan 1000 brugere afskedige e-mail-transaktionerne (læse, sende, slette, videresende, svare) på mange forskellige måder.
Hvis vi tager en transaktion pr. Bruger pr. Time, ville det være 1000 transaktioner pr. Time. Ved at simulere 10 transaktioner / brugere kunne vi indlæse test e-mail-serveren ved at besætte den med 10000 transaktioner / time.
Et andet eksempel på en belastningstest er vist i nedenstående billede:
Ovenstående billede viser en belastningstest udført i det kaldte værktøj JMeter . Denne test udføres for at identificere, hvor mange brugere et system kan håndtere. I denne test tilføjes 100 brugere efter hvert 30. sekund, indtil belastningen når 1000 brugere. Hvert trin tager 30 sekunder at fuldføre, og JMeter venter i 30 sekunder, inden det næste trin startes.
Når belastningen når 1000 tråde, vil de alle fortsætte med at køre i 300 sekunder (5 minutter) sammen og stopper endelig 10 tråde hvert 3. sekund.
# 3) Stresstest
Under stresstest udføres forskellige aktiviteter for at overbelaste de eksisterende ressourcer med overskydende job i et forsøg på at nedbryde systemet. Negativ test , som inkluderer fjernelse af komponenterne fra systemet, udføres også som en del af stresstest.
Også kendt som træthedstest , denne test skal fange en applikations stabilitet ved at teste den ud over dens båndbreddekapacitet.
Grundlæggende vurderer stresstest således en applikations opførsel ud over spidsbelastning og normale forhold.
Formålet med stresstest er at fastslå systemets fejl og overvåge, hvordan systemet genopretter yndefuldt. Udfordringen her er at oprette et kontrolleret miljø, før testen startes, så du nøjagtigt kan registrere systemets opførsel gentagne gange under de mest uforudsigelige scenarier.
De problemer, der til sidst ville komme ud som et resultat af stresstest, kan omfatte synkroniseringsproblemer, hukommelseslækage, løbsvilkår osv. Hvis stresstesten kontrollerer, hvordan systemet opfører sig i situationen med en pludselig opstart i antallet af brugere , så kaldes det en spids test.
Hvis stresstesten er at kontrollere systemets bæredygtighed over en periode gennem langsom opstart i antallet af brugere, kaldes det som en gennemblødningstest.
Stresstestmål:
Målet med stresstest er at analysere rapporter efter nedbrud for at definere applikationens opførsel efter fiasko.
Den største udfordring er at sikre, at systemet ikke kompromitterer sikkerheden af følsomme data efter fejlen. I en vellykket stresstest vil systemet vende tilbage til normalitet sammen med alle dets komponenter, selv efter den mest forfærdelige sammenbrud.
For eksempel,
Som et eksempel bruges en tekstbehandler som Writer1.1.0 af OpenOffice.org til udvikling af bogstaver, præsentationer, regneark osv. Formålet med vores stresstest er at indlæse det med overskydende tegn.
For at gøre dette indsætter vi gentagne gange en datalinie, indtil den når sin tærskelgrænse for håndtering af et stort tekstvolumen. Så snart tegnstørrelsen når 65.535 tegn, nægter den simpelthen at acceptere flere data.
Resultatet af stresstest på Writer 1.1.0 giver det resultat, at det ikke går ned under stresset, og det håndterer situationen yndefuldt, hvilket sørger for, at applikationen fungerer korrekt, selv under strenge stressforhold.
Et andet eksempel på en belastningstest, der viser en spidsprøve gennem pludselig opstart af 7000 brugere, er vist nedenfor:
Ofte stillede spørgsmål
Efter at have haft nok diskussioner om præstationstest, stresstest og belastningstest, lad os nu se på nogle relaterede hyppige spørgsmål, som testere søger svar på.
Spørgsmål nr. 1) Er belastningstestning og ydelsestestning den samme?
Svar: Svaret på dette er 'Nej'. De er ikke de samme.
Nu skal du have forstået forskellen mellem ydelsestest og belastningstest. Du kan henvise til tabeloversigten nedenfor for at se, hvordan ydeevne- og belastningstest har forskellige mål, omfangsattributter til undersøgelse og problemer, der skal afdækkes.
Q # 2) Er det en uretfærdig test at udføre stresstest på samme tid, når du udfører belastningstest?
Svar: Dette er også et almindeligt spørgsmål i mange softwaretestinterviews og certificeringseksaminer, da det er uretfærdigt at udføre stresstest og belastningstest parallelt? Svaret på dette er 'Nej'. Det er ikke uretfærdigt at udføre stresstest på samme tid, når du laver belastningstest.
Ingen test er nogensinde uretfærdig. Som tester er dit arbejde at finde problemer. Realiteten af softwaretest kan dog gælde, og ethvert problem, du opdager i denne situation, er muligvis ikke rettet.
Q # 3) Er Recovery-test en del af Performance-test?
Svar: Ja, restitutionstest er kategoriseret under performance-test, og til tider udføres det også med belastningstest. I restitutionstest , det åbnes som hvor godt et program er i stand til at gendanne efter fejl, nedbrud, hardwarefejl og andre lignende problemer.
I denne aktivitet er softwaren tvunget til at mislykkes, og derefter verificeres den, om den er i stand til at gendanne ordentligt. For eksempel, genstart af systemet pludselig, når et program kører og derefter verificering af dataintegriteten for applikationen.
Q # 4) Kræver ydelsestest kodning?
Svar: Ydelsestest kræver ikke, at du kender det avancerede niveau for kodning. At have en grundlæggende viden om programmering er dog en ekstra fordel.
For eksempel, hvis du bruger JMeter, så er det godt for dig at kende de grundlæggende i Java. Det kan hjælpe dig med at debugge bestemte ting, og du kan også skrive dit eget script, hvis det kræves.
Q # 5) Hvad er Spike-test i Performance Test?
Svar: Ved spidstest øges eller formindskes belastningen pludseligt af et stort antal brugere, og senere observeres systemadfærden. Spids-test udføres hovedsageligt for at kontrollere, om systemet er i stand til at håndtere pludselige ændringer i belastningen.
Forskellen mellem belastning og stresstest
For at opsummere, lad os observere de store forskelle mellem belastningstest, stresstest samt ydelsestest i nedenstående tabel:
| Test af ydeevne | Belastningstest | Stresstest | |
|---|---|---|---|
| Domæne | Supersæt af belastning og stresstest | En delmængde af ydelsestest. | En delmængde af ydelsestest. |
| Anvendelsesområde | Meget bredt anvendelsesområde. Inkluderer - belastningstest, stresstest, kapacitetstest, volumenprøvning, udholdenhedstest, spidsprøvning, skalerbarhedstest og pålidelighedstest osv. | Smalere omfang sammenlignet med præstationstest. Inkluderer volumintest og udholdenhedstest. | Smalere omfang sammenlignet med præstationstest. Inkluderer blødprøvning og spidsprøvning. |
| Stort mål | At indstille benchmark og standarder for applikationen. | For at identificere systemets øvre grænse skal du indstille appens SLA og se, hvordan systemet håndterer store belastningsvolumener. | At identificere, hvordan systemet opfører sig under intense belastninger, og hvordan det genopretter efter fejl. Dybest set for at forberede din app til den uventede trafikstigning. |
| Belastningsgrænse | Både - under og over tærsklen til en pause. | Indtil tærsklen til pause | Over tærsklen til pause |
| Attributter undersøgt | Ressourceforbrug, pålidelighed, skalerbarhed, ressourceforbrug, responstid, kapacitet, hastighed osv. | peak performance, servergennemstrømning, responstid under forskellige belastningsniveauer (under pausetærsklen), tilstrækkelighed af H / W-miljø, antallet af brugerapp, der kan håndtere, belastningsafbalanceringskrav osv. | Stabilitet ud over båndbreddekapacitet, responstid (over tærsklen for pause), etc. |
| Problemer identificeret gennem denne testtype | Alle ydeevne bugs inklusive runtime bloat, muligheden for optimering, problemer relateret til hastighed, latenstid, kapacitet osv. Dybest set - alt hvad der vedrører ydeevne! | Problemer med belastningsbalancering, båndbreddeproblemer, problemer med systemkapacitet, dårlig responstid, gennemstrømningsproblemer osv. | Sikkerhedsmangler med overbelastning, problemer med datakorruption ved overbelastningssituation, langsommelighed, hukommelseslækager osv. |
Forskellen mellem belastning, stress og volumenprøvning
Nu ved vi allerede om belastning og stresstest sammen med forskellene mellem de to. Lad os nu undersøge, hvad der er volumenprøvning, og hvordan adskiller det sig fra belastningstest og stresstest.
Volumenprøvning er også en slags præstationstest, der hovedsageligt fokuserer på databasen.
bedste virtualiseringssoftware til Windows 10
Ved volumintest kontrolleres det, hvordan systemet opfører sig mod en bestemt datamængde. Således er databaser fyldt med deres maksimale kapacitet, og deres præstationsniveauer som responstid og servergennemstrømning overvåges.
For at holde det meget simpelt vises forskellen mellem belastning, stress og volumenprøvning nedenfor:
| Volumen test | Belastningstest | Stresstest |
|---|---|---|
| En enorm mængde data | Et stort antal brugere | For mange brugere, for meget data, mod systemnedbrud. |
Konklusion
I denne vejledning har vi set og forstået gennem eksempler på, hvordan ydelsestest, belastningstest & stresstest er forskellige fra hinanden, og hvad der er omfanget af hver testtype.
Vi kiggede også kort på mange kategorier under præstationstest som spids-test, opsvingstest, volumintest osv. Og forstod, hvordan hver af disse er forskellige fra hinanden.
Vi håber, at denne vejledning ville have været til enorm hjælp for dig at forstå den praktiske forskel mellem ydeevne, belastning og stresstest.
Se vores kommende vejledning for at vide mere om funktionstestning mod ydelsestestning.
=> Besøg her for komplette ydeevne-test-tutorials-serier
PREV-vejledning | NÆSTE vejledning
Anbefalet læsning
- En komplet præstationsvejledning med eksempler
- Stresstestguide til begyndere
- Load Testing Komplet guide til begyndere
- Webapplikation belastning, stress og ydeevne test ved hjælp af WAPT
- Load Testing med HP LoadRunner-vejledninger
- Cloud Performance Testing: Cloud-Based Load Testing Service Providers
- Funktionstestning mod ydelsestestning: Skal det gøres samtidigt?
- Load Testing ved hjælp af LoadUI - Et gratis og open source Load Testing Tool