Hvad er belastningstest? (Eksempler)

Hvad er belastningstest?

Load Testing er en ikke-funktionel softwaretestproces, hvor softwareapplikationens ydeevne testes under en specifik forventet belastning. Det bestemmer, hvordan softwareapplikationen opfører sig, mens den tilgås af flere brugere samtidigt. Målet med Load Testing er at forbedre ydeevneflaskehalse og at sikre stabilitet og problemfri funktion af softwareapplikationen før implementering.

Denne test identificerer normalt -

• Den maksimale driftskapacitet for en applikation
• Bestem, om den nuværende infrastruktur er tilstrækkelig til at køre applikationen
• Anvendelsens bæredygtighed med hensyn til maksimal brugerbelastning
• Antal samtidige brugere, som en applikation kan understøtte, og skalerbarhed for at give flere brugere adgang til den.

Det er en form for ikke-funktionel test. Inden for Software Engineering er belastningstest almindeligvis brugt til klienten/serveren, webbaserede applikationer – både intranet og internet.

Hvorfor er belastningstest nødvendig?

Nogle ekstremt populære websteder har lidt alvorlige nedetider, når de får massive trafikmængder. E-handelswebsteder investerer kraftigt i reklamekampagner, men ikke i Load Testing for at sikre optimal systemydelse, når den markedsføring bringer trafik.

Eksempler på belastningstest

• Toysrus.com kunne ikke håndtere den trafik, som deres egen reklamekampagne genererede, og tabte dermed både de marketingudgifter og det salg, som de skulle have produceret.
• Et flyselskabs hjemmeside var ikke i stand til at håndtere 10000+ brugere under et festivaltilbud.
• Encyclopedia Britannica erklærede fri adgang til deres onlinedatabase som et kampagnetilbud. De var ikke i stand til at følge med i trafikken i ugevis.

Mange websteder lider under forsinkede indlæsningstider, når de møder tung trafik. Lidt fakta -

• Forladelse af sider stiger kraftigt ud over ca. 3 sekunders sideindlæsningstid, og effekten forværres på mobilforbindelser.
• Langsomme sider koster e-handelssider målbar omsætning ved hvert besøg, hvilket er grunden til, at performance behandles som en forretningsmæssig måleenhed snarere end en teknisk.

Hvorfor belastningstest?

• Belastningstest giver tillid til systemet og dets pålidelighed og ydeevne.
• Belastningstest hjælper med at identificere flaskehalse i systemet under svære brugerstressscenarier, før de sker i et produktionsmiljø.
• Belastningstest giver fremragende beskyttelse mod dårlig ydeevne og rummer komplementære strategier for præstationsstyring og overvågning af et produktionsmiljø.

Mål for belastningstest

Indlæsningstest identificerer følgende problemer, før applikationen flyttes til markedet eller produktionen:

• Svartid for hver transaktion
• Ydeevne af systemkomponenter under forskellige belastninger
• Ydeevne af databasekomponenter under forskellige belastninger
• Netværksforsinkelse mellem klienten og serveren
• Problemer med softwaredesign
• Serverkonfigurationsproblemer som en webserver, applikationsserver, databaseserver osv.
• Hardwarebegrænsningsproblemer som CPU-maksimering, hukommelsesbegrænsninger, netværksflaskehals osv.

Belastningstest vil afgøre, om systemet skal finjusteres, eller der kræves modifikation af hardware og software for at forbedre ydeevnen. For effektivt at udføre belastningstest kan du bruge forskellige præstationstestværktøjer som er tilgængelige for at hjælpe dig med at identificere områder, der kan forbedres.

Forudsætninger for belastningstestning

Den vigtigste metrik for belastningstest er responstid. Før du begynder belastningstestning, skal du bestemme –

• Om responstiden allerede er målt og sammenlignet – Kvantitativ
• Om responstiden er relevant for forretningsprocessen – Relevant
• Om responstiden er forsvarlig – Realistisk
• Om responstiden er opnåelig – Opnåelig
• Om responstiden er målbar ved hjælp af et værktøj eller stopur – Målbar

Miljøopsætning før belastningstest

Hardware platform	Software Configuration
Server maskiner Processorer Hukommelse Disklager Indlæs maskinkonfiguration Netværkskonfiguration	Operating System Server software

Strategier for belastningstest

Der er mange måder at udføre belastningstest på. Følgende er et par belastningsteststrategier-

