Vanliga frågor om Prestandatest

Jag skulle sätta ihop en riskworkshop med produktägarna och prioritera. Ta med marknadsfolk som kanske vet hur den här ökningen kommer bli framöver så att du inte bara testar som det ser ut för närvarande. Ta även med folk från driften som vet vad deras farhågor är och hur systemet beter sig. Skapa sedan krav och testfall efter riskworkshopen, tänk riskbaserat och fokusera på de riskerna som är störst. Vi har ett blogginlägg som handlar om prestandakrav som du hittar här.

När det gäller prestandaverktyg så brukar det oftast inte spela någon roll om man testar applikationer som kör on-prem eller i molnet. Prestandatestverktyg fungerar lika bra för båda så det spelar inte så stor roll vilket verktyg man väljer. Om man har sin applikation i Azure är det naturliga valet kanske främst att använda JMeter, eftersom Azures egna lasttesttjänst i molnet använder JMeter. Ett annat stort känt verktyg som funnits länge på marknaden utöver JMeter är Loadrunner som också lämpar sig väl för prestandatestning. Ett nyare verktyg som senaste tiden blivit populärt är K6 som även det lämpar sig väl i uppgiften.

Val av Prestandatestverktyg beror också på hur man väljer att arbeta. Vill man jobba kodnära och skriva testfallen i kod (K6), eller föredrar man ett GUI baserat upplägg där man inte skriver testfallen i kod (JMeter).

Mer om verktyg vi använder i utvecklingsteam hittar du här

Inte jättemycket utifrån prestandatestdelen. Det viktiga är att mäta. När man har en prestandatestmiljö och man tror att den inte motsvarar vad man har i produktion, så måste man titta på var bristerna finns. Har man halva produktionsmiljön uppsatt i prestandatest så behöver man mäta och se att man får samma upplevd prestanda i den miljön. Vissa problem uppstår inte förrän man har en miljard rader i databasen och det kan vara svårt att återskapa i testmiljön, och vissa tröskelproblem kan bli svåra att testa. 

Det viktiga är att titta på sin produktionsmiljö i nuvarande version och se så att den matchar det vad man ser i prestandatestmiljön. 

- Hur många händelser, exempelvis köp eller sök ska systemet klara nu och i framtiden?  
- Hur många inloggare som har en session samtidigt, och hur lång svarstid får det vara?  
- Hur lång tid systemet ska kunna vara i drift, och det … vara ur drift också. För att om det blir fullt på disk, och minnet tar slut, så vad är acceptabelt?  

Ett trick är att vända sig mot kunden och hur låta den förklara hur den upplever situationen, så att man får kundens upplevelser. Tänk från en användares håll hela tiden, så är det nog lättare att få en förståelse.

Med prestandatest så är det så att man försöker köra många sessioner från en dator eller server och då skalar man i regel bort själva renderingen, för att det tar väldigt mycket kraft. Om du exempelvis skulle köra 100 samtida användare från en dator, så skulle det inte funka att rendera upp alla bilder och allting som browsers gör vilket gör att man skalar bort det. Det är så prestandatestverktygen fungerar.  

Men det finns verktyg som har den här möjligheten till att rendera saker, så att alla objekt kommer upp, så man får med alla svarstider, hela flödet så att säga. De är Loadrunner och Micro focus.

En best practise är att inte belastningstesta i produktion, eftersom man då kan sänka produktion. Man kan förbereda en process genom att förbereda systemet på vad som ska hända om man har en dålig prestanda, att till exempel rulla ut sin nya version av systemet till ett fåtal användare och testa där. Hur funkar det för dom.  
 
Man kan också ha bra backningsrutiner. Ser man att det inte fungerar eller att det på något sätt att ostabilitet i systemet så är det bra med backningsrutiner för att snabbt rulla tillbaka till senaste versionen som funkade bra.  
 
Mätbarheten är central, alla typer av AB-tester är bra att köra, släppa på kunder steg för steg. Kan du inte mäta om det är bra eller dåligt så får du ingen nytta av det.

Jag jobbar mycket med real user monitoring och då handlar det om att mäta vad användarna gör och hur. Vad som händer i klienten. Oftast i en browser eller mobilapp. Man går igenom ”Vad har vi för flöden? Vad är våra centrala användarfält? Vad är de viktigaste grejerna som bara måste funka?” Och bryter ner det till “Vad gör kunden?”. Troligen så har man redan marknadsverktyg som Adobeverktygen eller Google Insights, så där kan man återanvända mycket av den användarmappningen som man har gjort där kanske.  
 
