Systemet fungerte perfekt gjennom hele testperioden. Alle funksjonelle tester var grønne, akseptansetesten ble godkjent uten anmerkninger. Så kom lanseringsdagen, tusen brukere logget inn samtidig, og løsningen brukte førti sekunder på å vise forsiden.
Ingen hadde testet med mer enn ti samtidige brukere. Lanseringsdagen ble dermed den første reelle ytelsestesten, gjennomført i produksjon, med ekte kunder som testere og pressen som observatør.
Denne artikkelen forklarer hva belastningstesting og ytelsestesting er, hvilke testtyper som finnes, når i prosjektet de hører hjemme og hvordan du kommer i gang uten å gjøre det mer komplisert enn nødvendig.
Hva er ytelsestesting?
Ytelsestesting er samlebegrepet for tester som måler hvordan en løsning oppfører seg under belastning: hvor raskt den svarer, hvor mange samtidige brukere den tåler, og hva som skjer når grensen nås. Der funksjonelle tester sjekker om systemet gjør det riktige, sjekker ytelsestester om det gjør det raskt og stabilt nok.
Ytelsestesting er dermed verifiseringen av de ikke-funksjonelle kravene: svartid, kapasitet, stabilitet og skalerbarhet. Uten målbare krav å teste mot, blir ytelsestesting gjetting. Hvordan du formulerer slike krav, har vi beskrevet i artikkelen om funksjonelle og ikke-funksjonelle krav.
Testtypene: belastning, stress og utholdenhet
Belastningstesting: tåler løsningen forventet last?
Belastningstesting simulerer den trafikken du faktisk forventer: for eksempel 500 samtidige brukere som logger inn, søker og sender inn skjema. Målet er å bekrefte at svartidene holder kravene under normal og høy, men realistisk, belastning. Dette er minimumstesten før enhver lansering.
Stresstesting: hvor er knekkpunktet?
Stresstesting øker belastningen forbi det forventede, helt til systemet svikter. Poenget er ikke å ødelegge for moro skyld, men å vite hvor grensen går og hvordan systemet oppfører seg der: feiler det kontrollert med en tydelig melding, eller kollapser det og drar med seg andre tjenester?
Utholdenhetstesting: hva skjer over tid?
Utholdenhetstesting, ofte kalt soak testing, kjører normal belastning over lang tid, gjerne et døgn eller mer. Den avslører problemer som ikke synes i korte tester: minnelekkasjer, databaser som vokser ukontrollert og køer som aldri tømmes. Systemer som består en times test, kan fortsatt knele etter en uke i drift.
Når i prosjektet bør ytelsestesting skje?
Det vanlige svaret er «uken før lansering». Det er også det dyreste svaret. Da er arkitekturen låst, og et dårlig resultat gir bare to valg: utsette lanseringen eller krysse fingrene.
Ytelsestesting bør planlegges inn i teststrategien fra start, med definerte krav og et realistisk testmiljø. I smidige leveranser hører ytelsestester hjemme i testgjennomføringen sprint for sprint, i det minste for de mest kritiske flytene. Da oppdages ytelsesproblemer mens de fortsatt kan løses med kodeendringer i stedet for arkitekturomlegging.
Offentlige tjenester og finansløsninger har i tillegg forutsigbare topper: frister, lønningsdager, kampanjer. Testen må dimensjoneres for toppen, ikke for gjennomsnittet. En løsning som håndterer en vanlig tirsdag, sier ingenting om siste frist for innlevering.
Slik kommer du i gang i praksis
Start med kravene. Definer målbare terskler for de viktigste flytene: «innlogging under to sekunder ved 500 samtidige brukere» kan testes, «systemet skal være raskt» kan ikke.
Velg de fem viktigste brukerflytene og test dem først. Det er bedre å ha solide tall for innlogging, søk og innsending enn overfladiske tall for alt.
Sørg for realistiske testdata og et miljø som ligner produksjon. En ytelsestest mot en halvtom testdatabase gir falsk trygghet, samme felle som vi beskriver for integrasjonstesting: kunstige testmiljøer finner ikke ekte problemer.
Automatiser kjøringen, slik at ytelsestestene kan gjentas ved hver større leveranse. Ytelse er ferskvare. En endring i en database-spørring kan doble svartiden uten at noen merker det før neste test.
Ofte stilte spørsmål om belastningstesting og ytelsestesting
Hva er forskjellen på belastningstesting og stresstesting?
Belastningstesting sjekker om løsningen håndterer forventet trafikk innenfor kravene. Stresstesting presser løsningen forbi forventet trafikk for å finne knekkpunktet og se hvordan systemet svikter. Begge trengs: den første bekrefter hverdagen, den andre forbereder deg på unntaket.
Hvilke krav bør settes til svartid?
Det avhenger av flyten, men vanlige utgangspunkt er under to sekunder for sidevisninger og under ett sekund for søk og oppslag, målt ved forventet topplast. Viktigere enn tallet er at kravet er målbart og knyttet til et definert lastnivå, slik at testen kan gi et tydelig ja eller nei.
Trenger små løsninger ytelsestesting?
Ja, men i mindre skala. En enkel belastningstest av de viktigste flytene koster lite og avslører de groveste problemene, som manglende indekser eller trege integrasjoner. Omfanget bør stå i forhold til konsekvensen av nedetid, ikke til størrelsen på systemet.
Hva koster det å hoppe over ytelsestesting?
I verste fall en mislykket lansering med nedetid, tapte inntekter og omdømmetap, fulgt av hastearbeid for å redde løsningen. I Aspirias prosjekter i bank og offentlig forvaltning er ytelsestesting fast del av testløpet, nettopp fordi kostnaden ved å teste er en brøkdel av kostnaden ved å la være.
Test kapasiteten før kundene gjør det
Belastningstesting og ytelsestesting handler om å møte virkeligheten på egne premisser: definerte krav, realistiske tester og tid til å rette det som ikke holder. Alternativet er å la lanseringsdagen bli testen.
Trenger dere hjelp med å planlegge ytelsestesting, eller en testleder som har gjort det før? Ta kontakt med oss for en uforpliktende prat.