Of, waarom je loadtests in je CI/CD-pijplijn moet opnemen
De eindeloze belastingstest, het klinkt als de titel van een horrorfilm waar niemand ooit om gevraagd heeft. Waarschijnlijk is een betere manier om naar dit onderwerp te kijken: Belasting testen terwijl je slaapt. Het is algemeen bekend dat hoe eerder je een defect ontdekt dat de prestaties, doorvoer en/of stabiliteit schaadt, hoe gemakkelijker het te verhelpen is. Mijn ervaring is dat 70% tot 80% van de problemen die ik aan het licht heb gebracht tijdens loadtests reproduceerbaar zijn op veel lagere schalen. Het is veel minder pijnlijk (en minder duur) om met zulke bugs om te gaan tijdens het testen met 20-500 virtuele gebruikers dan tijdens uw seizoensgebonden belastingstests waarbij mogelijk tienduizenden tot honderdduizenden virtuele gebruikers worden gebruikt.
Je voert al functionele tests uit als onderdeel van uw releasecycli (toch?), dus die een stap verder brengen naar belastingtests is eenvoudiger dan je denkt. Er zijn maar een paar dingen waar je rekening mee moet houden:
Houd het op schaal
Of je nu traditionele systeemspecificaties gebruikt zoals CPU cores en gigabytes RAM, of cloud-native services zoals Lambda, Aurora, containers as a service enzovoort, zorg ervoor dat je testomgeving geschaald blijft. Draai je 16 applicatieservers met een 32 core database? Dan zou je bijvoorbeeld kunnen streven naar 2 applicatieservers met een 4 core database. Gebruik je cloud-native diensten? Zorg er dan voor dat je capaciteit, doorvoerreservering enzovoort proportioneel schaalt in je ontwikkelomgeving.
Hergebruik testscripts
Weet je nog die geautomatiseerde functionele tests die je al uitvoert? Ga op zoek naar loadtesttools of -services die op dezelfde technologie zijn gebaseerd. Functioneel testen met JMeter? Gebruik JMeter dan ook voor jouw belastingtests. Echte browsers gebruiken vanuit Selenium-scripts? Daar zijn loadtestservices en opensourcetools voor. Een voorbehoud om te onthouden is dat de meeste grootschalige loadtests protocolemulatie gebruiken in plaats van echte browsers om redenen van middelen/kosten. Het is weliswaar vervelend om 2 smaken scripts te onderhouden, maar de kostenbesparingen kunnen dit rechtvaardigen.
Definieer je KPI’s en gebruik ze dan ook echt
KPI’s voor belastingtests kunnen genuanceerder zijn dan voor een functionele test, waarbij de resultaten zijn: of het werkte, of het werkte niet. Hoe weet je of je loadtests “werkten”? Probeer te beginnen met je productieomgeving als basislijn, denk na over KPI’s op basis van:
Aanvragen per minuut
Laadtijden voor pagina’s, klikacties en zelfs achtergrondacties die op het kritieke pad liggen (dit is een gebied waar echte browsertests een voordeel hebben met echte javascript engines etc. omdat alles automatisch wordt meegenomen in de test)
Vergeet niet om rekening te houden met verzoeken aan externe services en derde partijen of deze eruit te filteren, indien nodig.
Tot slot, maar zeker niet onbelangrijk, controleer je resultaten! Als de resultaten van je belastingtests in je releases naar het zuiden gaan, wil je de waarschuwingssignalen niet missen. Dit kan geautomatiseerde waarschuwingen vereisen op basis van de KPI’s die je hebt gedefinieerd. Het laatste wat je wilt is dat deze resultaten verdwijnen in het zwarte gat van de Inbox waar zoveel SLA-rapporten zijn gebleven.
Dit artikel is eerder gepubliceerd op LinkedIn.
