Zoekresultaten

De afgelopen tijd heb ik in een opdracht collega’s mogen adviseren over de positieve impact van het Test Automation Framework BDD rondom het thema Agile. In een vorige blog ‘Transformation’ is te lezen wat BDD voor mij betekent en hoe BDD voor synergie zorgt tussen verschillende disciplines binnen Agile-teams met als doel het leveren van kwalitatief hoogwaardig software aan de eindgebruiker. Toch zie ik dat er binnen Agile projecten nog steeds veel onnodige (saaie) “manuele testen” worden uitgevoerd. Waarom? Mijn advies is om het anders aan te pakken! Los van het feit dat manueel testen tijdrovend en arbeidsintensief is, zorgt het ook voor vertraging van test feedback door sommige complexe onderdelen. Deze vertraging is nou precies wat je als team en organisatie niet wilt hebben. Het team is onnodig druk en daardoor vaak in stress, zeker als op het laatste moment van de sprint nog bugs gefixed en hertest moet worden. Daarnaast kost dit verschijnsel ook simpelweg onnodig veel geld. Testautomatisering is het middel dat op lange termijn zowel de Business als het Development Team hierbij kan helpen. Een win-win situatie! Wat is de toegevoegde waarde van testautomatisering voor mij? Binnen Agile projecten is het ontzettend belangrijk dat testautomatisering een integraal onderdeel van het Agile project is. Met name wanneer je vertraging van test feedback en tijd- en geldverspilling wilt voorkomen. Daarnaast is het primaire doel van testers/testautomatisering om de kwaliteit van het product te bevorderen (Agile/BDD mindset). Om dit te kunnen bereiken hebben we tijd nodig om de structuur en intelligentie van testen op een betrouwbare manier in te richten. Echter, het is wel belangrijk om dit met de nodige snelheid en focus te realiseren. Zeker als er sprake is van een twee wekelijkse release naar productie. Er is gewoon weinig tot geen tijd en energie om elke iteratie manueel te testen. En zelfs, mochten we die tijd wel hebben, wij testers blijven mensen en mensen maken fouten. Laten we daarom slim zijn en in ieder geval het vele repetitieve werk overdragen aan machines. Hierbij zijn de drie centrale kwaliteitsattributen leesbaarheid, herbruikbaarheid en onderhoudbaarheid de sleutel. Graag sta ik hierna even stil bij hoe ik dit zou aanpakken. Selecteer een framework wat het beste binnen het Agile project past: SpecFlow, Cucumber, Behat, JBehave etc. Na installatie van de betreffende framework kunnen we al meteen starten met het schrijven van de Feature Files, welk bestaan uit scenario’s en steps. Met behulp van Step Definitions leggen we de connectie tussen de Feature File en Applicatie Interface. Door een extra laag tussen de Step Definitions en de Applicatie te plaatsen, kunnen we de applicatie elementen op één plek onderhouden en beheren. Het is nu een teamverantwoordelijkheid om het Test Automation Framework BDD correct te implementeren! Een feature file is een plain text format die een stuk functionaliteit beschrijft in de taal van de Business, ook wel Domain Specific Language (DSL) genoemd. Het doel van een feature file is enerzijds het creëren van een levende documentatie die ook voor de Business begrijpelijk is en anderzijds het automatiseren van je acceptatie criteria die in de user story staan beschreven. Op basis van je acceptatie criteria worden de testscenario’s in de feature file door middel van “Given-When-Then” steps geautomatiseerd.Feature Files Hoe ziet de relatie tussen user story en testscenario binnen BDD eruit? De feature file nodigt in dit geval de Business uit voor communicatie. Tip: wees er wel van bewust dat de scenario’s in plaats van imperatief juist declaratief geprogrammeerd moeten worden. Het verschil tussen deze twee is dat je bij imperatief programmeren door middel van acties de programmatuur de opdracht geeft wat er moet gebeuren, terwijl je bij declaratief programmeren juist aangeeft wat het resultaat moet zijn. Door declaratief te programmeren kom je snel tot de kern van de zaak. Daarnaast zijn je testscenario’s veel meer overzichtelijker, leesbaarder en herbruikbaar. Step Definitions Step Definitions is een methode die gedefinieerd is in een willekeurige programmeertaal. De teststeps vanuit de feature file worden direct gemapt in je Step Definitions (Glue Code). Dit vormt dan een connectie tussen je feature file en applicatie interface. Step Definitions kunnen resulteren tot de volgende statussen: Succesvol, in afwachting, onbepaald of gefaald. Status in afwachting, onbepaald of gefaald houdt in dat je als tester nog werkt te doen hebt. Wel is het een mooie reminder vanuit het framework om de test volledig te maken. Vanuit de applicatie zoeken we elementen op en voeren we waarden in om de feature file succesvol te maken. Waar men wel voor moet waken is dat testscenario’s op lange termijn groeien. Wanneer je hetzelfde element op meerdere plekken in de code gaat gebruiken, dan kan dat heel zwaar worden. Zodra dat element om welk redenen dan ook in het Agile project wijzigt, dan moet je als tester veel mini changes in je code uitvoeren om de testscenario’s werkend te krijgen. Dit is tijdrovend en leidt tot meer foutgevoeligheid! Mijn advies is om Page Object Models (POM) in het Agile project te gebruiken. Ik weet zeker dat dit tot een veel betere aanpak leidt. Page Object Models Een Page Object Model (POM) is een separate file class waarin de elementen van de applicatie te vinden zijn en waar deze gevalideerd kunnen worden. Alle gebruikers-interacties worden op één pagina gedefinieerd. Zodra een wijziging plaatsvindt in het Agile project, dan kan de wijziging op één plek in de code doorgevoerd worden in plaats van op meerdere plekken. Page Object Models stimuleert leesbaarheid, herbruikbaarheid en onderhoudbaarheid van je Glue Code met als doel het verminderen van het optreden van onzekere gebeurtenissen. Dit is waar het om programmeren en testen om draait. Toch? Mocht je vragen hebben of iets anders willen opmerken? Graag, dat kan hieronder. Ik hoop dat je het interessant vond.

