Ydelsestestning sparer virksomheder for millioner af dollars. Ifølge en rapport fra Dun & Bradstreet oplever 59 % af Fortune 500-virksomhederne mindst 1,6 timers nedetid hver uge. Lad os hurtigt regne på det. En Fortune 500-virksomhed beskæftiger i gennemsnit 52.810 personer. Hvis hver medarbejder kun tjente 10 dollars i timen, ville det koste en virksomhed 528.100 dollars om ugen i tabt produktivitet – eller 27.461.200 dollars om året.
Det er mange penge, der bare... forsvinder.
Det er i alles interesse, at software gennemgår en grundig ydelsestestning. Lad os undersøge betydningen af ydelsestestning, forskellige typer, almindelige problemer og værdifulde værktøjer.
Hvad er ydelsestestning?
Ydelsestestning kontrollerer, at software kan køre på et højt niveau under den forventede arbejdsbelastning. Udviklere vil undgå at skabe software, der er responsiv og hurtig, når kun én bruger er tilsluttet, men bliver langsom, når den skal håndtere flere brugere.
QA-testning handler ikke kun om fejl. Softwarens hastighed, reaktionsevne og ressourceforbrug er yderligere fokusområder. Ydelsestestning fokuserer på at identificere og afhjælpe flaskehalse i ydeevnen. Flaskehalse identificeres ved at simulere brugertrafik. Ideelt set vil QA-testere køre ydelsestest under virkelige forhold. Dette er en af softwarens første rejser ud af de ideelle omstændigheders trygge rammer og ind i slutbrugeroplevelsens usikre verden.
Hvorfor bør jeg teste ydeevnen?
Det giver interessenter konkrete oplysninger om softwarens hastighed, stabilitet og skalerbarhed. Uden ydelsestestning risikerer softwaren at få problemer med hastighed og pålidelighed ved lanceringen.
Vi har allerede nævnt produktivitetsomkostningerne ved et systemnedbrud. I mange tilfælde er det alene grund nok. Selvom al software ikke bruges internt, leveres og sælges den til kunder. I det scenarie bliver ydelsestestning endnu vigtigere, fordi det sidste, man ønsker, er en flok kunder, der er utilfredse med produktets kvalitet.
I udviklingsfasen giver ydelsestestning et klarere billede af, hvad der skal forbedres med hensyn til hastighed, stabilitet og ressourceforbrug. Uden den kunne softwaren blive udgivet med flere alvorlige fejl, såsom langsom kørsel med flere brugere, nedbrud på grund af for mange brugere og en inkonsekvent brugeroplevelse på tværs af forskellige operativsystemer og browsere.
Test for fejl giver ikke et klart billede af, hvordan softwaren vil fungere under belastning. Det er vigtigt, at ydelsestestning udføres uafhængigt og udelukkende med det formål at finde flaskehalse. Gode ydelsestestere ved, at hastighed ikke er det eneste mål for ydeevne. Et program, der indlæses hurtigt, men bruger 100 % af brugerens CPU, yder for eksempel ikke godt. Et sådant eksempel ville give slutbrugeren mange problemer, såsom overophedning, forkortet CPU-levetid, langsommere ydeevne på tværs af flere programmer og lejlighedsvise nedbrud.
Sådan udfører du ydelsestestning
Hvordan du udfører ydelsestestning, varierer afhængigt af softwaren. Der er flere forskellige tilgange, en QA-tester kan benytte. Det er en form for ikke-funktionel testning, hvilket betyder, at den i høj grad ikke beskæftiger sig med brugergrænsefladen.
Ydelsestestere vil sikre, at de interne komponenter er så finjusterede som muligt. De er pitcrewet i et F1-løb.
Den type testning, der udføres, afhænger af den metode, organisationen anvender. Hvis de følger den traditionelle vandfaldsmodel til softwareudvikling, får ydelsestesterne sandsynligvis først adgang til produktet, når udviklingen er afsluttet. Hvis organisationen derimod anvender den agile metode, vil agil ydelsestestning sandsynligvis foregå gennem hele udviklingsprocessen.
Have an account? Log In
Typer af ydelsestestning
Nogle kræver manuel testning, mens andre kræver automatiseret testning, men med den hastige stigning i automatiseret testning og udviklingen af mere effektive og pålidelige værktøjer hver dag er der en markant præference for automatiseret testning i disse situationer, fordi det kræver mange virtuelle brugere for at køre softwaren, som om de var rigtige slutbrugere. Dette er svært at efterligne manuelt, da det ville kræve langt flere testere, end teamet sandsynligvis har ansat.
At meget af ydelsestestningen håndteres af maskiner, betyder ikke, at der ikke er vigtige forskelle mellem testtyperne. En QA-tester bør forstå de forskellige typer af ydelsestestning, så vedkommende ved, hvilket værktøj der er bedst til opgaven.
Lad os gennemgå de forskellige typer af ydelsestestning, og hvad hver testtype forsøger at opnå.
Kapacitetstest
Tester, hvor mange brugere systemet kan håndtere, før ydeevnen falder under et acceptabelt niveau. Ved at teste en softwares kapacitet hjælper det udviklere med at forudse problemer med hensyn til skalerbarhed og fremtidig vækst i brugerbasen.
Belastningstest
Bekræfter, at systemet kan håndtere det krævede antal brugere og stadig fungere med et højt ydeevneniveau. Belastningstestværktøjer sikrer, at der ikke opstår daglige problemer med ydeevnen.
Volumentest
Kontrollerer, at softwaren kan håndtere og behandle en stor mængde data samtidigt uden at bryde sammen, blive langsommere eller miste oplysninger.
Stresstest
Forsøger bevidst at få softwaren til at bryde sammen ved at simulere et antal brugere, der markant overstiger forventningerne. Lanceringen af en ny iPhone og den pludselige stigning i brugertrafikken på Apples websted er et fremragende eksempel på en stresstest i den virkelige verden.
Langtidstest
Simulerer høj trafik i en længere periode. Kontrollerer softwarens evne til at tåle længere perioder med høj trafik.
4 almindelige problemer med ydeevnen
Ydeevnetestere støder typisk på mindst ét af disse fire problemer under testen.
- Lang indlæsningstid – Ingen bryder sig om at stirre på skærmen i 30-60 sekunder, mens de venter på, at en applikation indlæses. Det er kedeligt, især hvis det er en app, du åbner flere gange om dagen. Bortset fra noget særdeles ressourcekrævende software bør de fleste applikationer, websider og programmer kunne åbne på under få sekunder. Belastningstest fanger typisk software, der har problemer med at åbne inden for en acceptabel tidsramme.
- Dårlig svartid – Dette minder om problemet med lange indlæsningstider. Det er lige så frustrerende, når det efter den endelige åbning af appen også tager 30-60 sekunder at navigere mellem menuer eller indtaste data. Tænk på de apps, du bruger hver dag – hvor mange af dem får dig til at vente på, at en side indlæses? Det er sandsynligvis ikke ret mange. Lange indlæsningstider får folk til at miste interessen.
- Dårlig skalerbarhed – Dette kaldes uformelt ‘Slashdot-effekten’ eller ‘internettets dødskram’. Har du nogensinde hørt om et interessant websted, som nogen delte med dig på Facebook, og da du klikkede på linket, indlæstes siden ikke? Det skyldes, at du og en million andre ville se det seje lille websted, og at det ikke havde infrastrukturen til at håndtere en pludselig tilstrømning af brugere. En graf over trafikken på webstedet ville se nogenlunde sådan ud:
4. Flaskehalsdannelse – Flaskehalse opstår, når et system fordeler sin processorkraft uhensigtsmæssigt. Hvis din software kræver, at brugernes CPU kører ved 100 %, har de ingen ledig hukommelse til at køre yderligere opgaver. Det er dårligt og fører ofte til overophedning og et betydeligt fald i ydeevnen. Der er flere steder, hvor der kan opstå flaskehalse. Nogle af de mest almindelige er:
- CPU
- Hukommelse
- GPU
- Diskforbrug
More Articles
De bedste værktøjer til ydeevnetest
Hvilket værktøj til ydeevnetest der er det rigtige for dig, afhænger af dit projekt og dine mål. Nogle, såsom Jmeter, er meget gode til at udføre belastnings- og stresstest. Det afhænger også af dit budget. Mindre virksomheder vælger måske et af de mange gratis ydeevnetestværktøjer af høj kvalitet med åben kildekode for at reducere omkostningerne.
Ydeevnetestværktøjer med åben kildekode
Et af de bedst bedømte testværktøjer med åben kildekode er Jmeter. Det har været et oplagt valg for små virksomheder, der ønsker at udføre effektive test. Ydeevnetest med Jmeter analyserer nøje serverens ydeevne under belastning. Det giver dig mulighed for at udføre belastnings- og stresstest for at kontrollere, om din software kan håndtere det normale og maksimale forventede antal brugere.
Når ydeevnetestene er afsluttet, giver Jmeter dig mulighed for at se testresultaterne på flere letforståelige måder. En mulighed er at udskrive resultaterne i grafisk form. Sådan ser Jmeter-grafer ud:
Når du læser grafen, er den vigtigste parameter gennemløbet (den grønne linje), som viser antallet af anmodninger, der blev sendt under testen. Jo højere tallet er, desto bedre. Det viser, hvor mange anmodninger din software kan håndtere pr. minut. I dette eksempel er det 8,003 anmodninger pr. minut.
Andre førende værktøjer:
Der er nogle ulemper ved præstationsafprøvning med åben kildekode. En af dem er, at alle de simulerede brugere kører på virksomhedens servere. Det betyder, at testene udføres under ideelle ydeevneforhold frem for virkelighedsnære forhold. I små virksomheder, der ikke forventer en betydelig belastning, kan dette opfylde deres behov fint. Efterhånden som virksomheden vokser, kan den dog begynde at overveje at købe et førsteklasses værktøj til præstationsafprøvning.
Her er en kort liste over nogle førsteklasses værktøjer til præstationsafprøvning:
Præstationsafprøvning er generelt ens på tværs af operativsystemer. Mange af værktøjerne til præstationsafprøvning på Mac kan køre på Windows.
Afsluttende tanker
Præstationsafprøvning er en uundværlig del af arbejdet med at sikre softwarets pålidelighed og effektivitet, især for SaaS-virksomheder i hastig vækst. Ved at benytte de bedste værktøjer får QA-ledere uvurderlig indsigt i deres systemers skalerbarhed, udholdenhed og evne til at håndtere høj trafik. Tilmeld dig vores nyhedsbrev for at få flere indsigter fra fagfolk inden for kvalitetssikring!
