CWI-onderzoeker Stijn de Gouw heeft een nieuwe techniek ontwikkeld voor het opsporen van bugs in software geschreven in objectgeoriënteerde talen zoals Java. In een eerste test stelde de techniek de correctheid vast van complexe software van e-commerce softwarebedrijf SDL Fredhopper. De Grouw verdedigt zijn proefschrift Combining Monitoring with Run-time Assertion Checking op 18 december 2013 aan de Universiteit Leiden. Zijn onderzoek is uitgevoerd op het Centrum Wiskunde en Informatica (CWI) en het Leiden Institute of Advanced Computer Science (LIACS) van de Universiteit Leiden.
Volgens recent onderzoek van Cambridge University veroorzaken softwarebugs jaarlijks voor 312 miljard dollar aan schade. Het voorkomen, isoleren en oplossen van bugs is daarom van groot belang. Eén methode om dit te doen is run time checking, een techniek die fouten opspoort tijdens het draaien van de code en het programma stopt zodra een ernstige fout optreedt. In objectgeoriënteerde talen zoals Java communiceren objecten met elkaar via berichten.
Rascal
Voor zulke talen controleert run time checking ofwel of de objecten in de juiste volgorde communiceren (monitoring) ofwel of de inhoud van de berichten correct is (run time assertion checking). De techniek die De Gouw heeft ontwikkeld met behulp van metaprogrammeertaal Rascal, combineert deze twee benaderingen op een unieke manier, door slim gebruik te maken van een zogenaamde attributengrammatica.
De nieuwe techniek is getest in samenwerking met SDL Fredhopper, een e-commerce softwarebedijf dat achter de schermen van meer dan driehonderd van de grootste webshops ter wereld actief is. De methode was in staat cruciale en complexe onderdelen van het Fredhopper Access Server (FAS) te testen, een softwaresysteem dat it-services voor zoekopdrachten en merchandise biedt aan e-commercebedrijven. Het was de eerste keer dat de correctheid van deze software kon worden vastgesteld.
Ik neem aan: “Het was de eerste keer dat de incorrectheid kon worden vastgesteld op een wijze anders dan het uitvoeren van bepaalde speciaal uitgekiende tests”.
Correctheid van programmatuur laten vaststellen door programmatuur is namelijk onmogelijk. Het uitrekenen of een software fragment in alle valide omstandigheden ueberhaupt termineert is al onbeslisbaar: “halting problem”. Laat staan of het met het juiste resultaat eindigt.
Alle vormen van geautomatiseerd testen gaan uit van aannames die ook weer fout kunnen zijn. Wel fijn dat er weer een vorm van testen is bijgekomen. Dit is altijd nuttig.
Als je tijdens runtime kan testen of het correct is lijkt het mij verstandiger om dit te doen voordat het in productie gaat.
Ik probeerde net de abstract hiervan af te drukken.
Helaas gaat het fout tijdens het afdrukken wegens een bug… 😉
Interessant bij systeemtest; eens kijken of het bruikbaar is met de aannames in het achterhoofd houdend.