Tijdens één van onze kennismiddagen hebben we gekeken naar het testtool Gauge. Doel van de sessie was om een beeld te krijgen wat de toegevoegde waarde van Gauge is voor een tester. Benieuwd naar onze ervaringen? Lees dan snel verder! Gauge is een open source project, gesponsord door ThoughtWorks en belooft in het kort het volgende: Communicatieproblemen tussen ontwikkelaars en belanghebbenden is een veel voorkomend risico bij software-ontwikkeling. Gauge is een geavanceerde automatiseringstool die het mogelijk maakt requirements worden geschreven op een manier die door alle leden binnen een project kan worden begrepen en helpt de kloof te dichten. Enkele van de belangrijkste kenmerken van Gauge: Een rijke markup-taal gebaseerd op “markdown” Het is eenvoudig, flexibel en heeft een rijke syntax Business Language Tests: ondersteunt het concept van uitvoerbare documentatie Consistent Cross Platform / taalondersteuning voor het schrijven test-code. Dit werkt op dit moment voor Java, C# en Ruby Open Source, zodat iedereen het kan gebruiken en verbeteren Een modulaire architectuur met plug-in ondersteuning. Uitbreidbaar door middel van plug-ins en hacks Ondersteunt externe gegevensbronnen Het tool helpt om onderhoudbare en begrijpelijke testsuites te maken IDE Ondersteuning: IntelliJ IDEA en Visual Studio We hebben tijdens onze kennissessie gekeken naar zowel de integraties met Visual Studio (C#) als met IntelliJ (Java). Het is duidelijk nog een beta-product: we komen veel fouten en issues tegen. Er staan nog veel issues open in de issuetracker van Gauge (71 issues voor VS, 90 issues voor IntelliJ), Het koste ook veel tijd om het product aan de gang te krijgen in combinatie met Visual Studio. In Visual Studio werkt te intellisense niet zoals verwacht. In IntelliJ werkt de auto-completion wel (maar soms ook weer niet). Samples op Github en de documentatie zijn goed uitgewerkt en volledig Geneste uitvoer van steps zijn mogelijk Handig om templates te gebruiken maar maakt het wel complexer en mogelijk onoverzichtelijk (niet voor de beginnende gebruiker) Markup is erg mooi (Visual Studio). In IntelliJ heb je meteen een HTML view. Er is een plug-in beschikbaar voor het maken van mooie HTML-rapporten en werkt zo “out of the box” Verschillen met Gherkin (Cucumber/Specflow): Geneste structuur is mogelijk bij Gauge. Dit kan wel snel complex en onleesbaar worden. Het is niet gebonden aan de syntax Given-When-Then Binnen Gherkin gebruiken we regular expressions als indentifiers. Binnen Gauge zijn het simpele placeholders. Dit lijkt het eenvoudiger te maken (leesbaarder) maar daardoor is het minder flexibel (voor de ervaren gebruiker). Rapportage lijkt sneller te genereren zijn.

De afgelopen najaarseditie van Testnet stond onder het thema Continuous Everything vooral stil bij CI/CD en natuurlijk testen. Gezien DevOps en CI/CD ook grote invloed hebben op het vakgebied performance (testen), zijn wij blij dat we vanuit PerformanceArchitecten een bijdrage mochten leveren door middel van het delen van onze visie hierop. Onze collega René Meijboom (bedankt René!) heeft in een sterke en goed bezochte presentatie helder uiteengezet wat er allemaal veranderd in de wereld van performance testen en wat de gevolgen hiervan zijn met betrekking tot het afdekken van de niet functionele risico’s. Bij uitdagingen horen natuurlijk ook oplossingen. René eindigt dan ook met vier oplossingsrichtingen waarmee organisaties verder kunnen. Kortom, een heldere visie op hoe je performance risico’s, ook in de huidige tijd, de baas bent. En wanneer je op onderstaand linkje klikt ben ook jij op de hoogte! De presentatie performance testen in een CI/CD omgeving: Omdat het vertelde verhaal bij de presentatie hier niet bij staat, kunnen wij ons voorstellen dat er vragen zijn naar aanleiding van de slides. Mocht dit zo zijn, aarzel dan niet om contact op te nemen. Wij nemen graag de tijd deze vragen te beantwoorden.

