Performance Testing Tutorial: Hvad er, typer, metrics & Eksempel

Test af ydeevne

Performance Testing er en softwaretestproces, der bruges til at teste hastigheden, responstid, stabilitet, pålidelighed, skalerbarhed og ressourceforbrug af en softwareapplikation under en bestemt arbejdsbyrde. Hovedformålet med ydelsestest er at identificere og eliminere ydelsesflaskehalse i softwareapplikationen. Det er en delmængde af performance engineering og også kendt som "Perf Testing".

Fokus for Performance Testing er at kontrollere et softwareprograms

• Hastighed - Bestemmer, om applikationen reagerer hurtigt
• Skalerbarhed - Bestemmer den maksimale brugerbelastning, som softwareapplikationen kan håndtere.
• Stabilitet - Bestemmer, om applikationen er stabil under forskellige belastninger

I denne vejledning lærer du-

• Hvad er ydelsestest?
• Hvorfor udfører ydelsestest?
• Typer af ydelsestest
• Almindelige præstationsproblemer
• Process for testtest
• Metrics til test af ydeevne: Overvågede parametre
• Eksempel på sager om præstationstest
• Værktøjer til præstationstest
• FAQ

Hvorfor udfører ydelsestest?

Funktioner og funktionalitet, der understøttes af et softwaresystem, er ikke det eneste problem. En softwareapplikations ydeevne som dens responstid, pålidelighed, ressourceforbrug og skalerbarhed betyder noget. Målet med Performance Testing er ikke at finde fejl, men at eliminere ydeevne flaskehalse.

Performance Testing udføres for at give interessenter information om deres anvendelse med hensyn til hastighed, stabilitet og skalerbarhed. Mere vigtigt er det, at Performance Testing afdækker, hvad der skal forbedres, inden produktet går på markedet. Uden ydelsestest vil software sandsynligvis lide under problemer som: kører langsomt, mens flere brugere bruger det samtidigt, uoverensstemmelser på tværs af forskellige operativsystemer og dårlig brugervenlighed.

Ydelsestest vil afgøre, om deres software opfylder hastighed, skalerbarhed og stabilitetskrav under forventede arbejdsbelastninger. Applikationer, der sendes til markedet med dårlige præstationsmålinger på grund af ikke-eksisterende eller dårlig præstationstest, vil sandsynligvis få et dårligt omdømme og ikke opfylde forventede salgsmål.

Også missionskritiske applikationer som rumstartprogrammer eller livreddende medicinsk udstyr skal testes for at sikre, at de kører i lang tid uden afvigelser.

Ifølge Dunn & Bradstreet oplever 59% af Fortune 500-virksomhederne anslået 1,6 timers nedetid hver uge. I betragtning af det gennemsnitlige Fortune 500-firma med et minimum på 10.000 ansatte betaler $ 56 i timen, vil arbejdsdelen af ​​nedetidsomkostninger for en sådan organisation være $ 896.000 ugentligt, hvilket betyder mere end $ 46 millioner om året.

Kun 5 minutters nedetid på Google.com (19. august-13) anslås at koste søgegiganten så meget som $ 545.000.

Det anslås, at virksomheder mistede et salg til en værdi af $ 1100 pr. Sekund på grund af en nylig Amazon Web Service Outage.

Derfor er præstationstest vigtig.

Typer af ydelsestest

• Belastningstest - kontrollerer applikationens evne til at udføre under forventede brugerbelastninger. Formålet er at identificere præstationsflaskehalse, før softwareapplikationen bliver live.
• Stresstest - indebærer at teste et program under ekstreme arbejdsbelastninger for at se, hvordan det håndterer høj trafik eller databehandling. Målet er at identificere brudpunktet for en applikation.
• Udholdenhedstest - udføres for at sikre, at softwaren kan håndtere den forventede belastning over en lang periode.
• Spike test - tester softwarens reaktion på pludselige store pigge i belastningen genereret af brugerne.
• Volumen test - Under Volumen test stort nr. af. Data udfyldes i en database, og det overordnede softwaresystems adfærd overvåges. Målet er at kontrollere softwareapplikationens ydeevne under forskellige databasevolumener.
• Test af skalerbarhed - Målet med skalerbarhedstest er at bestemme softwareapplikationens effektivitet i "opskalering" for at understøtte en stigning i brugerbelastningen. Det hjælper med at planlægge kapacitetsudvidelse til dit softwaresystem.