• Manuel belastningstest: Dette er en af ​​strategierne til at udføre belastningstest, men det producerer ikke gentagelige resultater, kan ikke give målbare niveauer af stress på en applikation og er en umulig proces at koordinere.
• Egenudviklede belastningstestværktøjer: En organisation, der indser vigtigheden af ​​belastningstest, kan bygge deres egne værktøjer til at udføre belastningstest.
• Open source belastningstestværktøjer: Der er flere belastningstestværktøjer tilgængelige som open source, der er gratis. De er måske ikke så sofistikerede som deres betalte modstykker, men hvis du er på et budget, er de det bedste valg.
• Værktøjer til belastningstest i virksomhedsklassen: De kommer normalt med mulighed for optagelse/afspilning. De understøtter et stort antal protokoller. De kan simulere et usædvanligt stort antal brugere.

Sådan laver du belastningstest

Belastningstestprocessen kan kort beskrives som nedenfor –

1. Opret en dedikeret Testmiljø til belastningsprøvning
2. Definer belastningstestscenarierne
3. Bestem belastningstesttransaktioner for en applikation
   • Forbered data for hver transaktion
   • Antallet af brugere, der får adgang til systemet, skal forudsiges
   • Bestem forbindelseshastigheder. Nogle brugere kan være forbundet via faste kredsløb, mens andre kan bruge opkald
   • Bestem forskellige browsere og operativsystemer, der bruges af brugerne 
   • En konfiguration af alle servere som web-, applikations- og DB-servere
4. Udførelse og overvågning af testscenarier. Indsamling af forskellige metrics
5. Analyser resultaterne. Kom med anbefalinger
6. Finjuster systemet
7. Test igen

Retningslinjer for belastningstestning

1. Belastningstest bør planlægges, når applikationen bliver funktionsstabil.
2. Et stort antal unikke data skulle være klar i datapuljen
3. Antallet af brugere bør bestemmes for hvert scenarie eller scripts
4. Undgå oprettelse af detaljerede logfiler for at spare på diskens IO-plads
5. Prøv at undgå at downloade billeder på siden
6. I processen med at udføre belastningstest-testcases, bør konsistensen af ​​responstiden over den forløbne periode logges, og det samme bør sammenlignes med forskellige testkørsler.

Forskellen mellem belastnings- og stresstest

Load Testing	Stresstest
Belastningstest identificerer flaskehalse i systemet under forskellige arbejdsbelastninger og kontrollerer, hvordan systemet reagerer, når belastningen gradvist øges	Stresstest bestemmer systemets brudpunkt for at afsløre det maksimale punkt, hvorefter det bryder.
For at genkende den øvre grænse for systemet skal du indstille SLA for appen og kontrollere, hvordan systemet kan håndtere en tung belastning.	For at tjekke, hvordan systemet opfører sig under ekstreme belastninger, og hvordan det kommer sig efter fejl.
Generering af øget belastning på en webapplikation er hovedformålet med belastningstest.	Stresstest har til formål at sikre, at serverne ikke går ned under en pludselig høj belastning i længere tid.
De egenskaber, der kontrolleres i en belastningstest, er topydelse, servermængde og responstid.	Denne form for test kontrollerer stabilitetens responstid osv.
Ved belastningstest er belastningsgrænsen en tærskel for en pause.	Ved stresstest er belastningsgrænsen over tærsklen for et brud.

Forskellen mellem funktionel og belastningstest

Funktionstest	Load Testing
Resultaterne af funktionelle tests er let forudsigelige, da vi har de rigtige trin og forudsætninger defineret	Resultaterne af belastningstests er uforudsigelige
Resultaterne af funktionelle tests varierer lidt	Belastningstestresultater varierer drastisk
Hyppighed af udførelse Funktionstest vil være høj	En frekvens for udførelse af belastningstest vil være lav
Resultater af funktionstest afhænger af testdataene	Belastningstest afhænger af antallet af brugere.

Indlæs testværktøjer

LoadRunner

LoadRunner, oprindeligt fra HP og nu en del af OpenText Efter Micro Focus-opkøbet tester den applikationer under normal og spidsbelastning. Den genererer belastning gennem virtuelle brugere, der emulerer reel netværkstrafik, og rapporterer resultaterne grafisk.

Læs mere i LoadRunner-vejledning.

Apache JMeter

En open source Java værktøj og den mest anvendte gratis mulighed. Det understøtter HTTP, JDBC, JMS, FTP og mere, gemmer testplaner som XML og integreres i CI-pipelines. Se JMeter tutorial til en gennemgang.

