Performance-testen, of prestatie-testen, is een van de vele testvormen waaraan applicaties[*] worden onderworpen om aan te tonen of ze aan de eisen van de opdrachtgever voldoen. Maar hoe bepaal je nou of de scope van deze testfase voldoende is? Welke testen voer je uit, welke klikpaden neem je erin op, hoe verdeel je de belasting op het systeem tussen gebruikersscenario’s en welke risico’s dek je dan daarmee af? Open deur, dacht ik. Totdat ik een kennisdeling organiseerde.
De kennisdeling was georganiseerd om herkenbaar gedrag bij bottlenecks te bespreken; om van gedachten te wisselen over de verschillende hints die gegeven worden vanuit het gedrag van de applicatie aan de oppervlakte. Denk hierbij bijvoorbeeld aan oplopende responstijden of een oplopend aantal fouten per tijdseenheid. Tijdens een korte introductie over performance-testen gaf ik aan waarop vaak de focus wordt gelegd bij het bestuderen van de resultaten. Vanuit mijn ervaring is dit de benodigde hardware: het resource-verbruik. Past de applicatie op de bestaande, eventueel gedeelde omgeving? Hoe verhoudt de nieuwe versie zich tot de oude? En: responstijden.
Ik beschreef een “recept” voor responstijd: processing, transfer (incl. latency), wait en bij de eindgebruiker: rendering. De eerste drie had ik ingekaderd als focus bij performance-testen. Dit kwam voort uit de gedachte dat de meeste performance-testtools meten vanaf het verzenden van het verzoek tot het respons volledig is ontvangen. Alleen die eerste drie dus. Maar hoe zit het dan met de performance van het renderen? Met gebruik van JavaScript (o.a. AJAX en JSON) wordt dat ook steeds interessanter, ook al is dit dan afhankelijk van de hard- en software bij de eindgebruiker.
De opmerking werd geplaatst dat je dit ook kan meten met een enkele gebruiker. Hiervoor hoeven de servers niet belast te worden. Zou dit niet al na functionele testen duidelijk moeten zijn? Uiteraard, als een systeem traag is, levert dit frustraties op en kunnen hier opmerkingen over gemaakt worden. Een functioneel tester let echter over het algemeen op functionele eisen en wordt niet gevraagd om performance-metingen te verrichten. De discussie maakte heel mooi duidelijk dat een performance-test niet altijd een loadtest hoeft te zijn, al hoor je deze termen wel veel door elkaar.
Wanneer je lange tijd achter elkaar load- en stress-testen uitvoert voor een specifieke omgeving, raak je gewend aan een manier van werken; standaard risico’s en testscenario’s. Er ontstaat een tunnelvisie binnen het veld waarin je werkt. Je raakt eraan gewend om het downloaden van afbeeldingen en resources wel of niet op te nemen in je test. Applicaties die steeds met dezelfde gebruikersscenario’s worden getest. Alle testen met dezelfde distributie. Ooit is daar wel eens iets over gezegd. Men gaat door op dezelfde weg, waar, als het goed is, de risico’s zijn afgewogen tegen de kosten en ervoor is gekozen voor de betreffende aanpak. Aannames!
Een goede performance-consultant is op de hoogte van de performance-risico’s die spelen binnen het kader waarin hij werkt en de gemaakte keuzes voor de dekking. Daarnaast blijft hij open voor bestaande risico’s erbuiten, wanneer een nieuwe situatie zich voordoet. In een andere omgeving kunnen wel eens totaal andere risico’s meespelen. Staat de server bijvoorbeeld in hetzelfde continent als (een deel van) de eindgebruikers? Hierbij kan het netwerk ineens een grote rol gaan spelen. Hoe belangrijk zijn de responstijden? In sommige gevallen is 15 seconden snel genoeg; in een ander geval zou de klant bij een verschil van 200ms voor een service al kunnen klagen, omdat daarmee de totale responstijd hogerop in de keten het maximum overschrijdt. Test je überhaupt de hele keten of slechts een geïsoleerd deel? Speelt rendering een grote rol voor de responstijd? Waar staat je test-infra eigenlijk opgesteld? Neem je de firewall wel of niet mee?
Wanneer je verder kijkt, komen er dus nogal wat vragen bij kijken. Wanneer is de scope van je testen dan voldoende? Scope wil zeggen dat je het geheel aan omgeving, situaties en gebruik in kaart hebt. Het gaat er dus om dat je weet welk deel je afdekt (in-scope), welk deel niet (out-of-scope) en: waarom! Zo kan je de omgevingsspecifieke risico’s herkennen en passend advies geven in de vorm van testscenario’s om die risico’s af te dekken. Je schijnt altijd het licht op slechts een gedeelte van het geheel. Het is aan ons als performance-consultants om de klant bewust te houden van de risico’s in de donkere hoeken, zodat zij weloverwogen de beslissing kunnen nemen welke acceptabel zijn en op welke vlakken het product zich nog vooraf aan productie zal moeten bewijzen.
[*]In ons geval. Zo worden performance-testen ook op hardware en -onderdelen uitgevoerd, bijv. auto’s e.a.