Almindelige præstationsproblemer

De fleste ydeevne problemer drejer sig om hastighed, responstid, belastningstid og dårlig skalerbarhed. Hastighed er ofte en af ​​de vigtigste egenskaber ved en applikation. En applikation, der kører langsomt, mister potentielle brugere. Performance-test udføres for at sikre, at en app kører hurtigt nok til at holde brugerens opmærksomhed og interesse. Se på følgende liste over almindelige ydeevneproblemer og bemærk, hvordan hastighed er en almindelig faktor i mange af dem:

• Lang indlæsningstid - Indlæsningstid er normalt det indledende tidspunkt, det tager en applikation at starte. Dette bør generelt holdes på et minimum. Mens nogle applikationer er umulige at indlæse på under et minut, skal belastningstiden holdes under et par sekunder, hvis det er muligt.
• Dårlig responstid - Svartid er den tid, det tager, fra en bruger indtaster data i applikationen, indtil applikationen sender et svar på den input. Generelt skal dette være meget hurtigt. Igen, hvis en bruger skal vente for længe, ​​mister de interessen.
• Dårlig skalerbarhed - Et softwareprodukt lider under dårlig skalerbarhed, når det ikke kan håndtere det forventede antal brugere, eller når det ikke har plads til en bred nok række af brugere. Belastningstestning skal udføres for at være sikker på, at applikationen kan håndtere det forventede antal brugere.
• Flaskehals - Flaskehalse er forhindringer i et system, der forringer den samlede systemydelse. Flaskehalsning er, når kodningsfejl eller hardwareproblemer forårsager et fald i kapacitet under visse belastninger. Flaskehalsning er ofte forårsaget af et defekt afsnit i koden. Nøglen til at løse et problem med flaskehals er at finde det afsnit af kode, der forårsager afmatningen, og forsøge at rette det der. Flaskehals er løst ved enten at rette dårlige kørende processer eller tilføje yderligere hardware. Nogle almindelige præstationsflaskehalse er
  • CPU-udnyttelse
  • Hukommelsesudnyttelse
  • Netværksudnyttelse
  • Operativsystems begrænsninger
  • Diskbrug

Process for testtest

Den metode, der er anvendt til præstationsafprøvning, kan variere meget, men målet for præstationstest forbliver den samme. Det kan hjælpe med at demonstrere, at dit softwaresystem opfylder visse foruddefinerede præstationskriterier. Eller det kan hjælpe med at sammenligne ydelsen af ​​to softwaresystemer. Det kan også hjælpe med at identificere dele af dit softwaresystem, der forringer dets ydeevne.

Nedenfor er en generisk proces til, hvordan man udfører præstationstest

1. Identificer dit testmiljø - Kend dit fysiske testmiljø, produktionsmiljø og hvilke testværktøjer der er tilgængelige. Forstå detaljer om hardware, software og netværkskonfigurationer, der bruges under test, inden du begynder testprocessen. Det vil hjælpe testere med at oprette mere effektive tests. Det hjælper også med at identificere mulige udfordringer, som testere kan støde på under testtestprocedurerne.
2. Identificer præstationsacceptkriterierne - Dette inkluderer mål og begrænsninger for gennemstrømning, svartider og ressourcetildeling. Det er også nødvendigt at identificere projektsucceskriterier uden for disse mål og begrænsninger. Testere bør have beføjelse til at indstille præstationskriterier og mål, fordi projektspecifikationerne ofte ikke inkluderer et bredt udvalg af præstationsbenchmarks. Nogle gange kan der slet ikke være nogen. Når det er muligt at finde en lignende applikation at sammenligne med, er en god måde at sætte præstationsmål på.
3. Planlæg og design præstationsprøver - Bestem, hvordan brugen sandsynligvis vil variere blandt slutbrugere, og identificer nøglescenarier, der skal testes for alle mulige brugssager. Det er nødvendigt at simulere en række slutbrugere, planlægge testtestdata og skitsere, hvilke målinger der indsamles.
4. Konfiguration af testmiljø - Forbered testmiljøet før udførelse. Arranger også værktøjer og andre ressourcer.
5. Implementere testdesign - Opret præstationstest i henhold til dit testdesign.
6. Kør testene - Udfør og overvåg testene.
7. Analyser, tune og test igen - Konsolider, analyser og del testresultater. Finjuster derefter og test igen for at se, om der er en forbedring eller et fald i ydeevnen. Da forbedringer generelt bliver mindre for hver gentest, skal du stoppe, når flaskehalse skyldes CPU'en. Derefter kan du overveje muligheden for at øge CPU-effekten.

