Lasttester för e-handel – varför och hur?

En del i utvecklingen av en applikation eller en webbsida är att testa så att koden fungerar som den ska och upptäcka eventuella fel och buggar innan produkten når kunden. Man vill till varje pris undvika att slutanvändaren blir den som hittar buggar och fel. Det här är de flesta företag ganska duktiga på idag. Tester ingår som en del i arbetet som utvecklare.

Däremot är fortfarande last- och prestandatester av applikationer och webbsidor ännu inte en självklar del av arbetet i många fall.

Varför lasttestar man?

Lasttester kan hjälpa till att identifiera problem - både vad gäller prestanda och stabilitet - i ett tidigt utvecklingsskede. Att applikationens svarstid är utmärkt när man testar koden på sin egen dator betyder inte automatiskt att den är det när produkten ligger på kundens server och utsätts för tusentals samtida anrop. Ju tidigare man börjar lasttesta under utvecklingsfasen desto billigare blir det att rätta till de flaskhalsar i prestandan som upptäcks.

Ett lasttest testar prestandan på hela systemet, inte bara mjukvaran. Det gör att man kan upptäcka fysiska flaskhalsar som t ex bandbredd, CPU, minne mm och åtgärda bristerna långt innan man släpper in fysiska användare i systemet. Då kan man undvika servrar som blir överlastade, felmeddelanden som visas för användarna och andra fel som kan inträffa och leda till missnöjda användare. Missnöjda användare kan leda till förlorade affärer. Upplevs webbsidan eller applikationen som långsam eller instabil kan det leda till att kunderna söker sig till någon konkurrent.

Hur lasttestar man?

Att lasttesta eller prestandatesta (jag ska definiera vad som är vad senare i artikeln) innebär att man utsätter applikationen eller webbsidan för en simulerad last av flera samtida användare som genomför realistiska aktiviteter. Man kan hitta statistik på vanliga beteendemönster via till exempel Google Analytics, eller så studerar man och tar tid på användare som genomför olika uppgifter för att hitta så realistiska användarmönster som möjligt. 

Man bör också köra sina tester i en miljö som är så lik en produktionsmiljö som möjligt för att få en rättvis bild. Allra helst ska man köra testerna i produktionsmiljön för att få de verkliga förhållandena, men till exempel en staging- eller testmiljö kan också fungera. Då bör man se till att prestandan på servrarna motsvarar de i produktionsmiljön.

Med utgångspunkt från hur en vanlig användare förväntas bete sig när den besöker webbsidan eller applikationen sätter man sedan ihop flera scenarion att använda för sina lasttester. Man bör skapa upp scenarion som täcker upp alla funktioner på webbsidan eller i applikationen. Det kanske inte är möjligt att manuellt skapa upp tester som går in på varje enskild produktsida i en webbshop. Då finns möjligheten att skapa upp skript som stegar igenom en produktlista som man fått fram direkt från produktdatabasen. Man får inte heller glömma att ta med mindre besökta delar i testerna. Kanske har du en sida med kontaktinformation och stora bilder på medarbetarna som tar onödigt lång tid att ladda?

Prestandatester

Först vill man ta reda på vilken prestanda systemet har vid ett givet antal användare. Hur många användare förväntar man sig att webbsidan eller applikationen ska klara av? Hur långa blir svarstiderna då? Uppstår andra problem med hårdvaran eller mjukvaran? Redan här kan man hitta punkter som måste åtgärdas. Kanske systemet inte alls klarar det antal användare som beräknat?

Lasttester

När man hittat systemets prestanda och åtgärdat de eventuella flaskhalsar som upptäckts är det dags att börja pressa systemet för att avgöra var gränserna går. Då prestandatester oftast är kortare, mer specifika tester av olika delar av webbsidan eller applikationen ska ett lasttest visa hur kapaciteten för hela systemet är under en längre tid. Ibland kör man lasttester under flera timmar eller till och med flera dygn. Man vill köra ett så stort antal testcykler som möjligt för att få fram bra genomsnittliga värden. Lasten kan antingen vara konstant, varierande eller långsamt stegrande.

Vanligast i början är att starta med ett lågt antal virtuella användare för att sedan långsamt stega upp tills man når den nivå där prestandan börjar påverkas negativt. Klarar systemet det kan man lägga en konstant last runt den högre nivån under en längre tid för att hitta eventuella fel som kanske inte visar sig direkt. Under längre tester, t ex över en helg, kan det vara lämpligt med ett varierande antal virtuella användare för att testet ska vara mer realistiskt. Till exempel kan man variera antalet användare mellan en förväntad lägstanivå och en förväntad högstanivå.

Under lasttester kan man hitta mindre vanliga fel. Till exempel kan man här upptäcka hur systemet beter sig under tider då man normalt inte är på kontoret och manuellt kan övervaka systemet. Kanske körs ett backupjobb nattetid som gör att serverns kapacitet sjunker drastiskt? Kanske är det någon annan schemalagd aktivitet som påverkar?

Stresstester

Stresstester, som är en form av extremt lasttest, innebär att man lägger på en last som är på gränsen till vad systemet klarar av. Man vill med ett sådant test se vad som händer med systemet i ett worst case scenario. Till exempel när en rea startar vid en viss tidpunkt och besökarantalet på kort tid ökar kraftigt. Klarar systemet av en sådan tillströmning av besökare eller går systemet ner? Känner man till begränsningarna kan man förebygga problemen, till exempel genom att öka hårdvarans prestanda eller stänga av delar av webbsidan för att avlasta servern då man förväntar sig en kraftig ökning av antalet användare.
Under stresstester är det viktigt att noga övervaka systemet så inget går sönder. Ett stresstest sätter ofta oerhörd press på systemet så det är inte ovanligt att hårdvaran blir överhettad eller att andra tekniska fel uppstår. Är det flera kunder som delar på samma hårdvara måste man vara medveten om hur de kan bli påverkade av testerna.

lasttest_graph.png

Målet med lasttester

Det finns tre tydliga mål med att lasttesta sin produkt innan leverans till kunden. 

Det första målet är att hitta fel i produkten innan kunden gör det och på så sätt spara tid och pengar. Ju tidigare felet upptäcks, desto billigare blir det att åtgärda det. Ett lasttest kan leda till att fel uppstår som annars förblivit oupptäckta innan leverans.

Det andra målet är att tå reda på om hela systemet uppfyller kundens krav på prestanda och vad den högsta belastningen på systemet är. Om kunden betalar för en svarstid på max 3 sekunder vid 1000 samtida användare måste vi veta att systemet klarar av en sådan belastning.

Det tredje målet med lasttester är att se hur systemet klarar sig under en längre tid av användande under normal eller högre last. Uppstår det problem med minne, lagringsutrymme, databas etc över tid? Lasttester som pågår över flera dagar kan också visa på problem med bandbredd, lastbalansering, innehållsleverantörer och annat.

Kundnytta

Nyttan med att lasttesta produkten innan driftsättning borde vara uppenbar. Har man aldrig testat systemets kapacitet kan man omöjligt veta om den kommer att fungera med det antal besökare som kunden förväntar sig. Har man som leverantör lovat att systemet ska kunna klara 1000 samtida användare måste man med säkerhet veta att det verkligen är så. När systemet redan är i drift är det oftast för sent att lösa prestandaproblemen utan att kostnaderna skenar iväg. Ju tidigare man börjar lasttesta, desto billigare blir det att åtgärda flaskhalsar och prestandaproblem.