Leiderschap in de test: prestatietesten beheren

• Doelstellingen van prestatietesten
• Vier vereisten voor een prestatietest
• Hulpmiddelen voor prestatietesten
• Het proces van prestatietesten

Laten we beginnen.

Doelstellingen van prestatietesten

Als korte herhaling kunnen we de primaire doelstelling van prestatietesten als volgt definiëren:

“Aantonen dat het systeem volgens de specificatie functioneert, met aanvaardbare responstijden, terwijl de vereiste transactievolumes op een database van productiegrootte worden verwerkt.”

Je prestatietestomgeving is een testomgeving die kan worden gebruikt voor andere tests, met bredere doelstellingen, die we als volgt kunnen samenvatten:

• De groeicapaciteit van het systeem beoordelen (Als je niet zeker weet welke software aan je behoeften kan voldoen, kan onze lijst met de beste oplossingen voor databasebeheer je helpen.)
• Zwakke punten in de architectuur identificeren
• Het systeem afstemmen
• Onduidelijke bugs in software opsporen
• Veerkracht en betrouwbaarheid verifiëren.

Je teststrategie moet de vereisten definiëren voor een testinfrastructuur waarmee al deze doelstellingen kunnen worden bereikt.

Vier vereisten voor een prestatietest

"Als een van deze vereisten ontbreekt, wees dan zeer voorzichtig voordat je doorgaat met het uitvoeren van tests en het publiceren van resultaten. Het gebruik van automatiseringstools voor kwaliteitsborging kan helpen ervoor te zorgen dat aan deze vereisten wordt voldaan. De tests kunnen moeilijk of onmogelijk uit te voeren zijn, of de geloofwaardigheid van gepubliceerde resultaten kan ernstig tekortschieten en gemakkelijk ondermijnd worden."

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

1. Kwantitatieve, relevante, meetbare, realistische en haalbare vereisten

Als basis voor alle tests moeten prestatievereisten (doelstellingen) vóór de test worden overeengekomen, zodat kan worden vastgesteld of het systeem aan die vereisten voldoet. 

Vereisten voor systeemdoorvoer of responstijden moeten, om bruikbaar te zijn als uitgangspunt voor het vergelijken van prestatieresultaten, de volgende kenmerken hebben. Ze moeten:

• In kwantificeerbare termen zijn uitgedrukt.
• Relevant zijn voor de taak die een gebruiker wil uitvoeren.
• Meetbaar zijn met een hulpmiddel (of stopwatch) tegen redelijke kosten.
• Realistisch zijn in vergelijking met de duur van de gebruikertaak.
• Haalbaar zijn tegen redelijke kosten.

Vaak zijn prestatievereisten vaag of bestaan ze helemaal niet. Zoek eventuele gedocumenteerde vereisten op als dat mogelijk is. Als er hiaten zijn, moet je ze misschien achteraf documenteren. 

Voordat een prestatietest kan worden gespecificeerd en ontworpen, moeten vereisten worden overeengekomen voor:

• Transactieresponstijden.
• Belastingsprofielen (het aantal gebruikers en de te simuleren transactievolumes).
• Databasevolumes (het aantal records in databasetabellen dat naar verwachting in productie aanwezig zal zijn).

Het is gebruikelijk dat prestatievereisten in vage termen worden gedefinieerd. Deze vereisten zijn vaak gebaseerd op geschatte voorspellingen van bedrijfsvolumes; het kan nodig zijn om zakelijke gebruikers ertoe aan te zetten realistisch na te denken over prestatievereisten. 

Het kan ook nodig zijn dat je zelf een vereistenanalyse uitvoert en deze vereisten documenteert als de prestatiedoelstellingen. 

2. Een stabiel systeem

Als het systeem fouten bevat en onbetrouwbaar is, kom je met een prestatietest niet ver. Prestatietests belasten alle architecturale componenten in zekere mate. Maar om ervoor te zorgen dat prestatietests bruikbare resultaten opleveren, moeten het systeem en de technische infrastructuur van meet af aan redelijk betrouwbaar en veerkrachtig zijn.

3. Realistische testomgeving

De testomgeving moet zo worden geconfigureerd dat de test betekenisvol is. Je kunt het doel- of productiesysteem waarschijnlijk niet volledig nabootsen, maar de testomgeving moet geheel of gedeeltelijk vergelijkbaar zijn met de uiteindelijke productieomgeving. Je moet met de architect van het systeem overeenkomen welke compromissen aanvaardbaar zijn en welke niet, of op zijn minst welke zinvolle interpretatie aan de testresultaten kan worden gegeven.

