De senaste 20 åren som jag har jobbat med prestandatester har området inte förändrats nämnvärt. Men på sistone jag har börjat skönja några trender som kommer att förändra sättet vi bedriver prestandatester på. Vilka det är, kan du läsa om i detta inlägg.
Initiativet för prestandatest brukar starta med att projektledaren känner att systemet skulle behöva verifieras innan driftsättning. Detta mindset hos beställaren innebär att prestandatest hamnar väldigt sent i utvecklingsprocessen. Faktum är att man med prestandatester i regel alltid hittar problem med kod, konfiguration eller miljö!
Att identifiera att man inte kan driftsätta klockan fem i tolv påverkar affären och gör ingen beställare glad. Försenad driftsättning och sena kodändringar medför ytterligare testinsatser och kostnader.
Men nu äntligen börjar vi gå mot att prestandatesta tidigare. Att unit-testa sin kod är självklart för utvecklaren. Men att verifiera att koden har bra prestanda har tidigare hamnat hos någon prestandatestare efter några månader. Idag finns det verktyg och kodspråk som stöder kodnära prestandatester. Trenden är att tidigarelägga testerna för att identifiera problem när de är ”top on mind” hos utvecklaren. Det gör det effektivt att hitta problem trots att testerna inte är särskilt realistiska när de körs i en utvecklingsmiljö. Men det kan ge svar på följande frågor:
Är min kod effektiv?
Är den skalbar?
Har den minnesläckor?
Detta är problem som i regel upptäcks först senare vid end-to-end prestandatester i ett integrerat system. Med fördel kan också dessa tidiga tester användas för att prova ut den bästa kodlösningen.
I ett modernt utvecklingsprojekt förändras testmiljön ofta. Ständiga leveranser av kod, ny konfiguration och förändrad miljö/plattform innebär att systemet inte har samma egenskaper särskilt länge. Prestanda kan försämras av att exempelvis nya diskar i databasen installeras, trådpoolen förändras eller att en ny funktion implementeras.
Trenden är enklare prestandatester körs i en automations-server (till exempel Jenkins, Bamboo eller TeamCity), precis på samma sätt som i automatiska tester. Detta gör att man kan se trender eftersom man jämför resultat mot tidigare utförda tester.
Chansen att åtgärda förbättras när man på morgonen få reda på att koden som checkades in igår i nattens test medförde en 23 procentig svarstids-försämring. Eftersom feedbacken kom så snart efter det senaste bygget vet man vems kod det gäller och vad som har införts.
Vi går stadigt mot allt mer komplicerade system med mängder av samband till och från interna och externa aktörer. Det medför att testmiljöerna blir kostsamma att sätta upp och driva. Samband stubbas av eller i värsta fall undviks att testas överhuvudtaget. Datamängd och variation skiljer sig också ofta mot produktion. Osäkerheten och risken ökar att kunder drabbas negativt av driftsättningen.
För att undvika detta är trenden att låta användare nyttja den nya koden/miljön i produktion med hjälp av Feature Flags eller Feature Toggle (exempelvis Canary Releasing eller A/B testing). Men när detta implementeras måste man skaffa sig inblick i användarnas upplevelse och det görs bäst med verktyg som APM (Application Performance Monitorering). Där loggas varje transaktion och rapporteras i form av svarstider som kan larmsättas.
Jag rekommenderar att tillsätta en grupp med personer från verksamheten, drift och prestandatest som genomför ”Performance Feedback” inför varje påsläpp av nya användare eller ny kod/funktion. APM-verktygen visualiserar data utifrån ditt behov eller din roll och används som informationskälla för beslut, felsökning och testansatser.
I och med att systemen strävar efter att bli mer ihopkopplade ökar svårigheten att förutse vad som kommer hända vid avbrott eller exempelvis en fördröjning i någon av komponenterna i kedjan. Trenden går mot att utveckla modulärt i form av mikrotjänster (Micro Services, MSA) samt att nyttja moln i olika former vilket också leder till i viss mån minskad kontroll.
För att säkerställa att systemet är motståndskraftigt och stabilt används tekniker som Chaos Engineering eller Resilience Engineering för att simulera tillstånd i miljön med syftet att bygga bort dessa svagheter i systemet innan de inträffar.
Vad händer om vi inför en fördröjning på exempelvis 10 sekunder mot ett samband eller om en databasnod tas ner under last? Detta är svårt att förutse, och det bör testas.
Tidigarelagda prestandatester, automatisering av prestandatester, test i produktion och experimentera fram en stabil miljö - oavsett vilken eller vilka trender som blir verklighet, så har vi en spännande framtid framför oss, som kommer förändra det sätt vi säkerställer systemen. För vi behöver alltid se till att kunderna inte skall drabbas negativt, oavsett med vilken teknik, vilken frekvens och vilken hastighet vi levererar.