Zuinigheid testen met TMAP: hoe efficiënt gebruikt software resources?

Wat is zuinigheid binnen TMAP?

Zuinigheid beschrijft de verhouding tussen de prestaties van een systeem en de resources die daarvoor nodig zijn. Bij prestaties gaat het bijvoorbeeld om de snelheid en het aantal verwerkte transacties. Resources zijn onder meer CPU-capaciteit, geheugen, database-I/O, opslag en netwerkverkeer.

Zuinigheid betekent niet dat software zo weinig mogelijk resources mag gebruiken. Een applicatie die nauwelijks capaciteit vraagt, maar gebruikers lang laat wachten, is niet efficiënt. Het gaat om een passende verhouding tussen snelheid, transactievolume en resourcegebruik.

De centrale vraag is daarom:

Hoeveel resources heeft het systeem nodig om het afgesproken prestatieniveau te halen?

Wat is het verschil tussen performance en zuinigheid?

Performance en zuinigheid worden gemakkelijk door elkaar gehaald. Toch leggen ze een ander deel van de softwarekwaliteit bloot.

Bij performance test je bijvoorbeeld of een applicatie binnen twee seconden reageert en duizend transacties per minuut kan verwerken. Bij zuinigheid meet je hoeveel CPU, geheugen, databasecapaciteit en netwerkverkeer nodig zijn om dat resultaat te halen.

Stel dat twee systemen allebei duizend transacties per minuut verwerken. Het eerste systeem gebruikt daarbij 80 procent van de beschikbare CPU-capaciteit. Het tweede gebruikt 40 procent. Voor de gebruiker presteren beide systemen hetzelfde, maar het tweede systeem gaat efficiënter met de beschikbare capaciteit om.

Een performancetest is daarom niet compleet wanneer je alleen naar responstijden en transactievolumes kijkt. Om zuinigheid te beoordelen, moet je die resultaten koppelen aan het gemeten resourcegebruik.

Voorbeelden van onzuinig resourcegebruik

Onzuinige software valt niet altijd direct op. De functionaliteit werkt en de responstijd blijft binnen de norm. Het probleem wordt vaak pas zichtbaar wanneer het aantal gebruikers stijgt of de cloudkosten oplopen.

Geheugengebruik blijft toenemen

Een applicatie geeft tijdelijk geheugen na gebruik niet volledig vrij. Tijdens een korte test merk je daar weinig van. Bij een duurtest zie je dat het geheugengebruik langzaam blijft groeien. Uiteindelijk is een herstart of extra capaciteit nodig.

Een zoekopdracht verwerkt te veel data

Een gebruiker zoekt één klant op, maar de applicatie leest een groot deel van de database. Het juiste resultaat verschijnt op tijd, waardoor de test functioneel slaagt. Achter de schermen voert het systeem echter veel meer werk uit dan nodig is.

Cloudresources schalen niet terug

Tijdens een piek start het platform automatisch extra containers. Zodra de drukte voorbij is, blijven deze containers actief. De applicatie blijft snel en stabiel, maar de organisatie betaalt voor ongebruikte capaciteit.

Een release gebruikt meer resources

Na een wijziging blijven de responstijden gelijk, maar gebruikt de applicatie 25 procent meer geheugen. Zonder vergelijking met de vorige release blijft deze verslechtering gemakkelijk onopgemerkt.

Hoe kun je zuinigheid meetbaar maken?

Een eis als “de applicatie moet efficiënt omgaan met resources” is te algemeen om te testen. Een bruikbare norm verbindt resourcegebruik aan een duidelijke hoeveelheid werk.

Mogelijke metingen zijn:

• CPU-gebruik per duizend transacties;
• geheugengebruik per gelijktijdige gebruiker;
• databasebewerkingen per bestelling;
• netwerkverkeer per API-aanroep;
• het aantal transacties dat één container kan verwerken;
• het herstel van resourcegebruik nadat een belastingpiek voorbij is.

Welke meting geschikt is, hangt af van het systeem. Bij een mobiele applicatie kunnen batterij- en dataverbruik belangrijk zijn. In een cloudomgeving kijk je eerder naar geheugengebruik, servercapaciteit en autoscaling. Voor embedded software kunnen CPU-capaciteit en beschikbaar geheugen doorslaggevend zijn.