Marknadsavdelningen är oftast väldigt tidiga på att identifiera användarfall och flöden, och bryta ner det därifrån och se till att de blir namnsatta på samma sätt, så att alla pratar samma språk. Man kan prata om faktiska flöden som till exempel ”I det här flödet så ser vi att det tar högre tid i steg tre”, och så vidare. Nu pratar jag mest om hur vi gör det för riktiga användare, och det handlar om att lägga in Javascript i browserapplikationer, som då plockar ut det. Antingen att du bygger det själv, eller att du tar något färdigt verktyg som gör det, likadant för mobilapparna, antingen lägger vi in mätpunkter själva i koden, eller så tar man in ett standardverktyg som gör det, halvautomatiskt i alla fall. 
 
Ur ett prestandatestperspektiv är det vanliga är att man under prestandatesten utför både belastning och att man mäter svarstiderna. Man kan dels se vilka svarstider man får tillbaka ifrån prestandatestverktyg men man kan också komplettera det om man har tillgång till ett bra verktyg, som till exempel appen Ataramex.  Det är ett bra komplement för att se vart flaskhalsar finns.

Det går faktiskt att hitta belastningsrelaterade problem utan att ha en produktionslik miljö. Till exempel så kan man hitta minnesläckage, trådproblematik och andra typer av stabilitetsrelaterade problem i en systemtestmiljö. Så att om man har de utmaningarna att inte kunna ha en testmiljö till exempel, så kan man börja med dem.  
 
Om man hittar de problemen i en systemtestmiljö så kommer de säkert finnas i en produktionslik miljö. Man kan då eventuellt verifiera kapaciteten genom att köra det nattetid eller att man stänger ner systemet för användarna och testar under en helg, eller någonting sånt där. Bara för att verifiera att det fungerar som man har tänkt.  

Många av de här enkla prestandaproblemen kan absolut upptäckas redan på en utvecklardator, så länge man trycker en last. Såna saker behöver inte ens komma upp i en prestandatestmiljö, eller de bör inte ens komma upp i prestandatestmiljön, de ska lösas innan. Kostnaden för att lösa något på en utvecklardator jämfört med att lösa det när man väl har kommit upp i prestandatestmiljö är en bråkdel av den. För att kunna testa så effektivt som möjligt så vill vi inte ens få upp den typen av problem i prestandatestmiljön, och absolut inte i produktion.

Jag tror att man behöver tänka på hur användarna kommer uppleva det här. Om du sitter som en manuell testare eller så och ser att det går långsamt helt enkelt bör du lyfta det. Förklara att vi behöver göra någonting mer åt det här, att vi inte kan ha de här långa svarstider,  att vi måste testa vad det är som tar lång tid och även lägga på en last.  
 
Man kan inte bara lämna över prestandatesttänket till en separat gruppering utan nu när vi jobbar mer agilt måste ansvaret över prestanda ligga på hela organisationen. Prestanda är inte något man bara testar i slutet utan något vi måste ha med från början. Går det långsamt redan i funktionstesterna behöver man lösa det redan då. Grejerna ska ut i drift och måste funka, det är inte bara att lägga över testerna till någon ansvarig på driften utan man vill få igång testtänket tidigt. Om det inte är någon som gör det, börja själv i ditt team.

Jag skulle nog säga att man börjar med API-anrop. Alltså, prestandatestar mot API-anrop som är baserade på vad användaren gör. API-anropare är oftast enklare att både få till till en början, men också enklare för ett team att göra. Är man på API-nivå så kan man göra komponentbaserade tester, i stället för att bygga upp ett end to end-test utifrån ett användarperspektiv, som då bygger på att man har en helintegrerad miljö. Så att jag skulle säga att om man vill börja med prestandatester, börja litet med ett begränsat scope. Kör mot era enskilda API:er om ni använder Microservices eller någon sån arkitektur. Och sen lära av misstagen, se om ni hittar några prestandaproblem och förbättra helt enkelt, jobba agilt.

Nej, inte alltid. Om det är en app som används av väldigt få användare så kanske det inte är nödvändigt. Men tänk riskbaserat. Vad händer om det inte fungerar? Det man även ska tänka på är att en prestandamätning oftast aldrig bara blir en, utan det man kommer fram till i prestandatesterna kommer säkerligen leta till att vi behöver konfigurera om systemet. Kanske till och med koda om, beroende på problemen man hittar. Därefter måste man köra om testerna för att se att det blir rätt effekt av de förändringarna man har gjort. Normalt sett så håller man på i veckor för att ändra, testa, ändra testa. Det är en process som pågår en stund i regel. 
 
Vad testar man för. Testar man för en lansering där man vet att man kommer få en väldigt stor användartillströmning, och sen aldrig kommer hända igen? De testerna blir ganska speciella, eftersom då testar du en händelse som kommer inträffa en gång. Då blir den dyr, men då måste den funka antagligen. Det blir sån stor impact om det inte funkar och då är det kanske värt det. Men i övrigt så behöver du kunna återanvända dina tester.