Het creëren van een realistische testomgeving is essentieel voor betekenisvolle prestatests. Bekijk onze zorgvuldig samengestelde selectie van softwaretestplatforms voor tools waarmee je realistische omstandigheden kunt simuleren.

4. Gecontroleerde testomgeving

Prestatietesters hebben stabiliteit nodig. Niet alleen wat betreft de betrouwbaarheid en veerkracht van hardware en software, maar ook wat betreft het beperken van wijzigingen in de omgeving of de software die wordt getest. Als de interface bijvoorbeeld zelfs maar enigszins wordt gewijzigd, zullen testscripts die zijn ontworpen om gebruikersinterfaces aan te sturen waarschijnlijk onmiddellijk mislukken.

Alle wijzigingen in de omgeving moeten strikt worden gecontroleerd. Als de wijziging fouten oplost die waarschijnlijk geen invloed hebben op de prestaties, kun je overwegen de release niet te accepteren. Alleen wijzigingen die bedoeld zijn om de prestaties of betrouwbaarheid te verbeteren, zouden mogen worden geaccepteerd.

Toolkit voor prestatietests

Je toolkit voor prestatietests bestaat uit vijf belangrijke tools:

• Testgegevens aanmaken/onderhouden - om de grote hoeveelheden gegevens in de database aan te maken die voor de test nodig zijn. We verwachten dat dit een op SQL gebaseerd hulpprogramma is, of misschien een pc-gebaseerd product zoals Microsoft Access, dat is verbonden met je testdatabase.
• Belasting genereren – de gebruikelijke tools gebruiken testdrivers die virtuele clients simuleren door HTTP-berichten naar webservers te sturen.
• Tool voor het uitvoeren van applicaties – deze stuurt een of meer instanties van de applicatie aan via de browserinterface en registreert metingen van responstijden. (Dit is meestal dezelfde tool die voor het genereren van belasting wordt gebruikt, maar dat hoeft niet zo te zijn).
• Bronbewaking - hulpprogramma's die systeembronnen van clients en servers, netwerkverkeer, databaseactiviteiten enzovoort bewaken en loggen.
• Resultaten analyseren en rapporteren - tools voor het uitvoeren van tests en het bewaken van bronnen genereren grote hoeveelheden resultaatgegevens voor analyse.

Gerelateerd artikel: DE 10 BESTE SQL-ANALYSEDIENSTEN VOOR QA-TEAMS

Het proces van prestatietests

Hieronder staat een afbeelding met een algemeen proces voor het testen en afstemmen van prestaties. Afstemming maakt niet echt deel uit van het testproces, maar is een onlosmakelijk onderdeel van de taak om de prestaties en betrouwbaarheid te verbeteren. Bij afstemming kunnen wijzigingen in de architecturale infrastructuur nodig zijn, maar deze mogen geen invloed hebben op de functionaliteit van het systeem dat wordt getest.

Nu bekijken we hoe je een prestatietest ontwikkelt, uitvoert, analyseert en erover rapporteert.

Stapsgewijze testontwikkeling

Testontwikkeling wordt meestal in vier fasen uitgevoerd:

1. Elk testscript wordt afzonderlijk voorbereid en getest om fouten op te sporen.
2. Scripts worden geïntegreerd in de ontwikkelversie van de werklast en de werklast wordt uitgevoerd om te testen of het nieuwe script compatibel is.
3. Naarmate de werklast groeit, wordt het testkader in ontwikkeling voortdurend verfijnd, worden fouten opgespoord en verholpen en wordt het betrouwbaarder gemaakt. Ook de ervaring met en vertrouwdheid met de tools neemt toe.
4. Wanneer het laatste script in de werklast is geïntegreerd, wordt de test als een “proefrun” uitgevoerd om te controleren of deze volledig herhaalbaar en betrouwbaar is en klaar voor de formele tests.

Tussentijdse tests kunnen nuttige resultaten opleveren

Uitvoeringen van de gedeeltelijke werklast en testtransacties kunnen prestatieproblemen aan het licht brengen. Tests met werklasten met een laag volume kunnen ook een vroege indicatie geven van netwerkverkeer en mogelijke knelpunten wanneer de test wordt opgeschaald. 

Lange responstijden kunnen worden veroorzaakt door een slecht applicatieontwerp en kunnen eerder door ontwikkelaars worden onderzocht en opgelost. Vroege tests kunnen ook gedurende langere perioden worden uitgevoerd als duurtests.

More Articles

• 13 beste AI-nieuwsbrieven voor ontwikkelaars om je in 2026 op te abonneren
• 14 voordelen van appbouwers zonder code voor snellere implementatie
• 17 belangrijkste voordelen van NoSQL-databases voor moderne applicaties

Testuitvoering