Benieuwd naar de impact van het wijzigen van Apache MPM Prefork naar Worker? Lees dan door! Bij één van onze klanten heb ik dit onderzocht. Omdat dit ook interessant kan zijn voor anderen, deel ik mijn resultaten en ervaringen graag. Het is misschien wat technisch allemaal, maar voor performancetesters, de doelgroep, is het vast goed te begrijpen! Ik zal beginnen met een korte uitleg van wat Apache MPM is en welke gangbare smaakjes er zijn voor *nix systemen. Hierna sta ik even stil bij de testen die ik hiervoor heb uitgevoerd en deel ik de conclusie. Bij de web server Apache kan je kiezen op welke manier de httpd processen ingezet worden. Dit kan door een bepaalde MPM (Multi-Processing Module) te kiezen. MPM luistert naar (bind met) een netwerkpoort en ontvangt requests en laat zijn children de requests afhandelen. Je hebt de volgende MPM’s: Prefork Worker Event Welke MPM je moet kiezen, hangt af van thread support en thread-safe polling. Als het systeem het gebruik van threads niet ondersteunt, gebruik je prefork. Anders kijk je nog naar ondersteuning van thread-safe polling. Als dat mogelijk is, kom je uit bij event en anders bij worker. Hieronder worden de verschillende MPM’s kort uitgelegd. Prefork Er is 1 parent proces die verantwoordelijk is voor de child processen. De child processen “luisteren” naar nieuwe connecties en handelen deze af. Het parent proces beheert de server pool (de pool met child processen) volgens configuratie. Worker Er is 1 parent proces die verantwoordelijk is voor het beheren van de server pool. De server pool bestaat uit child processen en elk child proces heeft zelf ook weer een soort pool van 1 listener thread en meerdere server threads. De listener thread “luistert” naar connecties en verdeelt deze over de server threads die de verzoeken van die connectie afhandelt. Event Bij Worker zijn er problemen met keep-alive. De connectie kan worden opengehouden vanaf clientzijde. Hierdoor kan de server thread niet ingezet worden terwijl deze niets aan het doen is (behalve dan wachten). Event MPM lost dit probleem op. Event MPM is qua opzet gelijk aan de Worker MPM met het verschil dat bij Event de listener thread ook wat processing werk moet doen waaronder de connecties afhandelen van de sockets in keep alive status. Het werk wordt door de server threads op een shared queue gezet. Event is bij versie 2.2 geïntroduceerd en wordt betiteld als experimenteel. Dit label verdwijnt bij versie 2.4 (op moment van schrijven is een versie 2.5 beschikbaar). Voor Linux wordt een 2.6 kernel geadviseerd. Het is mogelijk dat Event niet werkt door connection filters die niet compatible zijn. In dat geval wordt automatisch Worker MPM in werking gesteld. Uitgevoerde testen Op mijn opdracht heb ik wat testen gedaan met verschillende MPM’s. Dit was voor een test op 1 applicatie waarbij ik bovengenoemde MPM’s heb geprobeerd. Ik heb 2 transacties gebruikt om load op het systeem te zetten. Ik heb het een en ander in een tabel gezet. De oplettende lezer heeft mogelijk al gezien dat in bovenstaande tabel MPM Event ontbreekt. Op de omgeving waarin ik testte, draaide Apache 2.2. Dit maakt de MPM Event experimenteel en het uitvoeren van testen en het vergelijken van de resultaten is hierdoor niet betrouwbaar. Als we kijken naar de resultaten voor Prefork en Worker zien we het (grote) verschil voornamelijk in het aantal httpd processen tijdens de test (118 versus 7-8). Voor Prefork wordt voor elke connectie een httpd proces in gebruik genomen zoals ook verwacht. En bij Worker is dit dus aanzienlijk lager doordat worker httpd processen een pool met meerdere threads bevatten om het werk af te handelen. Met minder processen zou je ook minder CPU gebruik verwachten. Dat zien we niet terug in bovenstaande tabel. Dit komt doordat het aantal gebruikte threads niet heel anders zal zijn dan bij prefork. Dit konden we helaas niet controleren. De testen wezen uit dat een overgang van Prefork naar Worker geen problemen oplevert. Ik ben heel benieuwd naar andere ervaringen en bevindingen met MPM testen. Dus reageer vooral!

In het kader van de 4e techday van Qquest heeft Chris met ondersteuning van HenkJaap een workshop gegeven. Basis was de presentatie en demo ‘No more magic’ van Bas en Chris, welke al een groot succes was op de TestAutomationDay en TestNet. Centraal bij het onderwerp ‘No more Magic’ staat het idee dat er bij een samenwerking in een Agile team geen ruimte is voor ‘eilandjes’ en onderlinge onduidelijkheden, waarbij het soms wel lijkt alsof collega’s magie gebruiken. Er komen verschillende methodes, talen en tooling bij elkaar, welke aan te passen zijn aan de door het team gebruikte technieken. In dit geval gebruikten we Specflow in combinatie met selenium en Visual Studio op een C# omgeving. Doel van de workshop was de deelnemers te introduceren in hoe je Gherkin gebruikt en hoe je met deze manier van werken een eenheid in je team afdwingt. Iedereen kan op zijn eigen abstractie niveau werken in dezelfde omgeving en zien wat de status van een project is. Hierbij zijn feature files, glue code en design patterns als het page object pattern en fluent interface aan bod gekomen. We hebben genoten van het enthousiasme en de werklust van de deelnemers, waarbij in relatief korte tijd toch veel van de stof aangeraakt is. De oefeningen zijn grotendeels afgemaakt met hier en daar wat coaching on the job en de deelnemers hebben door in groepjes te werken elkaars en hun eigen kennis weer verbreed. Lees ook hun eigen ervaringen! Aan het einde van de workshop ontstond er nog een inspirerende groepsdiscussie, waar de deelnemers naast hun enthousiaste feedback nog enkele goede vragen stelden, welke met voorbeelden uit de praktijk zijn beantwoord en toegelicht. Tot slot heeft Chris een link gedeeld met daarop alle opdrachten, de antwoorden en een setting van de installatie waarbij de opdrachten uitgewerkt zijn. Zo kunnen de deelnemers hun goede werk thuis of op hun opdracht verder in de praktijk brengen. Al met al een zeer geslaagde workshop. Nogmaals bedankt Qquest voor de enthousiaste inzet!

