Leiderschap in testen: servicetesten
Noot van de redactie: Welkom bij de serie Leiderschap in testen van softwaretestexpert & consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring—vooral degenen in agileteams—te helpen uitblinken in hun rol als testlead en manager.
In het vorige artikel bekeken we de veranderende rol van testers en hoe je betere samenwerking met je collega’s kunt bevorderen. In dit artikel gaan we dieper in op de ins en outs van het testen van de prestaties, betrouwbaarheid en beheerbaarheid van een webapplicatie. Oftewel: servicetesten.
Meld je aan voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de serie verschijnen. Deze posts zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen voor een diepere behandeling van dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER om $60 korting op de volledige cursusprijs te krijgen!
Hallo en welkom bij een nieuw hoofdstuk in de serie Leiderschap in testen. Deze week kijken we naar servicetesten voor webapplicaties. We behandelen:
- Wat is servicetesten?
- Wat is prestatietesten?
- Betrouwbaarheids-/failovertesten
- Servicemanagementtesten
Laten we beginnen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Wat is servicetesten?
De kwaliteit van de service die een webapplicatie biedt, kan worden gedefinieerd als al haar kenmerken, zoals functionaliteit, prestaties, betrouwbaarheid, bruikbaarheid, beveiliging enzovoort.
Voor onze doeleinden hier splitsen we echter drie specifieke servicedoelstellingen af die vallen onder het onderzoek van wat we ‘servicetesten’ zullen noemen. Deze doelstellingen zijn:
- Prestaties: de service moet responsief zijn voor gebruikers en tegelijkertijd de belasting kunnen ondersteunen die erop wordt uitgeoefend.
- Betrouwbaarheid: als de service is ontworpen om bestand te zijn tegen storingen, moet deze betrouwbaar zijn en/of een service blijven bieden, zelfs wanneer er een storing optreedt.
- Beheerbaarheid: de service moet kunnen worden beheerd, geconfigureerd of gewijzigd zonder dat eindgebruikers een merkbare verslechtering van de service ervaren. Beheerbaarheidstesten, of operationele tests, zijn erop gericht aan te tonen dat procedures voor systeembeheer, management en back-up en herstel effectief werken.
In alle drie de gevallen moeten we gebruikersbelasting simuleren om de tests effectief uit te voeren. Doelstellingen op het gebied van prestaties, betrouwbaarheid en beheerbaarheid bestaan in de context van liveklanten die de site gebruiken om zaken te doen.
De responsiviteit (in dit geval de tijd die één systeemknooppunt nodig heeft om op het verzoek van een ander te reageren) van een site houdt rechtstreeks verband met de beschikbare resources binnen de technische architectuur.
Naarmate meer klanten de service gebruiken, zijn er minder technische resources beschikbaar om de verzoeken van elke gebruiker af te handelen en zullen de responstijden verslechteren.
Het is duidelijk dat een service die licht wordt belast minder snel zal uitvallen. Veel van de complexiteit van software en hardware bestaat om te voldoen aan de vraag naar resources binnen de technische architectuur wanneer een site zwaar wordt belast.
Wanneer een site wordt belast (of overbelast), moeten de conflicterende verzoeken om resources worden beheerd door verschillende infrastructuurcomponenten, zoals server- en netwerkbesturingssystemen, databasebeheersystemen, webserverproducten, objectaanvraagmakelaars, middleware enzovoort.
Deze infrastructuurcomponenten zijn doorgaans betrouwbaarder dan de speciaal ontwikkelde applicatiecode die de resource nodig heeft, maar in beide gevallen kunnen storingen optreden:
- Infrastructuurcomponenten vallen uit omdat applicatiecode (door slecht ontwerp of slechte implementatie) buitensporig veel resources vereist.
- De applicatiecomponenten kunnen uitvallen omdat de resources die ze nodig hebben niet altijd (op tijd) beschikbaar zijn.
Door typische en ongebruikelijke productbelastingen gedurende een langere periode te simuleren, kunnen testers fouten in het ontwerp of de implementatie van het systeem blootleggen. Wanneer deze fouten zijn opgelost, zullen dezelfde tests aantonen dat het systeem veerkrachtig is. QA’s kunnen gebruikmaken van tools voor belastingstesten om veel van de hieronder beschreven processen uit te voeren.
Bij alle services zijn er doorgaans een aantal kritieke beheerprocessen die moeten worden uitgevoerd om de service soepel te laten werken. Het kan mogelijk zijn om een service buiten de normale werktijden uit te schakelen voor regulier onderhoud, maar de meeste onlineservices werken 24 uur per dag.
De werkdag van de service eindigt nooit. Onvermijdelijk moeten beheerprocedures worden uitgevoerd terwijl de service live is en gebruikers op het systeem actief zijn. Deze procedures moeten worden getest terwijl het systeem wordt belast, om te garanderen dat ze geen negatieve invloed hebben op de live service—oftewel prestatietesten.
Wat is prestatietesten?
Prestatietesten vormen een belangrijk onderdeel van servicetesten. Het is een manier om te testen hoe een systeem presteert op het gebied van responsiviteit en stabiliteit onder een bepaalde werklast. Hieronder volgt een overzicht van hoe het werkt:
- Prestatietesten bestaan uit een reeks tests met verschillende belastingen, waarbij het systeem een stabiele toestand bereikt (belastingen en responstijden op constante niveaus).
- We meten de belasting en responstijden voor elke belasting, gesimuleerd gedurende een periode van 15-30 minuten, om een statistisch significant aantal metingen te verkrijgen.
- We bewaken en registreren de vitale kenmerken voor elke gesimuleerde belasting. Dit zijn de verschillende resources in ons systeem, bijvoorbeeld CPU- en geheugengebruik, netwerkbandbreedte, I/O-snelheden enzovoort.
We zetten een grafiek uit van deze verschillende belastingen tegen de responstijden die onze “virtuele” gebruikers ervaren. Wanneer we deze uitzetten, ziet onze grafiek er ongeveer uit zoals de onderstaande afbeelding.
Bij nulbelasting, wanneer er slechts één gebruiker op het systeem aanwezig is, heeft deze alle resources voor zichzelf en zijn de responstijden snel. Naarmate we de belastingen verhogen en de responstijden meten, worden deze geleidelijk slechter totdat we een punt bereiken waarop het systeem op maximale capaciteit draait.
Op dit punt is de responstijd voor onze testtransacties theoretisch oneindig, omdat een van de belangrijkste resources van het systeem volledig is verbruikt en er geen transacties meer kunnen worden verwerkt.
Terwijl we de belastingen verhogen van nul tot het maximum, bewaken we ook het gebruik van verschillende typen resources, bijvoorbeeld serverprocessorgebruik, geheugengebruik, netwerkbandbreedte, databasesloten enzovoort.
Bij de maximale belasting is een van deze resources voor 100% benut. Deze resource is de beperkende resource, omdat deze als eerste opraakt. Uiteraard zijn de responstijden op dit punt zodanig verslechterd dat ze waarschijnlijk veel trager zijn dan aanvaardbaar zou zijn.
De onderstaande grafiek toont het gebruik/de beschikbaarheid van verschillende resources uitgezet tegen de belasting.
Om de doorvoercapaciteit te verhogen en/of de responstijden van een systeem te verkorten, moeten we een van de volgende dingen doen:
- De vraag naar de resource verminderen, meestal door de software die de resource gebruikt efficiënter te maken (dit is doorgaans een verantwoordelijkheid van de ontwikkelaars).
- Het gebruik van de hardwareresource binnen de technische architectuur optimaliseren, bijvoorbeeld door de DBMS zo te configureren dat er meer gegevens in het geheugen worden gecachet of door sommige processen op de applicatieserver voorrang te geven boven andere.
- Meer van een resource beschikbaar maken. Normaal gesproken door processoren, geheugen of netwerkbandbreedte enzovoort toe te voegen.
Zoals je ongetwijfeld al begint te beseffen, hebben prestatietesten een team van mensen nodig om de testers te helpen. Dit zijn de technische architecten, serverbeheerders, netwerkbeheerders, ontwikkelaars en databaseontwerpers/-beheerders. Deze technische experts zijn gekwalificeerd om de statistieken te analyseren die door de resourcebewakingstools worden gegenereerd en om te beoordelen hoe de applicatie het best kan worden aangepast, of hoe het systeem kan worden afgestemd of geüpgraded.
Als je de tester bent, laat je dan, tenzij je zelf bijzonder deskundig bent op deze gebieden, niet verleiden om te doen alsof je deze statistieken kunt interpreteren en beslissingen kunt nemen over afstemming en optimalisatie. Je moet deze experts al vroeg in het project betrekken om hun advies en steun te verkrijgen en later, tijdens het testen, om ervoor te zorgen dat knelpunten worden geïdentificeerd en opgelost.
Houd het volgende artikel in de gaten, waarin we dieper ingaan op het beheren van prestatietesten.
Betrouwbaarheids-/failovertesten
Het waarborgen van de continue beschikbaarheid van een service is waarschijnlijk een belangrijk doel van je project. Betrouwbaarheidstesten helpen obscure fouten aan het licht te brengen die onverwachte storingen veroorzaken. Failovertesten helpen ervoor te zorgen dat de ingebouwde failovermaatregelen voor verwachte storingen daadwerkelijk werken.
Failovertesten
Wanneer sites veerkrachtig en/of betrouwbaar moeten zijn, worden ze doorgaans ontworpen met betrouwbare systeemcomponenten met ingebouwde redundantie- en failoverfuncties die in werking treden wanneer storingen optreden.
Deze functies kunnen onder meer bestaan uit uiteenlopende netwerkroutering, meerdere servers die als clusters zijn geconfigureerd, middleware en gedistribueerde servicetechnologie die load balancing en het omleiden van verkeer in storingsscenario's afhandelt.
Failovertesten zijn bedoeld om het gedrag van het systeem te onderzoeken onder geselecteerde storingsscenario's vóór de implementatie en omvatten normaal gesproken het volgende:
- Identificatie van de componenten die kunnen uitvallen en een verlies van dienstverlening kunnen veroorzaken (waarbij storingen van binnenuit worden bekeken).
- Identificatie van de gevaren die een storing kunnen veroorzaken en tot een verlies van dienstverlening kunnen leiden (waarbij bedreigingen van buitenaf naar binnen worden bekeken).
- Een analyse van de foutmodi of scenario’s die zich kunnen voordoen, waarbij u erop moet kunnen vertrouwen dat de herstelmaatregel werkt.
- Een geautomatiseerde test die kan worden gebruikt om het systeem te belasten en het gedrag van het systeem gedurende een langere periode te onderzoeken.
- Dezelfde geautomatiseerde test kan ook worden gebruikt om het systeem onder test te belasten en het gedrag van het systeem onder foutcondities te monitoren.
Een techniek genaamd Foutboomanalyse (FTA) kan u helpen de afhankelijkheden van een dienst van de onderliggende componenten te begrijpen. Foutboomanalyse en foutboomdiagrammen vormen een logische weergave van een systeem of dienst en de manieren waarop deze kan uitvallen.
Het eenvoudige schema hieronder toont de relatie tussen elementaire uitvalgebeurtenissen van componenten, tussentijdse uitvalgebeurtenissen van subsystemen en de bovenliggende uitvalgebeurtenis van de dienst. Uiteraard kunnen er meer dan drie niveaus van uitvalgebeurtenissen worden geïdentificeerd.
Deze tests moeten worden uitgevoerd met een geautomatiseerde belasting om het gedrag van het systeem in productiesituaties te onderzoeken en vertrouwen te krijgen in de ingebouwde herstelmaatregelen. In het bijzonder wilt u weten:
- Hoe gedraagt de architectuur zich in foutsituaties?
- Werken de voorzieningen voor taakverdeling correct?
- Vangen de overschakelmogelijkheden de belasting op wanneer een component uitvalt?
- Werkt automatisch herstel? Halen opnieuw gestarte systemen hun achterstand in?
Uiteindelijk richten de tests zich op het bepalen of de dienstverlening aan eindgebruikers behouden blijft en of gebruikers daadwerkelijk merken dat de storing optreedt.
Betrouwbaarheidstests (of duurtests)
Betrouwbaarheidstests zijn erop gericht te controleren of er onder belasting geen storingen optreden.
De meeste hardwarecomponenten zijn zo betrouwbaar dat hun gemiddelde tijd tussen storingen in jaren kan worden gemeten. Betrouwbaarheidstests vereisen het gebruik (of hergebruik) van geautomatiseerde tests op twee manieren om het volgende te simuleren:
- Extreme belastingen op specifieke componenten of middelen in de technische architectuur.
- Langdurige periodes van normale (of extreme) belasting op het volledige systeem.
Wanneer we ons richten op specifieke componenten, willen we de component onder druk zetten door deze bloot te stellen aan een onredelijk groot aantal verzoeken om de ontworpen functie uit te voeren. Het is vaak eenvoudiger om kritieke componenten eerst afzonderlijk met grote aantallen eenvoudige verzoeken aan een stresstest te onderwerpen, voordat een veel complexere test op de volledige infrastructuur wordt toegepast. Er zijn ook speciaal ontworpen stresstesttools om het QA’s gemakkelijker te maken het proces uit te voeren.
Duurtests zijn tests waarbij een systeem gedurende een langere periode, bijvoorbeeld 24 of 48 uur of langer, aan belasting wordt blootgesteld om (doorgaans) moeilijk te vinden problemen op te sporen. Onduidelijke fouten worden vaak pas zichtbaar na een langere gebruiksperiode.
De geautomatiseerde test hoeft niet noodzakelijkerwijs tot extreme belastingen te worden opgevoerd (dat wordt door stresstests afgedekt). We zijn echter vooral geïnteresseerd in het vermogen van het systeem om continu te blijven draaien met een brede variëteit aan testtransacties, om na te gaan of er moeilijk te vinden geheugenlekken, vergrendelingen of racecondities zijn.
Servicebeheertests
Tot slot nog een opmerking over servicebeheertests.
Wanneer de dienst in productie is geïmplementeerd, moet deze worden beheerd. Een dienst operationeel en beschikbaar houden vereist dat deze wordt gemonitord, bijgewerkt, geback-upt en snel wordt hersteld wanneer er iets misgaat.
De procedures die servicemanagers gebruiken voor het uitvoeren van upgrades, back-ups, releases en herstel na storingen zijn cruciaal voor het leveren van een betrouwbare dienst. Daarom moeten ze worden getest, vooral als de dienst na de implementatie snel zal veranderen.
De specifieke problemen die moeten worden aangepakt zijn:
- Procedures bereiken niet het gewenste effect.
- Procedures zijn onwerkbaar of onbruikbaar.
- Procedures verstoren de actieve dienst.
De tests moeten voor zover mogelijk zo realistisch mogelijk worden uitgevoerd.
Enkele punten ter overweging
Sommige systemen zijn gevoelig voor extreme belastingen wanneer een bepaalde gebeurtenis plaatsvindt. Zo zou een onlinebedrijf piekbelastingen verwachten vlak nadat het aanbiedingen op televisie heeft aangeprezen, of kan een nationale nieuwssite overbelast raken wanneer er een groot nieuwsverhaal uitbreekt.
Denk aan een systeem dat u goed kent en dat werd getroffen door ongeplande incidenten in uw bedrijf of in het nationale nieuws.
Welke incidenten of gebeurtenissen kunnen overmatige belasting van je systeem veroorzaken?
Kun je (of zou je) gegevens uit systeemlogboeken vastleggen die je het aantal uitgevoerde transacties geven? Kun je deze gebeurtenis opschalen om een kritieke gebeurtenis te voorspellen die eens in de 100 jaar of eens in de 1000 jaar voorkomt?
Welke maatregelen zou je kunnen nemen (of heb je genomen) om de kans op pieken, de omvang van pieken of beide te verkleinen, of om ze helemaal te elimineren?
Meld je aan voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de serie online komen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we van harte aanbevelen als je je verder wilt verdiepen in dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
Aanbevolen lectuur: 10 BESTE OPEN SOURCE-TOOLS VOOR TESTBEHEER