Metrics til test af ydeevne: Overvågede parametre

De grundlæggende parametre, der overvåges under ydelsestest, inkluderer:

• Processorbrug - en mængde tidsprocessor bruger på at udføre ikke-inaktive tråde.
• Hukommelsesforbrug - mængden af ​​fysisk hukommelse, der er tilgængelig for processer på en computer.
• Disktid - hvor lang tid disk er optaget med at udføre en læse- eller skriveanmodning.
• Båndbredde - viser de bits pr. Sekund, der bruges af et netværksinterface.
• Private bytes - antal bytes, som en proces har tildelt, som ikke kan deles mellem andre processer. Disse bruges til at måle hukommelseslækager og brug.
• Engageret hukommelse - anvendt virtuel hukommelse.
• Hukommelsessider / sekund - antal sider skrevet til eller læst fra disken for at løse hårde sidefejl. Fejl på hårde sider er, når kode, der ikke er fra det aktuelle arbejdssæt, kaldes op fra andre steder og hentes fra en disk.
• Sidefejl / sekund - den samlede hastighed, i hvilken fejlsider behandles af processoren. Dette sker igen, når en proces kræver kode uden for sit arbejdssæt.
• CPU afbryder pr. Sekund - er gennemsnittet. antallet af hardware afbryder en processor modtager og behandler hvert sekund.
• Diskekø længde - er gns. ingen. af læse- og skriveanmodninger i kø for den valgte disk i et prøveinterval.
• Netværksoutputkø længde - længden af ​​outputpakkekøen i pakker. Alt mere end to betyder en forsinkelse, og flaskehalse skal stoppes.
• Netværksbyte i alt pr. Sekund - hastighed, hvilke byte der sendes og modtages på grænsefladen inklusive indramningstegn.
• Svartid - tid fra når en bruger indtaster en anmodning, indtil det første tegn i svaret modtages.
• Gennemstrømningshastighed en computer eller et netværk modtager anmodninger pr. Sekund.
• Mængde af forbindelsespooling - antallet af brugeranmodninger, der opfyldes af poolede forbindelser. Jo flere anmodninger mødes af forbindelser i puljen, jo bedre bliver ydeevnen.
• Maksimum aktive sessioner - det maksimale antal sessioner, der kan være aktive på én gang.
• Hit ratio - Dette har at gøre med antallet af SQL-sætninger, der håndteres af cachelagrede data i stedet for dyre I / O-operationer. Dette er et godt sted at starte for at løse problemer med flaskehalse.
• Hits pr. Sekund - nej. af hits på en webserver i hvert sekund af en belastningstest.
• Tilbageslagssegment - den mængde data, der kan tilbageføres til enhver tid.
• Databaselåse - låsning af tabeller og databaser skal overvåges og omhyggeligt indstilles.
• Top ventetid - overvåges for at bestemme, hvilke ventetider der kan reduceres, når man beskæftiger sig med, hvor hurtigt data hentes fra hukommelsen
• Trådtal - En applikations sundhed kan måles med nej. af tråde, der kører og i øjeblikket er aktive.
• Affaldssamling - Det har at gøre med at returnere ubrugt hukommelse tilbage til systemet. Affaldsindsamling skal overvåges for effektivitet.

