“Performance testing is in general testing performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.”
Wikipedia is vrij duidelijk over de betekenis van performance testen. Maar is dit nog wel correct in de tijd van mobiele (native)applicaties en javascript waar veel van het werk bij de client zelf plaatsvindt? Moeten we de scope uitbreiden naar client-side performance of is de infrastructuur van de aanbieder zelf als basis voldoende? Wat zijn nog meer interessante onderdelen om mee te nemen naast de traditionele performance test. Verbreed je performance test, add some sauce to IT!
De soorten
Als je zoekt op performance testsoorten kom je veelvuldig dezelfde testsoorten tegen: (piek)loadtest, stresstest, duurtest, stabiliteitstest, slow-backend test. Allemaal gericht om het systeem van de aanbieder te controleren bij een bepaald loadmodel. Maar hiermee lopen we voorbij aan de daadwerkelijke klantbeleving. Vaak laait dan de discussie op over hoe lastig het wel niet is om te bepalen wat een gemiddelde klant is en hoe deze te simuleren. Niet geheel onterecht, want elke gebruiker is uniek en gebruikt een ander systeem en/of browser, wat allemaal van invloed is op de eindbeleving. Toch zijn er veel zaken die vanuit de front-end te controleren zijn en ervaring leert dat hier regelmatig performance verbeteringen kunnen worden behaald.
- Exploratory testing, verkennend testen, dit is vaak de eerste stap. Leer het systeem kennen, hoe voelt het systeem aan? Zijn er al onderdelen welke traag aanvoelen, ondanks dat je als enige gebruiker gebruik maakt van de omgeving?
- CPU, hoeveel CPU wordt er gebruikt bij het ophalen en renderen van de pagina’s. Hoog en lang CPU gebruik door de browser bij het laden van de pagina zal betekenen dat deze op relatief trage desktops lang kan duren.
- Geheugen, hoeveel geheugen wordt er lokaal gebruikt door de applicatie en wat is het garbage collection gedrag bij een javascript gebaseerde webapp. Wordt de heap netjes vrij gegeven wanneer een garbage collection plaatsvindt of wanneer je deze zelf initieert?
- Caching, worden statische objecten zoals CSS en images gecached en voor hoelang?
- F5 protectie/backend belasting, wordt de backend niet onnodig belast wanneer iemand onverhoopt met zijn voorhoofd op de F5 knop in slaap valt. Met andere woorden, vindt er geen onnodig/dubbel backend verkeer plaats.
- CNS breakdown, een CNS breakdown kan je een beeld geven over hoe de responstijd is verdeeld over de client, het netwerk en de server en geeft mogelijk een indicatie waar de meeste performance verbetering is te behalen.
- Slow/No-backend, hoe is de beleving met een trage backend of helemaal geen backend? Is de melding die de gebruiker krijgt logisch bij onbeschikbaarheid?
- First response en additionele rendering, hoelang duurt het voordat de eerste visuele feedback terug komt en is er nog veel rendertijd nodig na de laatst ontvangen data?
- Resources, zijn alle resources beschikbaar of vinden er regelmatig 404’s of 500-fouten plaats? Wordt compressie een keep-alive ondersteund?
Dit is een aantal van de punten die gecontroleerd kunnen worden vanuit de front-end. Sommige punten leunen tegen andere testsoorten aan, dus waak ervoor dat men geen dubbel werk gaat doen.
Vaker doen!
Bij mijn huidige opdracht wordt steeds meer aandacht besteed aan client-side performance en wordt een front-end/statische analyse uitgevoerd als onderdeel van het performance testtraject zelf. Voorbeelden van tools die hiervoor gebruikt kunnen worden zijn, Chrome DevTools, Wireshark, Compuware Transaction Trace en Fiddler. Door tijdsgebrek worden dergelijke analyses vaak niet uitgevoerd, maar de ervaring leert dat met deze methode regelmatig performance gerelateerde issues naar voren komen.
Ik ben van mening dat een front-end/statische analyse moet worden aangeboden als onderdeel van het performance testtraject (mits een front-end beschikbaar). Als performance engineer kijk je toch met een andere bril naar de applicatie. Verbreed je scope, add some sauce to IT!