Performance testen vinden vaak op een gedeelde test omgeving plaats waar meerdere applicaties draaien. Deze applicaties worden door verschillende teams en personen los getest (dan wel met stubs, dan wel met de hele keten erachter) om te zien of ze de requirements halen en live gezet kunnen worden. Doordat er veel gefocust wordt op de losse applicaties en het testen hiervan, wordt alle applicaties samen testen, op dezelfde omgeving, met dezelfde systemen en componenten zoals op de productieomgeving, haast nooit gedaan. Waarom? Omdat deze ‘combitest’ een hele grote test is die vaak onhaalbaar is.
Het nut van de combitest
Wel kan een combitest zeker een goede toevoeging zijn. Het kan namelijk zo zijn dat er gedeelde componenten zijn (denk aan firewalls, loadbalancers, databases, services, etc.), die het bij losse applicatie testen prima doen, maar als alle applicaties tegelijk onder load staan performance verslechtering of fouten kunnen geven. Om te kunnen verzekeren dat ook de gedeelde componenten naar behoren blijven werken als de totale load op de hele omgeving staat, kan het uitvoeren van een combitest een optie zijn. Uit eigen ervaring weet ik dat het helaas nog wel eens voor kan komen dat problemen met gedeelde componenten pas naar voren komen op productie en dat wil je voorkomen. Alleen wat komt er allemaal bij kijken om een combitest uit te kunnen voeren en van toegevoegde waarde te kunnen laten zijn?
Afstemmen en samenwerken
Een van de belangrijkste aspecten is het afstemmen en samenwerken tussen alle teams. Zo moet er goede afstemming komen tussen de applicatie eigenaren, moeten er scripts en tools zijn waarmee de load gesimuleerd wordt en moet de juiste load op de applicaties staan. Met de test boots je de load op productie na op een piek moment. Het is dus ook van belang om goed te weten wat de load moet zijn. Dit zou bij een capacity management team gehaald kunnen worden of uit bepaalde monitoring af te leiden zijn. Naar mijn mening en ervaring werkt het goed als er één iemand de leiding neemt tijdens de test en zo alle betrokken teams en personen aligned. Het liefst heb je ook alle teams bij elkaar bij het uitvoeren van de combitest, zodat er snel geschakeld en gecommuniceerd kan worden. De teams zouden het moeten behandelen als een productie omgeving, om zo goed mogelijk te kunnen zien waar mogelijke bottlenecks zitten.
Tooling, testdata en loadmodel
Het mooiste zou zijn als je de combitest kan draaien op basis van een piekdag op productie. Op die manier weet je welke onderdelen welke load moeten hebben en welke testdata gebruikt moet worden. Om dit daadwerkelijk voor elkaar te krijgen is een stuk makkelijker gezegd dan gedaan. Het is namelijk lastig om precies op alle onderdelen de load te krijgen die je wilt en ook vergelijkbare testdata te gebruiken als op productie. In de blog van een collega is dit wat uitgebreider besproken en kan meer verduidelijking geven. Om deze load op de gehele omgeving te zetten en meerder applicaties tegelijk te raken is tooling nodig. De tools waar ik het meest mee heb gewerkt en in mijn ogen volledige tools zijn om een combitest mee uit te voeren zijn Loadrunner en Neoload. Met behulp van deze tools is het mogelijk om scripts te maken en te bundelen die een piekdag kunnen simuleren qua flow en load. Verder zijn er ook uitgebreide analyse mogelijkheden om hiermee de nodige conclusies te kunnen trekken.
Testomgeving vs. productieomgeving
Het is goed om te onderzoeken of de testomgeving wel gelijk is aan de productieomgeving. Als er veel en/of grote verschillen zijn, dan zou een omgevingstest een ander beeld kunnen geven dan wat er op productie zou kunnen gebeuren. Een inventarisatie maken met de verschillen en overeenkomsten geeft inzicht in wat wel en wat niet nuttig is om mee te nemen in de combitest. Denk hierbij bijvoorbeeld aan het vullen van de omgeving met testdata om het gelijk te krijgen met productie. Al is de testomgeving niet helemaal gelijk aan de productieomgeving, denk ik dat het toch nuttig is om een combitest te doen. Er ontstaat in ieder geval een beeld van hoe alles samen draait, voordat het naar productie gaat. Tevens bouw je een goede referentie op bij regressietesten later.
Aparte testomgeving voor de combitest?
Dit blijft een lastige als je het mij vraagt. Het mooiste zou zijn als er twee omgevingen zijn voor performance testen. Een omgeving om applicaties los te testen en een omgeving waar dezelfde versies van applicaties en systemen staan als op productie (ook wel de production-like omgeving genoemd). Als de losse applicaties positieve testresultaten tonen, dan kunnen deze op de production-like omgeving gezet worden. Op deze omgeving is dan goed te zien als een nieuwe versie van een gedeeld component of applicatie performance verslechtering toont. Dit klinkt allemaal mooi, maar is heel moeilijk en vaak ook duur om te bewerkstelligen.
Hoe vaak moet je de combitest uitvoeren?
Een dagelijkse combitest van één á twee uur is een mooie optie. Op deze manier kunnen dagelijkse testen met elkaar vergeleken worden om zo mogelijke bottlenecks en trends op gedeelde componenten te kunnen opsporen. De omgeving moet dan wel geclaimd worden voor alleen de combitest, om ervoor te zorgen dat de resultaten zo zuiver mogelijk zijn. Daarnaast kan een combitest van minimaal 8 uur ook een goede toevoeging zijn. Deze kan nog andere inzichten geven die mogelijk gemist worden tijdens de testen van onder de twee uur. Denk hierbij bijvoorbeeld aan volgelopen logs, oplopend CPU gebruik of memory leaks. De lange combitest zal wel meer voeten in de aarde hebben en dus is het een optie om deze maar één keer per week of zelfs één keer per maand uit te voeren.
Mogelijke opzet van een combitest
Vanuit één van mijn opdrachten heb ik het opzetten van een combitest en het uitvoeren ervan van dichtbij mee mogen maken. De opzet hierbij was om klein te beginnen en van daaruit steeds meer uit te breiden. De grootste en meest gebruikte applicaties werden eerst meegenomen in de combitest. Voor de individuele applicaties waren scripts al beschikbaar. Deze zijn door twee mensen toen allemaal gebundeld tot één groot en werkend script, die de gecombineerde load op de omgeving zet. De piekloadcijfers van productie waren de basis van de load die er tijdens de test werd gesimuleerd. Gedurende de eerste runs werden stubs gebruikt om zo de applicaties te isoleren en ervoor te zorgen dat deze naar behoren preseteerden. Na elke succesvolle test werden de stubs verder afgebouwd tot dat er volledig tegen live services en achterlanden getest werd. Naar mate deze testen ook succesvol waren, konden meerdere applicaties toegevoegd worden. Op deze manier kon er op een gecontroleerde manier steeds een completere combitest uitgevoerd worden, waar men daadwerkelijk wat aan had en ook meerdere productieproblemen mee voorkomen waren en gedrag in kaart werd gebracht. Een mogelijk nadeel van deze opzet is wel dat het een lang traject is en dat het nodige resources (mensen, testomgeving, tooling, etc.) kost.
Conclusie
In de tijd dat een verstoring van een website binnen een paar minuten op nieuws- en storingen sites te lezen is, is het belangrijk om er zo min mogelijk te hebben. Een combitest kan hier een goed hulpmiddel bij zijn. Het is de vraag of het voor alle bedrijven haalbaar en waard is om een volledige combitest draaiend te krijgen, maar een beknopte versie kan al veel verstoringen voorkomen. Een combitest die goed uitgevoerd wordt, kan verstoringen voorkomen, die anders pas op productie ontdekt zouden worden. Er is echter tijd en inzet nodig van alle betrokken teams en moet er goed samengewerkt worden. Anders zal het vooral veel werk verzetten zijn zonder het gewenste resultaat.