Een van de doelen van performancetesten is het verifiëren van de capaciteit van een systeem of applicatie. Dit wordt gedaan door het simuleren van gebruikers.
Wat wij merken is dat bij de klanten vaak onduidelijk is wat er precies getest moet worden. Wat doen die gebruikers die gesimuleerd worden? Welke functionaliteiten moeten er worden aangeroepen en hoe komen we aan die informatie?
Bij functionele testen worden doorgaans alle functionaliteiten getest, met de mogelijke grensgevallen die van belang zijn. Deze zijn af te leiden uit het functioneel ontwerp en via een methode als Tmap worden testgevallen gekozen op basis van een risico analyse. Afhankelijk van de complexiteit van een applicatie kunnen dit tientallen of honderden testgevallen zijn.
Voor het bepalen van de “testgevallen” bij performancetesten kan de volgende vuistregel worden aangehouden:
De volgende acties moeten worden gesimuleerd:
- De meest voorkomende acties; bijvoorbeeld het openen van de homepage, het inloggen in een applicatie, het openen van bepaalde overzichten of het uitvoeren van veelvoorkomende zoekopdrachten.
- De belangrijkste actie(s). Denk aan de betaalflow van een webshop. Het komt niet het meeste voor, maar het is wel essentieel dat deze goed presteert.
- Indien nodig: Acties die een grote impact op de betrokken systemen kunnen hebben; denk hierbij aan functionaliteit zoals het genereren van een jaarrapport, het uitvoeren van zware zoekopdrachten etc. Dit is uiteraard afhankelijk van het type applicatie.
Welnu, hoe bepaal je deze meest voorkomende acties? Hier zijn eigenlijk twee mogelijkheden:
- Het is een bestaande applicatie; hierbij kan geanalyseerd worden naar wat de huidige gebruikers in productie doen. Een goede bron zijn bijvoorbeeld productie logs. Denk hierbij aan een overzicht van aantallen pagina’s die worden geopend in een bepaalde periode. Een andere bron kan Google Analytics zijn, afhankelijk van de inrichting worden hier ook bepaalde pagina’s (kliks) van gebruikers gevolgd en kan worden geanalyseerd wat gebruikers doen op de applicatie(s).
Bij bepaalde type (order) applicaties kan ook gekeken worden naar het aantal orders wat in een bepaalde tijdsperiode wordt opgevoerd. - Er is geen informatie beschikbaar uit productie. Wellicht zijn er geen productie logs voorhanden, of er zijn simpelweg geen logs beschikbaar, omdat het een nieuwe applicatie is, die nog niet in productie draait. Hierbij is het dus van belang dat er een “educated guess” wordt gedaan naar het verwachte gebruik.
In een ideale wereld zou de performancetest al het gebruik vanuit productie simuleren. Echter vanuit uitvoerbaarheid, onderhoudbaarheid en kosten wordt er vaak gekozen om niet alle pagina’s of acties die gebruikers in productie doen te simuleren. Sommige pagina’s gebruiken bijvoorbeeld dezelfde technische functionaliteiten in het systeem of in een applicatie en zijn dus technisch gezien “dubbelop”. Andere pagina’s/functionaliteiten worden maar zo weinig uitgevoerd, dat het risico op performance problemen zeer laag is.
Daarnaast is de afweging tussen de functionaliteiten ook afhankelijk van het scenario wat gesimuleerd wordt. Bij een normale productie situatie kunnen er bijvoorbeeld zeer weinig nieuwe accounts worden aangemaakt, echter er zijn natuurlijk scenario’s denkbaar waarbij dit juist de meest voorkomende actie kan zijn.
Kortom, het bepalen van wat een gesimuleerde gebruiker moet doen tijdens een performancetest, wordt bepaald door (indien mogelijk) een analyse op productie uit te voeren, waarbij de vuistregels kunnen worden toegepast.
Door Paul de Waal
