Onlangs stond er een performance test gepland voor een systeem bij mijn opdrachtgever. Men wilde weten of er tijdens de test vertraging merkbaar was in de GUI (Graphical User Interface) van dit systeem. Ofwel; of een gebruiker hinder zou ondervinden van een grote load op het systeem. Standaard performance testen leveren doorgaans alleen cijfers van de metingen. Met deze test wilde men een stap verder gaan en in de praktijk zien wat het concrete effect was van een hoge server load op de gebruikerservaring. Om dit te realiseren waren er echter de nodige uitdagingen.
Twee struikelblokken
Het eerste idee was om tijdens de performance test ‘echte’ gebruikers in te zetten. Dit was echter praktisch niet haalbaar vanwege het tijdstip van de performance test (altijd in de avonduren) en de inrichting van een ruimte waar de gebruikers dan zouden konden zitten. Het tweede idee was om het te automatiseren. Hiermee wordt gesimuleerd hoe het examen in de user interface wordt afgenomen en wordt niet puur naar de calls naar de backend gekeken. Een heel goed idee alleen waren er twee struikelpunten: budget en kennis.
De test automatiseren was budgettechnisch dus ook geen optie. De kennis om de client te automatiseren was er ook niet. Ik was de enige tester met kennis van selenium en programmeren dus heb ik aangeboden om dit binnen twee weken (want dan begon de performance test) te realiseren. Naast de performance test zouden mijn nog te automatiseren scripts voor de respons in GUI draaien. De performance testen waren gericht op de performance van de servers en niet zozeer op de GUI.
Het hele proces van een examen afnemen was niet zo’n complexe situatie. Je meldt je aan. E-mailadres invullen en gaat dan door 65 vragen heen. Omdat het voor deze situatie niet ging om of je nou wel of niet geslaagd zou zijn heb ik met een simpele loop alle vragen beantwoord. Waarbij de tijd waarop het antwoord werd gegeven wel gerandomiseerd was.
Selenium
Iedereen die Selenium wel eens heeft gebruikt kent ook de Selenium IDE waarbij je met een plug-in in Firefox je acties kunt opnemen. Maar dit moest in Chrome gedaan worden. Eerst is geprobeerd om op te nemen in Firefox en dan in Chrome af te spelen maar dit ging niet goed door de verschillende interpretaties van de browser op elementen. Hierna heb ik het geprobeerd met een (onofficiële) Chrome plug-in voor Selenium IDE. Dit werkte ook niet naar behoren en toen heb ik besloten om het te scripten zonder plugin. Dit is wat lastiger omdat je dan zelf naar de elementen in de pagina moet zoeken om je acties op uit te voeren maar uiteindelijk toch efficiënter (en leerzamer) dan het aanpassen van een opgenomen script.
Clients aansturen
Ik had in de testruimte de beschikking over vier clients die ik kon gebruiken voor de automatisering. Mijn eerste idee was om hiervoor een Selenium server te gebruiken met vier nodes. De nodes worden daarbij aangestuurd door de Selenium server. Je kunt dan de test remote uitvoeren op elke node waarbij elke client een node is. Na wat testjes met de server en de nodes ontdekte ik dat de Windows-installaties van twee clients zo ingeperkt waren dat het niet mogelijk was om deze te bereiken via de Selenium server. Een probleem, want als je geen nodes hebt, hoe moet je deze clients dan aansturen? Ik heb toen een andere (weliswaar wat minder mooie) oplossing bedacht waarbij ik executable jars op de clients heb gezet met een datafile waar Selenium zijn kandidaten uithaalde en deze gebruikte in de test.
Wat zou ik anders gedaan hebben?
Als ik wat meer tijd had gehad, dan had ik een aantal zaken zeker anders aangepakt. Zo zou ik de clients die ik niet kon bereiken via het netwerk vervangen zodat ik het netjes remote kon aansturen. Daarnaast had ik error logging willen uitbreiden om te kunnen zien waarom iets fout ging. Nu moest ik dit in een Java stack trace uitpluizen wat veel meer tijd kostte. Als laatste had ik liever meer variatie willen aanbrengen in de tests. Meer variatie in de antwoorden die werden gegeven, maar ook in de verschillende soorten examens die hadden afgenomen kunnen worden. Zo zouden de testen realistischer zijn.
Performance testing maatwerk
Op het moment suprême konden we zien dat de kandidaten geen hinder ondervonden van het feit dat de systemen onder grote druk stonden. In de GUI waren er tijdens de performance test geen haperingen te zien en werd er ook niet ervaren dat de GUI langzamer was. Eind goed al goed dus. Een interessant traject waarbij we door creatief om te gaan met de mogelijkheden en beperkingen van de klant de test met succes hebben kunnen afronden. Zo zie je maar, ondanks wat veel mensen denken is ook performance testing maatwerk.