Probeer daarom niet alles te meten. Kies de resources waarvan overmatig gebruik een werkelijk risico vormt voor het product.

Hoe test je zuinigheid met TMAP?

Binnen TMAP: Quality for Cross-Functional Teams is kwaliteit een gedeelde verantwoordelijkheid. Ook zuinigheid hoort daarom niet alleen bij een performancetester of operations engineer. Testers, developers, beheerders en de product owner bepalen samen welke prestaties nodig zijn en welk resourcegebruik daarbij acceptabel is.

Tip: Neem zuinigheid op in de Product Risk Analysis

Bepaal eerst of onzuinig resourcegebruik een relevant productrisico is. Dat is bijvoorbeeld het geval bij grote aantallen gebruikers, hoge transactievolumes, beperkte hardware of een cloudomgeving waarin extra capaciteit direct tot hogere kosten leidt.

Als het risico groot is, krijgt zuinigheid een expliciete plek in de testaanpak. Zo voorkom je dat het team pas na de livegang naar resourcegebruik kijkt.

Stel meetbare acceptatiecriteria op

Combineer in één criterium een prestatienorm met een grens voor resourcegebruik. Bijvoorbeeld:

Bij vijfhonderd gelijktijdige gebruikers wordt 95 procent van de transacties binnen twee seconden afgerond en blijft het gemiddelde geheugengebruik onder de afgesproken grens.

Hiermee voorkom je dat het systeem een performancenorm alleen haalt door steeds meer capaciteit in te zetten.

Meet resources tijdens bestaande tests

Zuinigheid vraagt niet altijd om een aparte test. Tijdens functionele tests, loadtests en duurtests kun je tegelijkertijd CPU-, geheugen-, I/O- en netwerkgebruik meten.

Vooral duurtests zijn belangrijk. Problemen zoals geheugenlekken en verbindingen die niet worden afgesloten, worden soms pas zichtbaar nadat de applicatie langere tijd actief is.

Gebruik een baseline per release

Leg het resourcegebruik van een stabiele release vast en vergelijk nieuwe versies daarmee. Zo zie je of dezelfde functionaliteit na een wijziging meer capaciteit nodig heeft.

Een baseline helpt ook wanneer er geen harde maximumwaarde bestaat. Een plotselinge stijging ten opzichte van de vorige release is dan voldoende aanleiding voor verder onderzoek.

Controleer het herstel na een belastingpiek

Meet niet alleen wat er tijdens de hoogste belasting gebeurt. Controleer ook of geheugen wordt vrijgegeven, verbindingen worden afgesloten en extra cloudcapaciteit weer wordt afgeschaald.

Een systeem dat goed opschaalt maar daarna niet herstelt, blijft onnodig resources gebruiken.

Zuinigheid, cloudkosten en duurzaamheid

Efficiënt resourcegebruik zorgt ervoor dat er meer capaciteit beschikbaar blijft voor groei en onverwachte pieken. Het kan bovendien voorkomen dat de organisatie onnodig betaalt voor extra servers, opslag of cloudcapaciteit.

Zuinigheid raakt ook aan duurzaamheid. Software die minder rekenkracht en infrastructuur nodig heeft om hetzelfde werk uit te voeren, gebruikt doorgaans minder energie. Daarmee heeft dit kwaliteitsattribuut zowel een technisch, financieel als ecologisch effect.

De test blijft echter hetzelfde uitgangspunt houden: meet welke resources nodig zijn om het gewenste prestatieniveau te leveren.

Zuinigheid leren testen met Testlearning

In de e-learning TMAP: Quality for Cross-Functional Teams leer je hoe je kwaliteitsattributen zoals zuinigheid vroegtijdig bespreekbaar en meetbaar maakt. Je leert hoe je samen met het hele team relevante productrisico’s herkent en vertaalt naar een passende testaanpak. Niet door ieder beschikbaar cijfer te verzamelen, maar door gericht te meten wat voor jouw systeem belangrijk is.