Integreer Newman in 6 simpele stappen in Jenkins, inclusief JUnit testrapport Voor het testen en monitoren van web API’s is Postman een populaire tool. De community versie is gratis en bovendien behoorlijk compleet. Ook de Pro versie is best betaalbaar, zeker in vergelijking met bijv. SOAP-UI. In deze blog wordt beschreven hoe je jouw Postman collectie laat draaien vanuit Jenkins en hoe je hierbij een praktisch JUnit test report krijgt. Als je reeds een collectie van web requests hebt opgebouwd in Postman, dan kun je deze op een aantal manieren benutten: Via de Postman GUI (Chrome extensie of native Windows / Mac applicatie) Via de Postman Runner module in de applicatie Via Newman, de Command-Line Interface Methode 1 is volledig handmatig. Dat betekent dat je iedere request handmatig dient te verzenden om de betreffende response te kunnen testen. Hoewel dat prima volstaat om een specifieke request te verifiëren is het behoorlijk omslachtig wanneer je een complete set aan requests na wilt lopen, bijvoorbeeld voor een regressietest van je API. Methode 2 is wel geschikt om een complete collectie te draaien, maar vereist wel dat je handmatig een configuratie instelt in de GUI. Wil je je Postman collectie maximaal automatiseren? Ga dan voor methode 3. Je roept de collectie dan aan middels Newman: de command-line interface van Postman. Newman biedt bovendien de mogelijkheid om je collectie volledig geautomatiseerd te draaien, bijvoorbeeld door het in Jenkins te integreren. 1. Installeer de NodeJS plug-in in Jenkins Newman is een NodeJS applicatie. Daarom is het zaak om NodeJS te kunnen gebruiken vanuit Jenkins. Om NodeJS te installeren ga je naar: Jenkins > Manage Jenkins > Manage Plugins Kijk bij de ‘Installed’ tab of je de NodeJS plug-in ziet. Zo niet, selecteer hem dan in de ‘Available’ tab en klik op ‘Install without restart’. 2. Configureer NodeJS met Newman Nu Jenkins kan beschikken over NodeJS, gaan we een nieuwe NodeJS installatie aanmaken en de npm packages definiëren die geïnstalleerd dienen te worden. Ga daarvoor naar: Jenkins > Manage Jenkins > Global Tool Configuration Selecteer daar ‘NodeJS installations’ Geef een naam voor de installatie en kies een recente versie van NodeJS Bij ‘global npm packages to install’ geven we alleen ‘newman’ op Klik nu op ‘Save’ 3. Maak een nieuw Jenkins project aan Nu kunnen we in Jenkins een project aanmaken. Ga daarvoor naar: Jenkins > New Item Geef het project een naam, selecteer template ‘Freestyle project’ en klik OK. We gaan hierna 3 stappen toevoegen in dit project: 2 bouwstappen en 1 post-build stap voor het testrapport. 4. Maak een bouwstap aan voor NodeJS Scroll naar de ‘Build’ sectie en klik op ‘Add build step’. Kies vervolgens ‘Execute NodeJS script’ en selecteer de installatie die je onder stap 2 hebt aangemaakt. 5. Maak een tweede bouwstap aan voor Newman In deze bouwstap zorgen we ervoor dat Newman je collectie requests (en eventuele tests) uit gaat voeren. Daarvoor moet Newman wel kunnen beschikken over je Postman collectie. Een simpele manier daarvoor is de optie ‘Share collection’ in de Postman applicatie. Ga naar je Postman collectie en selecteer ‘Share Collection’. Selecteer de ‘Get Link’ tab en kopieer de link naar je klembord. Terug in Jenkins, kies nogmaals ‘Add build step’ en selecteer ditmaal ‘Execute Shell’. Hierin plaatsen we het Newman commando: Om de collectie te draaien: newman run CLI & JUnit rapporten genereren: --reporters cli,junit Om het JUnit rapport op te slaan: --reporter-junit-export <"newman/report.xml"> Het complete commando wordt dan als volgt: newman run https://www.getpostman.com/collections/12a34b56c78d90 -r cli,junit --reporter-junit-export "newman/SmoothieFlavorsTestReport.xml" Het JUnit rapport werkt uiteraard alleen als je collectie ook testen bevat. Anders kun je deze commando’s achterwege laten. 6. Publiceer het JUnit testrapport Het XML-rapport van JUnit is inmiddels aangemaakt, maar voor een leesbare weergave moet het nog gepubliceerd worden binnen Jenkins. Maak een nieuwe ‘Post-build Action’ aan en kies voor ‘Publish JUnit test result report’. De locatie waar de XML-rapporten staan is: “newman/*.xml”. Druk tenslotte op Save om je Jenkins project op te slaan! Eventuele vervolgstappen Je bestaande Postman collectie draait nu in Jenkins! Als je een nieuwe bouwpoging start, dan wordt je collectie doorlopen en de resultaten worden door JUnit verwerkt. De bouwpoging slaagt wanneer er geen fouten optreden en faalt indien één van de testen faalt. Natuurlijk zijn er nog wat mogelijke vervolgstappen om je Postman collectie nog waardevoller te maken voor jou en je project: Maak in Jenkins een Post-build stap aan om het project op de hoogte te houden. Dat kan bijvoorbeeld door middel van een e-mail of Slack-bericht met daarin een korte samenvatting van de resultaten. Voeg een build trigger toe om het je collectie op een vast interval of na een specifiek event te starten. Schakel versiebeheer in (Postman Pro licentie vereist) zodat je gemakkelijker kunt samenwerken en je collectie up-to-date houdt. De gedeelde collectie die we als voorbeeld gebruiken is namelijk statisch, en moet dus met de hand geüpdatet worden na iedere aanpassing. Leuk dat je dit blog hebt gelezen. Ik ben nieuwsgierig naar jouw ervaringen. Heb je nog tips? Of heb je vragen of opmerkingen? We horen het graag!