Eksempel på sager om præstationstest

• Bekræft, at responstiden ikke er mere end 4 sekunder, når 1000 brugere får adgang til webstedet samtidigt.
• Kontroller, at svartiden for applikationen under belastning er inden for et acceptabelt interval, når netværksforbindelsen er langsom
• Kontroller det maksimale antal brugere, som applikationen kan håndtere, før den går ned.
• Tjek databasekørselstid, når 500 poster læses / skrives samtidigt.
• Kontroller CPU- og hukommelsesforbrug af applikationen og databaseserveren under peak load-forhold
• Kontroller applikationens responstid under lave, normale, moderate og tunge belastningsforhold.

Under udførelsen af ​​den faktiske ydelsestest udskiftes vage udtryk som acceptabelt interval, tung belastning osv. Med konkrete tal. Ydelsesingeniører indstiller disse tal i henhold til forretningskrav og applikationens tekniske landskab.

Værktøjer til præstationstest

Der findes en lang række præstationsværktøjer på markedet. Det værktøj, du vælger til test, afhænger af mange faktorer, såsom typer af protokollen, licensomkostninger, hardwarekrav, platformsstøtte osv. Nedenfor er en liste over populært anvendte testværktøjer.

• LoadNinja - revolutionerer den måde, vi indlæser test på. Dette skybaserede værktøj til belastningstest giver holdene mulighed for at optage og afspille øjeblikkeligt omfattende belastningstest uden kompleks dynamisk korrelation og køre disse belastningstest i rigtige browsere i skala. Hold er i stand til at øge testdækningen. & reducer belastningstesttiden med over 60%.
• NeoLoad - er platformen til præstationstest designet til DevOps, der problemfrit integreres i din eksisterende pipeline for kontinuerlig levering. Med NeoLoad tester teams 10 gange hurtigere end med traditionelle værktøjer for at imødekomme det nye niveau af krav i hele Agile softwareudviklings livscyklus - fra komponent til fuld systemdækkende belastningstest.
• HP LoadRunner - er de mest populære værktøjer til præstationstest på markedet i dag. Dette værktøj er i stand til at simulere hundreder af tusinder af brugere og sætte applikationer under virkelige belastninger for at bestemme deres adfærd under forventede belastninger. Loadrunner har en virtuel brugergenerator, der simulerer handlinger fra levende menneskelige brugere.
• Jmeter - et af de førende værktøjer, der bruges til belastningstest af web- og applikationsservere.

FAQ

Hvilke applikationer skal vi præstere?

Ydelsestest udføres altid kun for klientserverbaserede systemer. Dette betyder, at ethvert program, der ikke er en klientserverbaseret arkitektur, ikke skal kræve Performance Testing.

For eksempel er Microsoft Calculator hverken klient-serverbaseret, eller den kører flere brugere; det er derfor ikke en kandidat til Performance Testing.

Hvad er forskellen mellem Performance Testing & Performance Engineering

Det er af betydning at forstå forskellen mellem Performance Testing og Performance Engineering. En forståelse deles nedenfor:

Performance Testing er en disciplin, der beskæftiger sig med test og rapportering af den aktuelle ydeevne for en softwareapplikation under forskellige parametre.

Performance engineering er den proces, hvormed software testes og tunes med det formål at realisere den krævede ydeevne. Denne proces har til formål at optimere det vigtigste egenskab ved applikationsydelse, dvs. brugeroplevelse.

Historisk har testning og tuning været tydeligt adskilte og ofte konkurrerende områder. I de sidste par år har imidlertid flere lommer af testere og udviklere samarbejdet uafhængigt for at oprette tuningteams. Fordi disse hold har mødt en betydelig succes, har begrebet kobling af ydelsestest med performance tuning fanget, og nu kalder vi det performance engineering.

Konklusion

Inden for softwareteknik er ydelsestest nødvendig inden markedsføring af softwareprodukt. Det sikrer kundetilfredshed og beskytter en investors investering mod produktsvigt. Omkostninger til præstationstest er normalt mere end kompenseret med forbedret kundetilfredshed, loyalitet og fastholdelse.