Model Based Testen in de praktijk

Image

Door: Ed Hilkman

In mijn vorige blogs ging ik in op de bottlenecks die ik ervaar met testgevallen en schetste ik een oplossing in de vorm van een andere werkwijze: Model Based Testen. In dit blog ga ik aan de hand van een voorbeeld dieper op MBT in. Het voorbeeld heb ik uitgewerkt met behulp van de MBT tool TestOptimal.

De System Under Test (SUT) waarvoor het model is gebouwd betreft een fictieve webshop. Zoals in iedere webshop kan je naar producten zoeken en details van producten raadplegen. In deze webshop kan geraadpleegd worden op twee niveau’s: 1) een quick view met de globale productgegevens en 2) een detailed view waarmee de overige productinformatie wordt getoond.

Model

De zoekfunctionaliteit (1) heb ik gemodelleerd in TestOptimal. Het model laat zien dat de zoekfunctionaliteit ook het zoeken naar niet bestaande producten ondersteunt (2). In dat geval wordt een melding getoond dat geen van de aanwezige producten in de webshop voldoet aan de zoekterm. Indien er wel producten overeenkomen met de zoekterm, dan kan men ze globaal (3) of gedetailleerd (4) raadplegen.

Image
Toestanden

Elke toestand in het model wordt weergeven als rechthoek en komt overeen met een praktijksituatie in de webshop. De toestand Search geeft aan dat je wilt gaan zoeken, Search result komt overeen met de situatie dat een zoekactie minstens één product heeft opgeleverd en Quick view representeert het getoonde globale productoverzicht in de webshop. De meeste toestanden bevatten zogenaamde assertions. Assertions zijn de controles die je normaliter in testgevallen ook ziet terugkomen. Zo bevat de toestand Search een check of het zoekveld zichtbaar is, in Search result wordt gecontroleerd of er tenminste één zoekresultaat zichtbaar is en Quick view vergelijkt de productnaam en prijs met het geselecteerde artikel uit het zoekresultaat.

Transities

De pijltjes tussen twee toestanden heten transities. Transities komen overeen met óf het voornemen om iets te gaan doen óf de daadwerkelijke handeling. De transitie Click on More klikt op de ‘More’-knop van een product uit het zoekresultaat. De transitie Search for non-existing product voert een term in het zoekveld in en klikt op de zoekknop. Middels een transitie beland je in een nieuwe toestand waarbij de controles worden uitgevoerd die daarin zijn vastgelegd.

Testuitvoering

Voor het uitvoeren van de test maak ik gebruik van een dataset waarin een verzameling zoektermen staat. Dit model bevat twee datasets: één met niet bestaande productnamen en één met bestaande productnamen.

De test is uitgevoerd met een random algoritme met als stopconditie een executietijd van 1 minuut. Op basis van deze parameters en het model heeft TestOptimal zes testgevallen afgeleid en uitgevoerd. Om enig gevoel te krijgen bij deze gegenereerde testgevallen heb ik in onderstaande tabel per testgeval aangegeven uit hoeveel stappen deze bestaat.

ID Testgeval Aantal stappen
TC01 3
TC02 7
TC03 3
TC04 55
TC05 27
TC06 18

Testgevallen TC01 en TC03 doorlopen hetzelfde pad. Dat kan gebeuren en dat is ook niet erg. Een klein model én de keuze voor een random algoritme vergroten die kans. Bovendien: bij elke passage van een transitie met dataset wordt telkens nieuwe data opgehaald en gebruikt in de volgende stappen van de test. Dit geldt zowel voor verschillende als voor identieke testgevallen. Dus al is het pad identiek, er kan variatie zitten in de data die gebruikt wordt. In onderstaande figuur heb ik de doorlopen teststappen voor twee testgevallen (TC04 en TC05) geplot op het model van de webshop.

Image

Het is heel duidelijk te zien dat beide automatisch gegenereerde testgevallen heel anders door de applicatie heen lopen dan een tester ooit kan bedenken en uitvoeren (handmatig dan wel geautomatiseerd). De langere testgevallen zijn interessant omdat vaak nieuwe inzichten ontstaan als vaker dezelfde functionaliteit wordt geraakt. Blijft de applicatie hetzelfde reageren als een functionaliteit 10x wordt herhaald binnen één testgeval?

In mijn volgende blog ga ik hier dieper op in en beschrijf ik de gevolgen voor de testuitvoering bij verschillende algoritmes waarmee de testgevallen worden gegenereerd.

Delen:

Ed Hilkman

Ed Hilkman is Testconsultant met ruim 20 jaar ervaring in het testen van software. Hij is gespecialiseerd in testautomatisering en technisch testen.
Bekijk de LinkedIn pagina van Ed Hilkman