Testuitvoering vereist enige fasebegeleiding of coördinatie. U moet overleggen met de ondersteunende deelnemers die het systeem monitoren terwijl u tests uitvoert. Het team voor “testbewaking” kan verspreid zijn, dus u moet hen op de hoogte houden als de test soepel moet verlopen en de resultaten correct moeten worden vastgelegd.

Naast de coördinatie van de verschillende teamleden verloopt de uitvoering van prestatietests doorgaans volgens een vaste routine.

1. De database voorbereiden (indien nodig herstellen vanaf tape).
2. De testomgeving naar behoefte voorbereiden en de status ervan controleren.
3. De bewakingsprocessen starten (netwerk, clients en servers, database).
4. De belastingssimulatie starten en de systeembewaking observeren.
5. Als een afzonderlijke tool wordt gebruikt, start u wanneer de belasting stabiel is de tool voor het uitvoeren van applicatietests en het meten van de responstijd.
6. De test gedurende de volledige testduur nauwlettend bewaken.
7. Als de tools voor het uitvoeren van tests niet automatisch stoppen, beëindigt u de test wanneer de testperiode is afgelopen.
8. De bewakingstools stoppen en de resultaten opslaan.
9. Alle vastgelegde resultaten archiveren en ervoor zorgen dat alle resultaatgegevens veilig worden geback-upt.
10. Tussentijdse rapporten opstellen en met andere teamleden overleggen over eventuele afwijkingen.
11. Analyses en rapporten voorbereiden.

Het coördineren van verschillende teamleden tijdens de testuitvoering kan een uitdaging zijn. Stroomlijn dit proces door geavanceerde testbeheertools voor Jira te integreren, die functies bieden zoals realtime samenwerking en rapportage

Afstemming volgt doorgaans op het testen wanneer er problemen zijn of wanneer bekende optimalisaties mogelijk zijn. Als een test wordt herhaald, is het essentieel dat alle wijzigingen in de omgeving worden vastgelegd. Zo kunnen eventuele verschillen in systeemgedrag en daarmee in de prestatieresultaten worden gekoppeld aan de wijzigingen in de configuratie.

Als het gaat om het beheren van testgevallen voor prestatietests, kan software voor testbeheer een grote verbetering betekenen. Deze maakt een betere organisatie, het bijhouden en zelfs de automatisering van testgevallen mogelijk.

Als vuistregel is het verstandig om slechts één ding tegelijk te wijzigen, zodat verschillen in gedrag kunnen worden herleid tot de aangebrachte wijzigingen.

Resultatenanalyse en rapportage

Het meest gebruikelijke rapport voor een testrun vat deze metingen samen en vermeldt voor elke uitgevoerde meting het volgende:

• Het aantal metingen.
• Minimale responstijd.
• Maximale responstijd.
• Gemiddelde responstijd.
• Responstijd van het N-de percentiel (doorgaans het 95^e percentiel).

De tool voor het genereren van belasting uit uw gereedschapskist moet het aantal transacties van elk type gedurende de testperiode registreren. Door deze aantallen te delen door de duur van de test, verkrijgt u de daadwerkelijk behaalde transactiesnelheid of verwerkingscapaciteit. 

Het aantal transacties is de belasting die op het systeem wordt toegepast. Hierbij wordt ervan uitgegaan dat de verhoudingen van de uitgevoerde transacties overeenkomen met het belastingprofiel dat u probeert toe te passen.

De toegepaste belasting zou moeten overeenkomen met het gesimuleerde belastingprofiel - maar dat hoeft niet als het systeem traag reageert en transacties met verschillende snelheden worden uitgevoerd.

Doorgaans voert u een reeks testruns uit met verschillende belastingen. Gebruik de resultaten van een reeks tests om een grafiek te maken waarin de responstijd van een transactie wordt uitgezet tegen de toegepaste belasting.

Hulpmiddelen voor resourcemonitoring beschikken doorgaans over statistische of grafische rapportagemogelijkheden waarmee het resourcegebruik in de loop van de tijd wordt weergegeven. Uitgebreidere rapporten over resourcegebruik in verhouding tot de toegepaste belasting zijn zeer nuttig en kunnen helpen bij het identificeren van knelpunten in de architectuur van een systeem.

Veel succes!

Schrijf u in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de reeks online komen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen om dieper in te gaan op dit en andere onderwerpen. Gebruik onze exclusieve couponcode QALEADOFFER om $60 korting op de volledige cursusprijs te krijgen!

Gerelateerd artikel: SERVERMONITORINGSTATISTIEKEN OM BIJ TE HOUDEN VOOR DE SYSTEEMGEZONDHEID EN -PRESTATIES