Database performance testing

Zoals de naam doet vermoeden heeft database performance testing weinig te maken met de werking van de applicatie als het gaat of de invulling van de functionele requirements. Database performance testing is een niet-functionele databasetest die we kunnen onderverdelen in verschillende categorieën die vaak terugvoeren naar de business requirements. Vereisten zoals het management die aan de systemen heeft gesteld zoals snelheid, robuustheid en dergelijke. Belangrijke onderdelen van database performance testing zijn belastingtest en stresstest.

De belastingtest en de stresstest kunnen we groeperen onder de noemer van prestatietesten. Ze dienen twee specifieke doelen als het gaat om Niet-functioneel databasetesten.

Risico kwantificering database performance testing

Kwantificering van risico’s met behulp van een risico analyse helpt de testers daadwerkelijk om de verschillende responstijden onder een maximaal niveau van belasting te bepalen. We moeten wel bedenken dat de belastingtest het risico niet direct verminderen, maar dat we door de processen van risico-identificatie en risico-kwantificering kansen creëren en impulsen geven om de risico’s te verkleinen.

Minimale Infrastructuur Requirements

Door middel van geformaliseerd performance testing kunnen we de minimale systeemconfiguratie bepalen. Met de minimale configuratie kan het systeem dat voldoen aan de Infrastructuur Requirements. Dat wil zeggen dat het systeem aan de formele prestatieverwachtingen van opdrachtgever voldoet. Zodoende kunnen we de aanschaf van hardware, software en de bijbehorende cost of ownership minimaliseren. Deze specifieke requirement kunnen we categoriseren als een algemene eis voor bedrijfsoptimalisatie en past binnen een LEAN aanpak.

Database performance belastingtest

Als onderdeel van de database performance test moet iedere database belastingtest een duidelijk doel hebben. We moeten dit goed documenteren.

De volgende testgevallen zijn een must voor een belastingtest en moeten in het database testplan worden opgenomen:

1. De meest gebruikte gebruikerstransacties. Ze kunnen de prestaties van alle andere transacties beïnvloeden als ze niet efficiënt zijn.
2. Ten minste één opvraag SQL query voor management informatie. Dit soort acties moeten we opnemen in de uiteindelijke testset zodat we de invloed van dergelijke transacties op andere transacties kunnen vaststellen.
3. De belangrijkere transacties die de kerndoelstellingen van de applicatie vormen. Deze testgevallen moeten we opnemen, aangezien een systeem-falen door overbelasting op deze transacties per definitie de grootste impact voor de organisatie heeft.
4. Ten minste één invoertransactie per databasetabel. De verwerking van dergelijke transacties moeten we onderscheiden van andere transacties zodat we de impact op de performance kunnen vaststellen.
5. Ten minste één wijzigingstransactie per databasetabel. De verwerking van dergelijke transacties moeten we onderscheiden van andere transacties zodat we de impact op de performance kunnen vaststellen.
6. Ten minste één rollback per databasetabel. De verwerking van een rollback moeten we onderscheiden van andere transacties zodat de impact op de performance kunnen vaststellen.
7. Ten minste één deadlock situatie per databasetabel. Als twee transactie op elkaar staan te wachten gaan beide niet verder. Welke impact heeft dat op de performance van andere transacties die wel doorgang kunnen vinden?
8. De meting van de responsetijden tijdens het gebruik van het systeem door een groot aantal virtuele gebruikers.
9. De meting van de effectieve tijden voor het ophalen van verschillende datatypes.

Belangrijke tools voor het testen van de database belasting zijn load runner, win runner en JMeter.

Database performance stresstest

Stresstesten noemen we ook wel eens een marteling. De applicatie die we testen wordt namelijk met enorm veel werk belast, zoveel dat het systeem op een gegeven moment niet meer werkt. Hierdoor kunnen we de knelpunten van het systeem identificeren.

Meest voorkomende problemen die we tijdens het Stresstesten van databases tegenkomen zijn:

1. De grote druk op het systeem gaat een rol spelen bij het bepalen van de status van de databasetransacties. Als de databasesoftware een verkeerd beeld heeft van de status van de transacties ontstaan meteen inconsistenties. De algehele procesplanning en -timing van de applicatie moeten we zo organiseren dat er zo min mogelijk tijd aan overhead verloren gaat.
2. Na het uitvoeren van een stresstest moet de oude testgegevens worden opgeruimd en ruimte maken voor nieuwe testgegevens. Vooraf moeten we in het testplan de methode voor het genereren van testdata vaststellen.
3. Een SQL-generator die geschikte SQL-query’s maakt voor de vereiste testgevallen is belangrijk. Het beheer van de SQL-query’s en het voortdurende onderhoud daarvan vormen een belangrijk onderdeel van het algehele testproces. Het SQL-query beheer is onderdeel van de algemene teststrategie en dient in het testplan te zijn beschreven.

De hierboven genoemde vereisten zorgen ervoor dat het opzetten van het database-testproces kostbaar en tijdrovend kan zijn. Er moet een goede balans zijn tussen kwaliteit en de totale duur van het projectsplan waarvan het testen van de database een onderdeel is.

Discussieer mee op LinkedIn.