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. Performance testing is een niet-functionele databasetest en kan Worden onderverdeeld 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 performance testing zijn belastingstest en stresstest.

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

Risicokwantificatie 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 risicokwantificering 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 aan de formele prestatieverwachtingen van opdrachtgever wordt voldaan. Zodoende kunnen de aanschaf van hardware, software en de bijbehorende cost of ownership worden geminimaliseerd. Deze specifieke requirement kan worden gecategoriseerd als een algemene eis voor bedrijfoptimalisatie en past binnen een LEAN aanpak.

Database belastingtest

Als onderdeel van de database performance test moet iedere database belastingtest een duidelijk doel hebben en moet gedocumenteerd worden.

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 moet worden opgenomen in de uiteindelijke testset zodat de invloed van dergelijke transacties op andere transacties kan worden vastgesteld.
3. De belangrijkere transacties die de kerndoelstellingen van de applicatie vormen. Deze testgevallen moeten worden opgenomen, aangezien een systeemfalen door overbelasting per definitie op deze transacties de grootste impact voor de organisatie heeft.
4. Ten minste één invoertransactie per databasetabel. De verwerking van dergelijke transacties moet worden onderscheiden van andere transacties zodat de impact op de performance vastgesteld kan worden.
5. Ten minste één wijzigingstransactie per databasetabel. De verwerking van dergelijke transacties moet worden onderscheiden van andere transacties zodat de impact op de performance kan worden.
6. Ten minste één rollback per databasetabel. De verwerking van een rollback moet worden onderscheiden van andere transacties zodat de impact op de performance vastgesteld kan worden.
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 stresstest

Stresstesten worden ook wel eens een marteling genoemd. De applicatie die wordt getest 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 tijdens het Stresstesten van databases worden vastgesteld 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 zo worden georganiseerd 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 moet in het testplan de methode voor het genereren van testdata worden vastgesteld.
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.

Discusseer mee op LinkedIn.

Boeken over dit onderwerp

-- Printbare PDF-versie --