Du kommer inte ha samma överkapacitet som man i många fall har i en on-prem-miljö. Det blir för dyrt. En av syftena med molnmigrering är i många fall att spara pengar. Rätt storlek av miljön är en väldigt central punkt för all typ av molnmigrering så se till att hitta ett mellanläge, som inte kostar för mycket men som ger en rimlig användarupplevelse. Du vill kunna verifiera att molnmigreringen faktiskt har gett lyckat resultat, och inte ger en försämring i prestanda till exempel.

Det handlar om att göra det som man ofta kallar för shift left. Det bygger på att det som man vill deploy:a, exempelvis en komponent, att det team som äger det också äger testerna. Man delar då på ansvaret mellan ett centralt prestandatestteam till exempel, och ett utvecklingsteam som förvaltar den här komponenten.  
 
Om man har sitt prestandatest i en CI/CD pipeline som man kör när man till exempel merge:ar över sin branch, sin nya feature till develop-programmen, då kan man kontinuerligt se vilka förändringar som händer i prestandatestresultaten över tid. Man kan köra prestandatestarna lokalt, och även de-bugga komponenten som man prestandatestar helt enkelt.  
 
Det här möjliggör ett sätt att jobba med prestandatester i en agil utvecklingsprocess, eftersom man har flera team. Varje team förvaltar ett antal komponenter. Då man har sina prestandatester i teamen så kan man också tidigarelägga prestandatesterna, och möjliggöra att få med prestandatester i varje release snarare än att samla ihop alla komponenter, ta dem till en prestandatestmiljö och sen göra prestandatest.  
 
Det här möjliggör ett sätt att jobba med täta releaser och få in  prestandatester som ett agilt arbetssätt.

Det är svårt att svara på, det är väldigt beroende på vad det är för omfattning. En enkel webbsida kan man få igång rätt snabbt om man har inloggningsuppgifter och testfall. Man kan börja småtesta det redan efter ett par dagar men oftast handlar det om veckor när man ska skaffa testverktyg, sätta upp lastmaskiner, brandväggsöppningar och monitorering.  
 
Sen ska man även analysera resultaten och hittar man då problem får man köra det igen, och så vidare. Man kan komma igång snabbt men det är veckor vi normalt pratar om. 

Jag tycker att man kör här i samband med att man deploy:ar.  
Kör kontinuerligt och småskaligt så att man vet vad som händer, om det är någon ny förändring, något nytt incheckat, om det påverkar svarstider och andra problem i belastningen.  
 
Jobba småskaligt men kontinuerligt så att man inte bygger in några prestandahämmande grejer i koden. Kontinuerligt på samma sätt som man checkar in annan kod, och kör regressionstester. Man kan köra mer fullskaliga prestandatester varannan vecka, eller en gång i månaden.  
 
Då har man de småskaliga som kommer kontinuerligt, och sen lite större mer omfattande tester.

Trimma era rutiner och processer, och automatisera. Har man ett automatiskt sätt att hantera testdata, att man kör sina tester kontinuerligt i CI/CD på samma sätt hela tiden och har ett väl fungerande mönster, då kan man också se när det börjar gå fel och även pinpointa till varför det är problem i testmiljön hela tiden.  
 
Man hör ofta ”Ja, men det var testmiljöstrul”, försök hela tiden göra på samma sätt för de olika testerna och jobba enligt ett mönster helt enkelt. Det kan vara många anledningar till varför testmiljön strular, exempelvis att man uppdaterat ett system men inte gjort en ny produktionskopia ifrån produktionen för databasen. Det gör att det diffar mellan vilka databasscheman man har, kontra vilket data man har. 
 
Prestandatestmiljön måste underhåller enligt samma rutiner som alla andra miljöer. Om ett prestandatestteam äger prestandatestmiljön kommer den troligen att diffa. Men ingår den i samma pipeline som allt annat, så finns det större möjligheter att appen ser ut likadan.

Ja, nya system kan dra ut på tiden och man vill inte tappa kunder och affärer under tiden. Det är bra att någon plan för att förbättra det nuvarande om det är så att det finns ett prestandaproblem.  

: Tänk riskbaserat. Är det ett system som man tänker att man ska ha kvar i 2 år men inte uppdatera så mycket mer, då kanske risken är mindre. Om det fungerar bra och man ser att det funkar bra med APM-verktyg i produktion, minskar behovet av att aktivt jobba med prestandatester på det sättet. Den funkar bra med nuvarande last.

När man pratar om den miljön man testar så spelar det inte så stor roll vilka prestandatestverktyg man använder. Om man är ett utvecklingsteam som jobbar både med back-end och front-end, så finns det till exempel K6 som är ett Javaskriptbaserat verktyg. Gällande .net så är det inte jättemånga verktyg som är byggda i det men de flesta verktyg kan trycka last mot .net-miljö. Det är ingen skillnad i sig.