Stresstest används normalt vid införandet av större systemförändringar eller kampanjer. I samband med dessa är syftet oftast att hitta övergripande flaskhalsar i systemet och vid behov öka t.ex. bandbredd eller antalet servrar. Här är vi istället intresserade av hur prestandan påverkas av inkrementella förändringar, t.ex. vid en sprint-release i ett agilt utvecklingsprojekt, och syftet är att hitta eventuella prestandaproblem och förbättringsmöjligheter i den bakomliggande koden. Detta görs lämpligen genom att jämföra mätetalen från lasttesten för de olika sprintarna.
Gör rättvisa jämförelser
Som vid alla typer av jämförelser är det dock väsentligt att inte jämföra äpplen och päron. En grundregel är därför att man bör ändra på så få parametrar som möjligt mellan två jämförande test. Detta kan vara svårt vid test av en e-handelssajt där både innehåll, layout, och funktionalitet ständigt utvecklas och uppdateras, men för att hålla nere antalet variabler finns det ett par saker som man bör tänka på.
Först och främst bör man se till att de användarscenarier som används är såpass generella att de kan användas under en längre period utan att dessa behöver ändras. Detta innebär t.ex. att man bör undvika att besöka sidor som hör till specifika kampanjer eller säsongsbetonade produkter och som därmed riskerar att falla bort ur sortimentet. Om man inte vill behöva förlita sig på att en viss produkt finns på sidan så är ett alternativ att låta testscriptet slumpvis välja en produkt bland dem som visas, men då bör man också vara beredd på att behöva hantera resultatet med statistiska metoder för att säkerställa att slumpmässigheten i sig inte påverkar resultatet.
Har man väl ett par stabila användarscenarier handlar det sedan främst om att isolera den variabel som vi vill testa. Vill vi testa hur en ny version av koden presterar i jämförelse med tidigare version så räcker det kanske inte att jämföra med testresultaten uppmättes vid föregående sprint. Risken är att eventuella skillnader som uppmäts istället har att göra med innehållsmässiga förändringar på sajten. För att undvika detta bör man därför se till att köra de tester man jämför både direkt innan och direkt efter en viss ändring införs.
Maximera informationen
I den här artikeln går vi inte in närmare på hur själva testet väl körs, utan detta förfarande är som sagt i princip identiskt med hur man gör ett stresstest, och som beskrivs i den andra delen av den här artikelserien. En praktisk skillnad är dock att man inte behöver lasta på systemet mer än det tål, utan att man istället bör lägga lasten i nivå med vad som kan anses vara ett normalt antal besökare. Testet kan därför normalt köras på dagtid utan att besökarna påverkas, och kan också med fördel köras i ett separat testsystem eftersom vi i första hand inte är ute efter några absoluta mätetal utan skillnader jämfört med tidigare körningar.
Som vi skrivit i de tidigare artiklarna så kan lastverktyget normalt ge information om laddtider för de olika sidor som besöks under testet, samt även mer detaljerad information om vilken typ av innehåll som står för vilken del av denna. I vissa fall erbjuds även möjligheten att ladda hem diagnossystem som övervakar själva servern under testet och ger information om t.ex. CPU-, minnes-, och bandbreddsåtgång.
Vill man få ut ännu mer information om vad som egentligen tar tid eller slukar resurser under testet är det bästa sättet ofta att bygga in verktyg för prestandamätning direkt i systemet som skall testas. På 3bits jobbar vi bland annat med profiling för att mäta exekveringstider för anrop till vissa funktioner, databaser, och/eller externa resurser. Vi jobbar också med system som Microsoft Application Insights som gör det möjligt att samla in och presentera ytterligare prestandarelaterad data. Dessa verktyg får vi kanske återkomma om i en separat artikel, men här nöjer vi oss med att konstatera att man inte är begränsad till de mätetal som ens lastverktyg erbjuder, utan kan få ut betydligt mer information om sitt system genom att själv se till att samla in exakt den information man är intresserad av.
Med detta avslutar vi vår artikelserie om lasttest. Har du några frågor eller kommentarer som rör artikeln eller test av programvara rent allmänt så är du varmt välkommen att höra av dig.
