Een webservice testen, hoe pak je dat aan?

donderdag 18 augustus 2016

Nu je de risico’s met betrekking tot een webservice in kaart gebracht hebt, is de vraag “Hoe test je een webservice?”. In deze blog geef ik je tips waar je op moet letten bij het testen van een webservice, welke testtechnieken je kunt toepassen, wat veel voorkomende bevindingen zijn en welke tools behulpzaam zijn.

De verschillende soorten webservices

Misschien komen ze je wel bekend voor: de verschillende soorten webservices SOAP, REST en JSON. Ze verschillen als het gaat om de structuur van het bericht en de manier van communiceren, maar ze hebben allemaal hetzelfde doel: gegevens uitwisselen tussen applicaties. Ik licht de webservices even toe:

  • Een SOAP bericht bestaat uit een envelope, een header en een body en wordt gemaakt in XML. In de body staat het bericht met de gegevens.
  • JSON lijkt op JavaScript en is een goed leesbare taal. De berichten zijn minimaal en kunnen daardoor ook snel verwerkt worden.
  • Een REST aanroep maakt gebruikt van de http methodes zoals GET en POST voor het versturen van berichten. Het antwoord van de applicatie waarmee wordt gecommuniceerd is meestal in XML.

Documentatie reviewen en testtechnieken

Als je eenmaal gaat beginnen met testen, dan is het fijn als er documentatie beschikbaar is. Denk hierbij aan documentatie over het doel van de webservice, de mapping van de velden tussen de applicaties en het bericht, element informatie en voorbeeldberichten. Ga je SOAP berichten testen dan zijn er ook Web Service Definition Language (WSDL) en XML Schema Definition (XSD) bestanden aanwezig. Helaas is er niet altijd documentatie aanwezig. Als deze wel beschikbaar is dan kunnen deze documenten beoordeeld worden en kun je controleren of de onderdelen consistent met elkaar zijn. Vaak komen we inconsistenties tegen, zoals verplichte velden die in de voorbeeldberichten niet aanwezig zijn of mappingen naar verkeerde velden in de database. Hierdoor zullen waardes niet op het scherm getoond worden. Als er geen documentatie aanwezig is, moet je hier al testende achter komen en kan je technieken als error-guessing of exploratief testen gebruiken.

Een webservice testen met documentatie

Als je wel documentatie hebt dan zal het grootste gedeelte van je testgevallen bestaan uit syntactische testen, semantische testen en grenswaarde analyses. Bij syntactische testen wordt gecontroleerd of de veldwaarde voldoet aan een bepaalde definitie. Bijvoorbeeld: geboortedatum = DD-MM-JJJJ. Een semantische test zou kunnen zijn: bij een niet volwassene moet de leeftijd < 18 jaar zijn. Grenswaardeanalyse wordt gebruikt als waardes worden afgeleid: >= 0 is Debet en < 0 is Credit. Het is verstandig om controles uit te voeren voor naamgeving, (conditioneel) verplichte velden, maximale veldlengte, minimale berichten en maximale berichten.

Met de bovenstaande controles check je vooral het bericht en de webservice zelf. De keten dient ook functioneel getest te worden. Hierbij test je vanuit de versturende en/of ontvangende applicatie om te zien of het systeem de data correct verwerkt.

Veel voorkomende bevindingen

  • Ontstaan bij de uitrol van een webservice:
  • Onjuiste configuratie webservice
  • Verkeerde versie is uitgerold

  • Gerelateerd aan de infrastructuur:
  • Time-out connectie met de database
  • Geheugenallocatie webservice is volgelopen
  • ESB platform ligt eruit

  • Tijdens het functioneel testen:
  • Onjuiste aannames over veldwaardes
  • Incorrecte mapping van velden
  • Verplichte velden zijn niet verplicht

Hulpmiddelen bij het testen

Waar je in een applicatie kan rondklikken om je testen uit te voeren, wordt dat bij een webservice een stuk lastiger. Eigenlijk zie je een webservice nooit, omdat het als communicatiemiddel op de achtergrond wordt gebruikt tussen de systemen. Dus hoe ga je de webservice testen? Daar zijn verschillende tools voor.

SoapUI

Eén van die tools is SoapUI. Hiermee kun je webservice berichten naar een ESB of applicatie versturen. Gebruik deze tool om makkelijk situaties te testen die je waarschijnlijk niet via een applicatie kan testen. Een applicatie heeft meestal zijn eigen validaties, waardoor het niet mogelijk is om bijvoorbeeld datums waarvan het formaat niet klopt of maximale veldlengtes te sturen naar een webservice.

Service virtualisatie

Maar wat nou als de applicatie waarnaar je een webservice bericht wilt versturen niet beschikbaar is? Of misschien nog helemaal niet gebouwd? Dan wil je nog steeds de webservice kunnen testen. Ook hier zijn verschillende tools beschikbaar voor. Dit wordt Service Virtualisatie genoemd. Met deze tools kun je een applicatie simuleren, waardoor je altijd het juiste bericht krijgt. Dit is ook erg handig als je bepaalde testdata nodig hebt die niet in de applicatie aanwezig is. Wil je hier meer over weten, lees dan blog ‘Service virtualisatie waardevol voor het agile team’.