Ytelsestesting sparer selskaper for millioner av dollar. Ifølge en rapport fra Dun & Bradstreet opplever 59 % av Fortune 500-selskapene minst 1,6 timer med nedetid hver uke. La oss regne litt raskt. I gjennomsnitt har et Fortune 500-selskap 52 810 ansatte. Hvis hver ansatt bare tjente 10 dollar i timen, ville det kostet selskapet 528 100 dollar i uken i tapt produktivitet – eller 27 461 200 dollar i året.
Det er mye penger som bare ... forsvinner.

Det er i alles interesse at ytelsestesting av programvare gjennomføres grundig. La oss utforske betydningen av ytelsestesting, ulike typer, vanlige problemer og verdifulle verktøy.
Hva er ytelsestesting?
Ytelsestesting kontrollerer at programvaren kan kjøre på et høyt nivå under den forventede arbeidsbelastningen. Utviklere ønsker å unngå å lage programvare som er responsiv og rask når bare én bruker er tilkoblet, men som blir treg når den håndterer flere brukere.
QA-testing handler ikke bare om feil. Programvarens hastighet, responsivitet og ressursbruk er også viktige hensyn. Ytelsestesting fokuserer på å identifisere og håndtere flaskehalser i ytelsen. Flaskehalser identifiseres ved å simulere brukertrafikk. Ideelt sett ønsker QA-testere å gjennomføre ytelsestester under virkelige forhold. Dette er en av programvarens første reiser ut fra de ideelle forholdenes trygge havn og inn i sluttbrukeropplevelsens usikre verden.
Hvorfor bør jeg teste ytelsen?
Det gir interessentene konkret informasjon om programvarens hastighet, stabilitet og skalerbarhet. Uten ytelsestesting risikerer programvaren problemer med hastighet og pålitelighet ved lansering.
Vi har allerede nevnt produktivitetskostnaden når et system krasjer. I mange tilfeller er det alene grunn nok. Selv om ikke all programvare brukes internt, leveres og selges den til kunder. I slike tilfeller blir ytelsestesting enda viktigere, fordi det siste du ønsker, er en mengde kunder som er misfornøyde med kvaliteten på produktet ditt.
I utviklingsfasen gir ytelsestesting et tydeligere bilde av hva som må forbedres når det gjelder hastighet, stabilitet og ressursbruk. Uten dette kan programvaren bli lansert med flere alvorlige feil, for eksempel treg kjøring med flere brukere, krasj på grunn av for mange brukere og en ujevn brukeropplevelse på tvers av ulike operativsystemer og nettlesere.
Testing for feil gir ikke et tydelig bilde av hvordan programvaren vil fungere under belastning. Det er viktig at ytelsestesting gjennomføres separat og med det eneste formålet å finne flaskehalser. Gode ytelsestestere vet at hastighet ikke er det eneste målet på ytelse. En applikasjon som lastes inn raskt, men bruker 100 % av brukerens CPU, har for eksempel ikke god ytelse. Et slikt eksempel vil føre til mange problemer for sluttbrukeren, som overoppheting, kortere levetid for CPU-en, lavere ytelse på tvers av flere applikasjoner og sporadiske krasj.
Slik gjennomfører du ytelsestesting
Hvordan du gjennomfører ytelsestesting, varierer avhengig av programvaren. Det finnes flere ulike fremgangsmåter en QA-tester kan benytte. Det er en form for ikke-funksjonell testing, noe som betyr at den i stor grad ikke fokuserer på brukergrensesnittet.
Ytelsestestere ønsker å sørge for at de interne komponentene er så finjusterte som mulig. De er pitcrewet i et F1-løp.