Omdat ik zelf toch wel even heb moeten uitvogelen hoe ik Oracle ATS kon installeren op Windows, heb ik deze handleiding in elkaar gezet, zodat het voor jou als lezer wat makkelijker wordt. Het gaat over versies vanaf 13.x en is interessant voor iedereen die Oracle ATS wil gebruiken om Oracle (web)applicaties te testen. ATS staat voor Application Testing Suite en is software van Oracle waarmee onder andere performance tests uitgevoerd kunnen worden op web applicaties, maar ook Oracle producten. Ik richt me in deze blog vooral op de installatie voor performancetesten waarbij de componenten van OATS worden geïnstalleerd op Windows machines. De onderstaande installatie focust zich daar ook op. Mocht je meer willen lezen over Oracle ATS, dan kan je die informatie hier vinden: https://www.oracle.com/technetwork/oem/app-test/index.html. De applicatie kan je downloaden via: http://www.oracle.com/technetwork/oem/downloads/index-084446.html. Voor performancetesten gebruik je de volgende componenten: Oracle OpenScript Oracle ATS Server Components: Oracle Load Testing, Oracle Test Manager, Administrator Oracle ATS Agent Al deze componenten installeer je via dezelfde ingang: de setup.bat in de applicatie download zip folder. Als je setup.bat op de server start, kan je kiezen voor complete of custom installatie. Als je voor custom kiest, kan je zelf aangeven welke van bovenstaande componenten je wilt installeren. In de applicatie download zip folder bevindt zich ook de installatie handleiding (onder /docs/). Dit artikel geeft vooral wat meer context en focust zich voornamelijk op de punten in de installatie waar je even goed moet opletten welke keuze je maakt. De componenten die wij willen installeren, zijn: OpenScript, Oracle Load Testing (OLT) en Administrator en Agent. Hieronder beschrijf ik hoe je dat doet per applicatie. De beschrijving gaat ervan uit dat je al in het scherm bent, nadat je voor custom installatie hebt gekozen. Let op: vanaf versie 13.x is het niet meer mogelijk om via deze suite een database te installeren. Je moet deze al beschikbaar hebben of er één installeren. Het moet dan een Oracle XE of EE database zijn. OLT en Administrator Als je Oracle ATS Server Components en Oracle ATS Agent (is een required dependency) geselecteerd hebt: Klik je op Next. Vul hier een master password in. Dit wachtwoord wordt gekoppeld aan meerdere gebruikers waaronder de administrator user. Klik op Next. Kies voor Configure an existing Oracle XE or EE Database en klik op Next. Vul hier de DB Hostname, Port (default 1521), Service Name, DB User en DB password in. Klik op Next. Let op: het is belangrijk om hier een DB User te gebruiken met voldoende rechten om views en dergelijke aan te passen en accounts aan te maken voor de database. Default is daarom ook system ingevuld als DB User. Als de gegevens in de vorige stap in orde waren, krijg je nu schermen om users in de database aan te maken, namelijk: OATS, OTM en OLT. Als je deze stappen doorloopt, zal de installatie uitgevoerd worden. Agent Als je Oracle ATS Agent geselecteerd hebt: Klik je op Next. Hier vul je een master password in. Dit is het wachtwoord wat OLT nodig heeft om te kunnen connecten met de Agent. Klik op Next. Nu kan je klikken op Install en zal de Agent geïnstalleerd worden. OpenScript Als je Oracle OpenScript geselecteerd hebt: Klik je op Next. Klik op Install en OpenScript wordt geïnstalleerd. Verdere configuratie Je kan nu Administrator starten (via programma’s of via URL http://localhost:8088/admin/Login.do). Hier kan je dan met administrator user en master password van OLT installatie inloggen op Default OLT Database. Hier kan je accounts gaan aanmaken voor het gebruik van OLT. OLT wordt gebruikt als Controller. Hier kan je de scripts die je maakt in OpenScript in een scenario gieten en de Agents gebruiken om de load te genereren. De communicatie tussen OLT en de Agents gaat via port 9001 (OLT à Agent) en 8088 (Agent à OLT). Als deze porten niet openstaan, moeten deze opengezet worden. Als op de Agent machine een firewall aanwezig is, moet ook port 7 opengezet worden. Toevoegen van de Agents in OLT gaat als volgt: Klik op drop down bij gebruikernaam (rechtsboven) en selecteer Options Ga naar Systems à VU Agent Systems Voeg hier een “New System” toe Vul de gegevens in. Port en Username staan al ingevuld. Dit zijn de standaard waardes bij installatie van een Agent. Het Password is het master password dat je hebt opgegeven bij de installatie van de Agent. Klikken op Test zal verifiëren of de connectie met de Agent tot stand kan worden gebracht. Klikken op OK voegt de Agent toe aan de lijst. Nu is Oracle ATS klaar voor gebruik! Ik hoop dat je iets aan deze handleiding hebt gehad. Als je nog opmerkingen of vragen hebt, hoor ik dat graag!

In deze blog sta ik stil bij een recent voorbeeld van innovatie. Ik beschrijf hoe ik R heb ingezet bij het analyseren van loadtest-resultaten, omdat een andere analyse tool zoals die van MicroFocus LoadRunner / Performance Center niet voor handen was. Dit was het geval in een klantsituatie waarbij teams in staat zijn gesteld zelf al zoveel en zo vroeg mogelijk te performancetesten, met tools als bijvoorbeeld JMeter. Zo kunnen teams meer autonoom opereren en ontstaat er al in een eerder stadium een eerste beeld over de performance van een applicatie. Wanneer er grote hoeveelheden data zijn om te analyseren, of wanneer er simpelweg een aantal CSV-bestanden met gegevens verwerkt en weergegeven moeten worden in een tabel of grafiek, wordt daar vaak Excel voor gebruikt. Zolang je eenvoudige gegevens verwerkt, is dit best een goede oplossing. Maar in de praktijk moet je vaak meerdere bestanden combineren en wil je diverse berekeningen op de ingelezen gegevens loslaten. Wij hebben in het gebruik van R een goede oplossing gevonden. R is een programmeertaal en omgeving voor statistische analyse en grafische representatie van gegevens. R is de open-source versie van S. Meer informatie is te vinden op de website van het R-Project (www.r-project.org). R-Studio is een populaire IDE voor R en is zowel als open source en als commerciële editie beschikbaar. RStudio draait op Windows, Mac en Linux. In het volgende voorbeeld is er sprake van een drietal bestanden die gecorreleerd moeten worden: create.dat – dit bestand bevat items die op een bepaald tijdstip zijn gecreëerd. queue.dat – dit bestand bevat meerdere tijdstippen per items waarop deze op een queue geplaatst zijn. processed.dat – dit bestand bevat meerdere statussen en tijdstippen per verwerkt item van de queue. In onderstaand plaatje worden een paar regels van de verschillende bestanden weergegeven. Hoewel het mogelijk is om dit in Excel te correleren en weer te geven in een grafiek, is dat geen eenvoudige klus. Met behulp van R kan dit veel sneller een eenvoudiger, zeker met grote bestanden. Er zijn veel packages beschikbaar voor R die als hulpmiddel kunnen dienen bij data manipulatie of weergeven van grafieken en tabellen. Hieronder zie je de grafiek die met R gemaakt is waarin het aantal events per minuut zijn weergegeven. De bijbehorende tabel toont de gegevens zoals die gebruikt zijn voor het creëren van bovenstaande grafiek. Het is verder mogelijk om te filteren en sorteren. In onderstaande tabel is gefilterd op id 313-1563955 en gesorteerd op id. Op deze manier is het eenvoudig om alle events per id terug te vinden. De code die nodig is om dit alles te maken kun je hieronder terugvinden. Zelfs als je nog niet bekend bent met de taal R is het al goed mogelijk om deze code te lezen. Het is zeker de moeite waard om je in R te verdiepen, het is een krachtig hulpmiddel voor data-analyse. --- title: "Data analyse met R" author: "Rene Meijboom" date: "26 februari 2019" output: html_document --- ```{r demo, include=FALSE} knitr::opts_chunk$set(echo = TRUE) options(warn = -1) library(formattable) library(DT) library(plotly) create <- read.csv("create.dat", header = FALSE, stringsAsFactors=FALSE, sep = ",") names(create)<- c("name","id","datetime") create$datetime <- as.POSIXct(strptime(create$datetime, "%Y-%m-%dT%H:%M:%S")) create["event"] <- c("created") publish <- read.csv("queue.dat", header = FALSE, stringsAsFactors=FALSE, sep = ",") names(publish)<- c("id","datetime") publish$datetime <- as.POSIXct(strptime(publish$datetime, "%Y-%m-%dT%H:%M:%S")) publish["event"] <- c("on queue") processed <- read.csv("processed.dat", header = FALSE, stringsAsFactors=FALSE, sep = ",") names(processed)<- c("id","status","datetime") processed$datetime <- as.POSIXct(strptime(processed$datetime, "%Y-%m-%dT%H:%M:%S")) processed["event"] <- c("processed") total <- rbind(subset(processed,select = c("id","datetime","event")),rbind(subset(create,select = c("id","datetime","event")),publish)) aggr <- aggregate(id~datetime+event, FUN=length, data=total) dfgran <- aggregate(id~event+strftime(cut(aggr$datetime, "60 sec"), "%H:%M:%S"), FUN=length, data=aggr) names(dfgran)<- c("event","time","count") plot_ly(dfgran, x=~dfgran$time, y=~dfgran$count, color=dfgran$event, type = 'scatter', mode = 'lines') %>% layout(title = 'Events per minute', xaxis = list(title = 'Elapsed time'), yaxis = list(title = 'Number of items'), margin = list(l = 50, r = 50, b = 100, t = 100, pad = 4)) as.datatable(formattable(total)) ``` Conclusie is wat mij betreft dat R je prima mogelijkheden geeft om tot complexe data analyses te komen. Al dan niet in samenhang met een geautomatiseerd performance test framework. Heb jij ervaring met R, of juist met een ander, vergelijkbaar tool? We zien jouw ervaringen graag als reactie tegemoet! De in deze blog besproken 'data-analyse met R' is een voorbeeld van één van de innovaties die PerformanceArchitecten samen met haar klanten ontwikkeld. Innovatie is iets waar de omstandigheden steeds vaker om vragen gezien de snelle ontwikkeling binnen het vakgebied. Al deze innovaties komen samen in de aanpak Quality Engineering (QE) van PerformanceArchitecten. QE ondersteunt klanten met het opzetten van een integrale kwaliteitsaanpak in een DevOps en CI/CD omgeving. Het draagt bij aan een sneller ontwikkelproces met een betere kwaliteit. Zowel op functioneel gebied als op non-functioneel gebied. Mocht je hier vragen over hebben of mocht je hier gewoon eens over willen sparren, zien we graag je reactie!