Gatling

Et open source-værktøj, hvis tests er skrevet som kode i Scala eller JavaDen håndterer høj samtidighed på beskeden hardware og producerer detaljerede HTML-rapporter, hvilket passer til teams, der foretrækker versionsstyrede testscripts.

k6

Et open source-værktøj med tests skrevet i JavaScript, designet til udviklerejet performancetest i en CI-pipeline i stedet for som en separat QA-aktivitet.

Valg af værktøj

Pick JMeter For den bredeste protokoldækning uden omkostninger, Gatling eller k6, når teamet ønsker, at tests skal holdes i kildekontrol sammen med applikationen, og et kommercielt værktøj som LoadRunner, når support af virksomhedsprotokoller og leverandørassistance berettiger licensen.

Fordele og ulemper ved belastningstestning

Følgende er fordelene ved belastningstest:

• Ydeevne flaskehalse identifikation før produktion
• Forbedrer skalerbarheden af ​​systemet
• Minimer risikoen i forbindelse med nedetid i systemet
• Reducerede omkostninger ved fiasko
• Øge kundetilfredsheden

Ulemper ved belastningstest:

• De fleste værktøjer kræver programmeringskendskab for at kunne scripte realistiske scenarier.
• Værktøjer kan være dyre, da priser afhænger af antallet af understøttede virtuelle brugere.

Nøglemålinger, der skal registreres under en belastningstest

Afsnittet om forudsætninger fastlægger svartid som den primære måleenhed. I praksis skal en belastningstestrapport bruge sekscifrede tal, fordi svartid alene ikke kan fortælle dig, hvorfor et system blev langsommere.

metric	Hvad den fortæller dig	Advarselsskilt
Gennemsnitlig svartid	Den typiske brugeroplevelse	Stigende i takt med at belastningen øges
95. percentil responstid	Oplevelsen for de langsomste brugere	Langt over gennemsnittet
gennemløb	Anmodninger behandlet pr. sekund	Fladning eller fald, mens lasten stiger
Fejlrate	Andel af mislykkede eller timeout-forespørgsler	Enhver stigning over den aftalte tærskel
Samtidige brugere	Faktiske samtidige sessioner opnået	Lavere end det tilsigtede scenarie
Serverressourceforbrug	CPU-, hukommelses-, disk- og netværkskapacitet	Enhver ressource over cirka 80 procent

Læsekapacitet sammen med svartid. Stigende svartid med stigende gennemløbshastighed betyder ganske enkelt, at systemet har mere travlt. Stigende svartid med faldende gennemløb betyder, at den har overskredet sin kapacitet og nu mister arbejde, hvilket er det punkt, testen eksisterer for at finde.

Rapportér aldrig kun gennemsnittet. Et gennemsnit på 900 ms med en 95. percentil på 1.1 sekunder beskriver et konsistent system. Det samme gennemsnit med en 95. percentil på 11 sekunder betyder, at én ud af tyve brugere har en uacceptabel oplevelse, som gennemsnittet skjuler.

Hvordan denne test sammenlignes med andre præstationstests

Ydelsestestning er en familie af tests, der adskiller sig i formen af ​​den påførte belastning, hvilket er grunden til, at de så let forveksles.

Testtype	Hvad er øget	Spørgsmål det besvarer
Belastningstest	Samtidige brugere, til den forventede top	Opfylder det målene under normal spidsbelastning?
Volumentest	Data opbevaret i databasen	Klarer den sig, når datasættet vokser?
Stresstest	Belast ud over kapacitet, indtil fejl	Hvor går den i stykker, og hvordan?
Spike test	Indlæs, øjeblikkeligt og ekstremt	Overlever den og kommer den sig efter et chok?
Udholdenhedstest	Varighed ved normal belastning	Forringes ydeevnen over tid?
Soak-test	Varighed, observationsressourcer	Er der hukommelses- eller handle-lækager?
Stabilitetstest	Varierende forhold	Forbliver den pålidelig, når forholdene ændrer sig?

Den mest betydningsfulde forskel her: Volumentest skalerer dataene, belastningstest skalerer brugerne. En rapport, der kører på to sekunder mod ti tusinde rækker og to minutter mod ti millioner rækker, har et volumenproblem, ikke et belastningsproblem, og ingen ekstra serverkapacitet vil løse det.

Ofte Stillede Spørgsmål