Hvilken type testing som gjennomføres, avhenger av hvilken metodikk organisasjonen bruker. Hvis de følger den tradisjonelle fossefallsmodellen for programvareutvikling, får ytelsestesterne sannsynligvis ikke tilgang til produktet før utviklingen er ferdig. Hvis organisasjonen derimot bruker smidig metodikk, vil smidig ytelsestesting sannsynligvis foregå gjennom hele utviklingsprosessen.
Have an account? Log In
Typer ytelsestesting
Noen krever manuell testing, mens andre krever automatisert testing. Med den raske økningen i automatisert testing og utviklingen av mer effektive og pålitelige verktøy hver dag, er det en betydelig preferanse for automatisert testing i disse situasjonene, fordi det krever mange virtuelle brukere for å kjøre programvaren som om de var faktiske sluttbrukere. Dette er vanskelig å gjenskape manuelt, siden det ville kreve langt flere testere enn teamet sannsynligvis har.
At mye av ytelsestestingen håndteres av maskiner, betyr ikke at det ikke finnes viktige forskjeller mellom testtypene. En QA-tester bør forstå de ulike typene ytelsestesting, slik at vedkommende vet hvilket verktøy som passer best til oppgaven.
La oss se nærmere på de ulike typene ytelsestesting og hva hver type test skal oppnå.
Kapasitetstesting
Tester hvor mange brukere systemet kan håndtere før ytelsen synker under akseptable nivåer. Ved å teste programvarens kapasitet hjelper man utviklerne med å forutse problemer knyttet til skalerbarhet og fremtidig vekst i brukerbasen.
Lasttesting
Bekrefter at systemet kan håndtere det nødvendige antallet brukere og fortsatt fungere med høy ytelse. Verktøy for belastningstesting sikrer at det ikke oppstår daglige ytelsesproblemer.
Volumtesting
Kontrollerer at programvaren kan håndtere og behandle store datamengder samtidig uten å krasje, bli tregere eller miste informasjon.
Stresstesting
Forsøker med vilje å bryte programvaren ved å simulere et antall brukere som betydelig overstiger forventningene. Lanseringsdagen for en ny iPhone og den plutselige økningen i brukertrafikk på Apples nettsted er et utmerket eksempel på en stresstest i den virkelige verden.
Utholdenhetstesting
Simulerer høy trafikk over en lengre periode. Kontrollerer programvarens evne til å tåle langvarige perioder med høy trafikk.
4 vanlige ytelsesproblemer
Ytelsestestere støter vanligvis på minst ett av disse fire problemene under testingen.
- Lang lastetid – Ingen liker å stirre på skjermen i 30–60 sekunder mens de venter på at en applikasjon skal lastes inn. Det er kjedelig, spesielt hvis det er en app du åpner flere ganger om dagen. Med unntak av svært ressurskrevende programvare bør de fleste applikasjoner, nettsider og programmer kunne åpnes på under noen få sekunder. Belastningstester fanger vanligvis opp programvare som har problemer med å åpnes innenfor en akseptabel tidsramme.
- Dårlig responstid – Dette ligner på problemet med lang lastetid. Det er like frustrerende når det også tar 30–60 sekunder å navigere mellom menyer eller legge inn data etter at appen endelig er åpnet. Tenk på appene du bruker hver dag – hvor mange av dem får deg til å vente på at en side skal lastes inn? Det er sannsynligvis ikke særlig mange. Lange lastetider gjør at folk mister interessen.
- Dårlig skalerbarhet – Dette kalles uformelt «slashdot-effekten» eller «internettets dødelige omfavnelse». Har du noen gang hørt om et interessant nettsted som noen delte med deg på Facebook, og da du klikket på lenken, lastet ikke siden inn? Det skyldes at du og en million andre ønsket å se på det kule lille nettstedet, og at det ikke hadde infrastrukturen som skulle til for å håndtere en plutselig økning i antall brukere. En graf over trafikken på nettstedet ville sett omtrent slik ut:

4. Flaskehalser – Flaskehalser oppstår når et system fordeler prosesseringskraften dårlig. Hvis programvaren krever at brukernes CPU kjører på 100 %, har de ikke noe minne igjen til å kjøre flere oppgaver. Dette er dårlig og fører ofte til overoppheting og et betydelig ytelsesfall. Det finnes flere steder der flaskehalser kan oppstå. Noen av de vanligste er:
- CPU
- Minne
- GPU
- Diskbruk
More Articles
De beste verktøyene for ytelsestesting
Hvilket verktøy for ytelsestesting som passer for deg, avhenger av prosjektet og målene dine. Noen, som Jmeter, er svært gode til å kjøre belastnings- og stresstester. Det avhenger også av budsjettet ditt. Mindre selskaper kan velge blant mange kostnadsfrie ytelsestestingsverktøy av høy kvalitet med åpen kildekode for å redusere kostnadene.
Ytelsestestingsverktøy med åpen kildekode
Et av de best rangerte testverktøyene med åpen kildekode er Jmeter. Det har vært et førstevalg for små selskaper som ønsker å gjennomføre effektive tester. Ytelsestesting med Jmeter analyserer nøye serverens ytelse under belastning. Det lar deg kjøre belastnings- og stresstester for å kontrollere om programvaren kan håndtere det normale og maksimale forventede antallet brukere.
Når ytelsestestene er fullført, lar Jmeter deg se testresultatene på flere lettfattelige måter. Ett alternativ er å vise resultatene som en graf. Slik ser Jmeter-grafer ut:

Når du leser grafen, er den viktigste parameteren gjennomstrømningen (den grønne linjen), som viser antallet forespørsler som ble sendt under testen. Jo høyere tallet er, desto bedre. Den viser hvor mange forespørsler programvaren kan håndtere per minutt. I dette eksempelet er det 8 003 forespørsler per minutt.
Andre gode verktøy:
Det finnes noen ulemper ved ytelsestesting med åpen kildekode. Én av dem er at alle de simulerte brukerne kjører på selskapets servere. Dette betyr at testene utføres under ideelle ytelsesforhold i stedet for under forhold fra den virkelige verden. For små selskaper som ikke forventer en betydelig belastning, kan dette dekke behovene deres godt. Når selskapet vokser, kan det imidlertid begynne å vurdere å kjøpe et førsteklasses verktøy for ytelsestesting.
Her er en kort liste over noen førsteklasses verktøy for ytelsestesting:
Ytelsestesting er generelt likt på tvers av operativsystemer. Mange av verktøyene for ytelsestesting på Mac kjører på Windows.
Avsluttende tanker
Ytelsestesting er en uunnværlig del av arbeidet med å sikre programvarens pålitelighet og effektivitet, spesielt for SaaS-selskaper som opplever rask vekst. Ved å bruke de beste verktøyene får QA-ledere uvurderlig innsikt i systemenes skalerbarhet, utholdenhet og evne til å håndtere høy trafikk. Abonner på nyhetsbrevet vårt for mer innsikt fra fagfolk innen kvalitetssikring!