Wanneer je ‘vroeger’ een website had, waren er altijd flink wat handelingen nodig om files via een FTP client op een webserver te krijgen. Vandaag de dag, met behulp van een verscheidenheid aan tooltjes, is dat een fluitje van een cent. Daarnaast krijg je een arsenaal aan mogelijkheden mee als builden, testen, etc.. In deze blog beschrijf ik wat mijn ervaringen zijn tijdens een eerste tool onderzoekje naar Circle-CI. Hint: Het wordt een positief verhaal, lees dus snel door! Mijn zondagochtend begon met het inrichten van Circle-CI. Een collega raadde mij aan om deze tool eens te onderzoeken omdat het gebruik zeer gebruiksvriendelijk, snel en gratis zou zijn. Het doel: Met één druk op de knop mijn repository en website bijwerken. Circle-CI is een CI/CD tool die gekoppeld kan worden aan je Github account. Aangezien mijn repository (website) hier staat geparkeerd, ga ik deze combinatie uitproberen. Setup Als je naar de site van Circle-CI gaat (https://circleci.com) kun je een account aanmaken en bij het inloggen kiezen voor ‘Log in with GitHub’. Er volgt daarna een soort van koppelingsactie met GitHub zodat we de GitHub repo’s kunnen gebruiken in Circle-CI. Het ritueel spreekt voor zich. Eenmaal op het dashboard van Circle-CI gaan we aan de linkerkant in het menu naar ‘Add Projects’. Wanneer we hier op klikken dan zien we alle repositories uit het GitHub account. Vervolgens kunnen we aan de rechterkant van een projectnaam klikken op ‘Set Up Project’. In het voorbeeld hieronder zijn de bovenste 2 projecten al ‘up and running’. Door ‘Unfollow Project’ te klikken kun je het project weer loskoppelen. Wanneer we door de setup gaan zien we dat Circle-CI al heeft herkend in welke taal het project is ontwikkeld. Dit kan eventueel nog aangepast worden. Een vereiste is het aanmaken van een configuratie file in de vorm van een YML. Daarvoor moeten we in de projectmap een folder (.circleci) aanmaken (tip: gebruik de command line en vergeet de punt niet voor de foldernaam) om daarin een file genaamd ‘config.yml’ aan te maken (zie onderaan het artikel de indeling van het project). In het dashboard scherm staat een voorbeeld van een .YML file. Deze kan gekopieerd worden en in de config.yml worden geplakt. Hieronder staat een voorbeeld van de .YML file die ik zelf gebruik. Deploy Bij het pushen van het project naar GitHub wordt het project gebuild in CircleCI en alles dat in de .YML file staat gedefinieerd wordt uitgevoerd. We doen dit nog niet want zoals in het voorbeeld te zien moeten we een deploy.js file aanmaken waarin we een FTP actie gaan definiëren om de aangepaste files naar de webserver te FTP-en. Vóórdat we kunnen deployen moeten we zorgen dat de ftp-deploy package aanwezig is in de package.json file van het project. Dit doen we door deze te installeren: npm install -D ftp-deploy. Deze zal aan de ‘devDependencies’ worden toegevoegd met de laatste versie. De FTPUSERNAME, FTPPASS en FTPHOST variabelen kunnen we definiëren in Circle-CI. Wanneer we naar ‘Settings’ gaan en vervolgens onder het kopje ‘Organisation’ naar ‘Projects’ dan zien we het project onder ‘Followed projects’. Helemaal aan de rechterkant van het project zien we een settings radartje. Wanneer we hier op klikken kunnen we onder ‘Build settings’ kiezen voor ‘Environment Variables’. We kunnen hier nieuwe variabelen definiëren en deze gebruiken in de scripts die we uitvoeren. Er makkelijk en veilig. Test Het punt is aangebroken om de boel te testen. We hebben het project lokaal staan en maken een kleine wijziging in een file (bijvoorbeeld de index.html file). We comitten de file en pushen het naar GitHub. We kunnen in het dashboard van Circle-CI de progressie zien (menu-item ‘Jobs’) en als we op de job doorklikken kunnen we de details zien.  Per detail kunnen we zien wat er allemaal wordt uitgevoerd (logging) en of de job uiteindelijk geslaagd is of gefaald (de uitslag kun je via de mail ontvangen) Uiteindelijk zal de aangepaste file op de webserver en in GitHub zijn geplaatst. Uiteraard kunnen er tal van jobs worden toegevoegd in dit proces (denk aan testen). Wat betreft snelheid gaat dit aardig snel. Er kan opgeschaald worden qua gebruikers en resources. Dit is echter niet gratis. Wanneer je het niet te gek maakt kun je er wel gewoon gratis gebruik van maken. Conclusie Mijn conclusie is dat Circle-CI snel, goedkoop (gratis) en makkelijk in gebruik is. In een half uurtje is alles up-and-running. Het dashboard is overzichtelijk en bied tal van mogelijkheden. Ik ben benieuwd hoe Circle-CI zich gedraagt in grote complexe omgevingen. Iemand meer ervaring met Circle-CI of juist met een vergelijkbare tool? Ik zie het graag in de comments. Andere vragen en of opmerkingen horen we ook graag natuurlijk. Bedankt voor je aandacht! Indeling project:

Om (ontwikkel)teams zo vroeg mogelijk van feedback te voorzien met betrekking tot performance voer ik regelmatig performance testen uit. Zo ook voor de verschillende projecten die ik bedien binnen mijn huidige opdracht. Dankzij de regelmatige testen bouw je meer historische data op waardoor je trends kan gaan ontdekken. Bovendien worden hierdoor ook (enigszins) de effecten van andere wijzigingen inzichtelijk (anders dan een nieuwe release van de applicatie). Denk hierbij bijvoorbeeld aan OS updates op de applicatie server of wijzigingen aan het netwerk of aan backend systemen. In deze blog geef ik kort en bondig neer in welke opzet en met welke tooling ik dat in deze opdracht doe. Ik zou het leuk vinden te horen wat jij daarvan vindt en of en zo ja welke ervaring jij hebt met performancetesten in de pipeline. Bij mijn opdracht gebruik ik de volgende tooling: SVN (Subversion) – versiebeheer software Bamboo – continuous integration software (pipeline) Oracle ATS – performance test tooling Splunk – software voor zoeken, monitoren en analyseren van data, gegenereerd door servers. SVN In deze context wordt SVN gebruikt om het powershell script te beheren die door de Bamboo plannen gebruikt wordt. Het gaat hier dan om een script die de test aftrapt in Oracle ATS. Bamboo In Bamboo heb ik per project een plan aangemaakt. Als er van te voren testdata aangemaakt moet worden heb ik 2 stages, anders 1. De eerste stage is dan natuurlijk voor het voorbereiden van testdata en de tweede is voor de uitvoer van de performance test. De stages bevatten zelf weer jobs die binnen die stage uitgevoerd worden. Ik focus me nu alleen op de uitvoer stage. Binnen de uitvoer stage hebben we 2 jobs; Source Code Checkout en een PowerShell Task. De Source Code Checkout haalt uit SVN het powershell script waarmee we de test in Oracle ATS willen starten. De PowerShell Task gebruikt vervolgens dat script en geeft Arguments mee. Dit zijn gebruikersnaam/wachtwoord combinaties voor OLT (Oracle Load Testing; de Controller van Oracle ATS) en van de server waarop OLT draait en enkele project specifieke waardes zoals applicatie naam en naam van scenario file (.scn). Om bovenstaande in te kunnen stellen, moet je bij de plan configuratie nog wel de SVN repository toevoegen onder Repositories. Ik heb bij Triggers een Scheduled trigger toegevoegd waarbij ik in kan stellen wanneer dit plan gerund moet worden (bijv. elke vrijdag om 20:00 uur). Oracle ATS Dit is de performance test tooling die bij mijn opdracht gebruikt wordt. Via OpenScript kan je scripts maken. Via Oracle Load Testing (OLT) kan je scenario’s maken en performance testen uitvoeren. Je kan deze ook via command line aftrappen. Op deze manier worden de testen ook gestart via de pipeline in Bamboo. Het commando ziet er als volgt uit: C:/OracleATS/jdk/bin/java -jar C:/OracleATS/lib/OLTCommandLine.jar -run -OLTServer=localhost:8088 -user=oats -password= -scenarioFile= -session= De resultaten van de performance test komen in een Oracle database terecht. Door middel van een scriptje gemaakt door een DBA’er wordt deze content weggeschreven in een log. Splunk De logging die gegenereerd wordt met de performance test resultaten wordt via een Splunk Forwarder opgepakt en wordt dus beschikbaar in Splunk. In Splunk hebben we per project een scriptje dat elk uur draait om te kijken of er voor dat specifieke project een testrun is geweest met een eindtijd. Als dat het geval is, worden de gegevens waarmee die run te identificeren is toegevoegd aan een lookup waarin alle runs staan van dat project. Hierbij is vooral het sessie id belangrijk. In een dashboard worden dan in een dropdown selectie velden de verschillende runs getoond uit die lookup. Hierbij kunnen dan 2 runs geselecteerd worden die met elkaar vergeleken kunnen worden. De data wordt dan opgehaald op basis van de sessie id’s die horen bij de geselecteerde runs. Dat was hem weer. Zoals gezegd ben ik benieuwd hoe jullie dit doen. Is de opzet vergelijkbaar of helemaal anders? Ik hoor het graag!

Bij PerformanceArchitecten vinden we het belangrijk om continu onze kennis te ontwikkelen en bij te houden. Daarom organiseren we elke maand een kennismiddag, waarbij we ons verdiepen in verschillende onderwerpen die relevant zijn voor ons werk. Onze laatste kennismiddag stond in het teken van het RealBrowser “protocol” binnen het performancetesttool NeoLoad van Tricentis. Voor degenen die niet bekend zijn met NeoLoad, het is een tool die wordt gebruikt voor het testen van de performance van webapplicaties en -diensten. Het is een tool onder performancetesters die steeds populairder wordt vanwege de vele mogelijkheden en maar vooral ook de concurrerende prijsstelling van dit commerciële tool. Sinds versie 9.0 is RealBrowser toegevoegd aan NeoLoad. Dit biedt testers de mogelijkheid om tests uit te voeren die nog realistischer zijn dan voorheen. Met RealBrowser kunnen testers nu de performance van hun applicaties testen op basis van echte browsers zoals Chrome en Firefox. Anders dan het standaard HTTP gebaseerde protocol dat voorheen de standaard in NeoLoad was, wordt ook de client-side rendering en verwerking binnen de browser meegenomen. Hiermee krijg je dus een realistischere transactietijden zoals ook de eindgebruiker ervaart. Daarnaast is het niet nodig om moeilijke correlatie te doen om het gedrag van de browser goed te simuleren. Om tijdens de kennismiddag praktijkervaring op te doen met RealBrowser, was het belangrijk dat alle deelnemers de nieuwste versie van NeoLoad, versie 9.2.1, hadden geïnstalleerd op hun laptops. Dit zorgde ervoor dat we optimaal gebruik konden maken van de laatste mogelijkheden van RealBrowser en de functionaliteiten ervan goed konden verkennen en testen. De basis van RealBrowser is gebaseerd op Playwright, een open source testing framework dat is geïntegreerd in het NeoLoad-tool. Hierdoor krijg je grotendeels de functionaliteit van Playwright. Bij de installatie worden meerdere browsers meegeleverd en geïnstalleerd. NeoLoad biedt de functionaliteit van Playwright door middel van nieuwe scriptacties, die handmatig kunnen worden toegevoegd aan het script, maar ook kunnen worden opgenomen. Wanneer de opname wordt gestart, wordt eerst een Chromium-browser gestart, waarna alle acties die in de browser worden uitgevoerd automatisch worden omgezet in NeoLoad-scriptacties. Dit zorgt voor een snelle manier om testscripts op te zetten. Onze ervaringen met het RealBrowser-protocol binnen NeoLoad laten zien dat het goed werkt, maar dat het nog steeds in ontwikkeling is. Het was een slimme keuze van Tricentis om het protocol te baseren op Playwright, omdat het snel, stabiel en compatibel is met verschillende browsers, zowel in headless als in GUI-modus. Het blijkt dat de extra resources die nodig zijn voor browser-gebaseerde tests meevallen. Om echter veel gebruikers te simuleren, is het ook mogelijk om een mix te maken van zowel het traditionele HTTP-gebaseerde protocol als het RealBrowser-protocol. Voor de echte belasting van de applicatie kan je het “oude” protocol gebruiken, wat relatief weinig resources vereist, en enkele RealBrowser-gebruikers toevoegen om een realistischer beeld te krijgen van hoe eindgebruikers de applicatie ervaren. Dit biedt een goede balans tussen belasting en realisme tijdens het uitvoeren van performancetests. Hoewel het RealBrowser-protocol binnen NeoLoad goed werkt, valt er zeker nog wel het een en ander op aan te merken. Tijdens het gebruik wordt het duidelijk dat het nog steeds een versie 1.0 is. Sommige functionaliteiten zijn nog niet volledig geïntegreerd op een eenduidige manier en er is nog weinig documentatie beschikbaar. Dit kan leiden tot enige uitdagingen bij het opzetten van performancetests met het RealBrowser-protocol. Nog wat expliciete voor- en nadelen: Het opgeven van welke browser gebruikt moet worden is niet consequent met de andere protocollen Voor de loadgeneratoren kan een Linux gebaseerde Docker-image worden gebruikt wat ook weer minder resources inneemt en meer gebruikt wordt dan Windows gebaseerde Docker images Record from here: een handige functie die eerst de voorgaande stappen afspeelt en dan de recording start Assertions zijn onduidelijk hoe je die toevoegt of gebruikt Zoeken/vervangen werkt niet goed in RealBrowser Tijdens de recording worden alleen screenshots bewaard waardoor het lastig is om onderhoud te doen en doot de CSS/Xpath uit de source te halen De ondersteuning van vreemde browser frameworks (bv Vaadim) is geen probleem voor RealBrowser terwijl dit heel moeilijk/onmogelijk te scripten is met het HTTP protocol Het recorden van zaken die niet standaard zijn kosten exponentieel meer moeite. Al met al was onze kennismiddag over RealBrowser en NeoLoad zeer leerzaam en interessant. We zijn blij dat we ons kunnen blijven ontwikkelen en op de hoogte kunnen blijven van de nieuwste ontwikkelingen op ons vakgebied. We kijken alweer uit naar de volgende kennismiddag!

Tijdens de laatste maandelijkse kennismiddag van PerformanceArchitecten hebben we ons verdiept in het onderwerp SRE (Site Reliability Engineering). SRE combineert software engineering en operationele principes om grootschalige en complexe systemen te bouwen en beheren. Ter introductie hebben we verschillende video’s bekeken waarin de definitie van SRE werd gegeven en het verschil tussen SRE en DevOps werd uitgelegd. Vervolgens hebben we deelgenomen aan een workshop getiteld “The Art of SLO”. Tijdens deze workshop werd niet alleen uitgebreid de theorie behandeld, maar kregen we ook de gelegenheid om zelf aan de slag te gaan met het bepalen van SLI’s (Service Level Indicators) en SLO’s (Service Level Objectives) aan de hand van enkele opdrachten. Tenslotte hebben we geëvalueerd in welke mate de kennis en vaardigheden die we hebben opgedaan direct toepasbaar zijn in ons werk. We zien zeker raakvlakken met ons werk als performance engineer en denken dat er met name mogelijkheden liggen bij onze klanten die bezig zijn met cloudtechnologie. Concluderend kunnen we stellen dat onze kennismiddag zeer geslaagd was. We hebben veel geleerd over SRE en we kijken uit naar de volgende kennismiddag en het volgende onderwerp dat we gaan verkennen.