Load testing

Load testing – Performancetesten – Stress testen

Er bestaat nog al eens verwarring over wat load testing of performance testen nu precies is.

Feitelijk is performance testen een verzamelnaam van verschillende testtypen die als doel hebben een functioneel kloppende response van een softwaresysteem binnen een acceptabele tijd te verkrijgen. Een duidelijk gedefinieerde set van verwachtingen in termen van de prestaties van het systeem is essentieel bij performance testen. Voor bijvoorbeeld een webtoepassing moet u minstens weten wat de te verwachten belasting in termen van gelijktijdige gebruikers of HTTP-verbindingen is en wat een acceptabele responstijd betreft.

Als je eenmaal weet waar je wilt zijn, kan begonnen worden aan de zoektocht naar knelpunten bij het voortdurend verhogen van de belasting op het systeem.

Binnen performance testen zijn verschillende methoden te onderscheiden:

Load testen

Load testing is de meest toegepaste vorm van performance testen. Kan het systeem een gebruikersbelasting aan die reëel (normaal en piek) te verwachten is? Denk hierbij aan de hoeveelheid gebruikers die inloggen, schermen opvragen, op menu’-items en buttons klikken, etc. Wanneer de resultaten van de load testing aangeven dat de prestaties van het systeem niet voldoen aan de verwachte doelen, is het uiteraard tijd om ‘aan meerdere knoppen te gaan draaien’.

Volume testen

Kan het systeem een volumebelasting aan die reëel (normaal en piek) te verwachten is? Denk hierbij aan de hoeveelheid op te vragen data, aantal weg te schrijven records, etc.

Stress testen

Deze manier van performance testen heeft als doel het zoeken naar het breekpunt van een systeem. De stabiliteit van het systeem wordt hierbij getest. Bij welke belasting gaat het systeem onderuit en performt het helemaal niet meer. Dit breekpunt kan zo drastisch zijn dat het systeem definitief ‘onderuit gaat’.

Hierbij wordt getest met een zwaardere belasting dan gebruikelijk, waarbij gekeken wordt naar zaken als robuustheid, beschikbaarheid, foutafhandeling en recovery na zware belasting tot het punt waarop het systeem het begeeft. Het doel hiervan is na te gaan wanneer het systeem crasht als gevolg van bijvoorbeeld een gebrek aan systeembronnen, zoals RAM-geheugen, opslagcapaciteit, netwerkcapaciteit of meer dan normaal aantal gelijktijdige gebruikers. Op basis van de resultaten wordt daar waar nodig de capaciteit uitgebreid om zo de verwachte groei aan gebruikers te kunnen verwerken. Stresstesten worden bij voorkeur uitgevoerd op een ‘productie-like’ systeem, aangezien systemen niet lineair schalen en interpolatie van resultaten hierdoor een hoog risico op fouten geeft.

Gewaakt moet worden dat stresstesten uitgevoerd worden met slechts 1 scenario, daar deze aanpak weinig realistisch is. Een voorbeeld hiervan is het zoeken van één product welke een hoge systeembelasting veroorzaakt. Gebruikers zullen echter niet continu producten zoeken, maar ook in- en uitloggen, rondkijken op de site of order- en betalingshistorie bekijken. Een stresstest die de werkelijkheid beter benaderd, bestaat dan ook uit meerdere scenario’s. Daarnaast zijn er meer logins / gebruikersrollen en testdata benodigd voor de verschillende scenario’s.

Denial-of-service-aanvallen (dos-aanvallen) en distributed denial-of-service-aanvallen (DDoS-aanvallen) worden soms ook gezien als een stresstest, maar zijn dit niet. Het hoofddoel in dat geval is om een website, internetdienst of server ervan te weerhouden aanvragen van reguliere gebruikers te behandelen. Door het versturen van grote hoeveelheden verkeerd samengestelde data, raakt weliswaar de webserver overbelast, maar de achterliggende databases en systemen worden niet belast, iets wat bij een stresstest wel gebeurt.

Soak testen
Daar waar stress testen een tijdelijk piek simuleert, heeft soak testen het simuleren van een langdurige belasting als doel. Denk aan een reële belasting over een langere tijd. Dagen, weken, maanden. Lopen buffers niet vol, vinden er geen automatische maar ongewenste resets plaats na een x tijd, bezwijkt de hardware niet onder de langdurige belasting?

Concurrency testen
Hoeveel processen kunnen er tegelijkertijd draaien? 1000 gebruikers online op een webshop, zullen nooit tegelijkertijd gaan afrekenen in het winkelmandje. Maar vlak voor de deadline voor een voor een bezorging de volgende dag (dus bijvoorbeeld om 20:55 uur)  zullen misschien snel nog even 80 gebruikers een bestelling afronden. Kan het systeem 80 gelijktijdige betalingstransacties aan?

Scope en Plan van aanpak performancetesten

Voordat men overgaat tot performancetesten zijn scopebepaling en een plan van aanpak noodzakelijk. Als de scope en de requirements (omgeving, testscenarios, testdata, beheer, monitoring) bepaald is, wordt overgegaan tot het uitvoeren van een Proof of Concept (PoC). Voordat een PoC gestart kan worden, wordt eerst middels een testtoolselectie bepaald welke tool het meest geschikt is. Dit kan een Open Source of commerciële tool zijn, waarbij ook gekeken wordt naar reeds aangeschafte licenties. De meeste geschikte tool wordt gekozen op basis van diverse variabelen, waaronder de omgeving waarmee gecommuniceerd moet worden en beschikbaar budget (Licenties, consultancy, eventueel opleiding). Tijdens de PoC wordt bekeken hoe de tooling de performancetesten uitvoert en of dit tot het gewenste resultaat leidt.  De PoC kan tevens dienen als pilot, waarna bij positief resultaat alle benodigde omgevingen getest kunnen worden.

Meer weten over load testing en onze aanpak betreft performancetesten?

Praegus is expert op gebied in alle varianten binnen performancetesten en kent bij uitstek verschillende tools (Open Source en Commercieel) die hiervoor in te zetten zijn. Meer weten over performance testen, load testen of stresstesten? Neem contact op en we komen graag langs met onze specialisten om u op dit gebied te ontzorgen.