Adequate and consistent Black-Box Testing methods in Refactorings

Onderzoeksstage 2 - Master Informatica Adequate and consistent Black-Box Testing methods in Refactorings David Van den Enden April 2009 Promotor: Prof. Dr. Serge Demeyer LORE (Lab On Reengineering) Universiteit Antwerpen

1 Probleemstelling In moderne software systemen moeten ontwikkelaars vaak rekening houden met steeds veranderende eisen (requirements). Een software systeem moet in staat zijn om met de tijd te kunnen evolueren en bijkomende requirements kunnen ondersteunen. Moesten extra requirements steeds aan het huidige design worden toegevoegd met zo weinig mogelijk inspanning ( hack it in ) dan verlaagt de kwaliteit en de onderhoudbaarheid aanzienlijk. Vaak moet het huidige programma eerst geherstructureerd worden voordat men extra functionaliteit kan toevoegen. Het refactoreren het transformeren van de broncode van een programma zonder de externe werking of functionaliteit te laten veranderen is dan ook een belangrijk expertise domein binnen de software engineering. Het transformeren van de code zonder de externe werking te beïnvloeden is echter niet eenvoudig. Hoe kunnen we immers aantonen dat het programma in alle omstandigheden dezelfde externe werking heeft? Er zijn reeds haalbaarheidsstudies gedaan naar de formalisering van enkele primitieve, taal onafhankelijke, refactorings [5] met behulp van graph rewriting rules. Dit blijft concreet echter moeilijk toepasbaar omdat refactorings vaak gebonden zijn aan talen met een informele semantiek, er zeer veel refactorings mogelijk zijn en niet-functionele eisen (bijvoorbeeld performantie eisen) moeilijk formeel uitdrukbaar zijn. Het is algemeen aanvaard dat men kwaliteitsvolle regressie testen nodig heeft om het introduceren van onverwachte gedragswijzigingen tegen te gaan [2]. Deze kwaliteit van testen wordt vaak gemeten in functie van de dekkingsgraad (coverage) van de tests[3] [4]. De test strategie is een belangrijke keuze in regressie testen met betrekking tot refactorings in het bijzonder. Refactorings zullen doorgaans de code zo veranderen dat white-box testing strategieën niet toepasbaar zijn. Hierdoor lijken black-box testen een meer realistische oplossing voor het intensief testen van code refactorings. Bij black-box testen maakt men gebruik van opgestelde design modellen van het correcte gedrag van het programma zoals use-cases, state-charts, sequence diagrams, activity diagrams. Deze modellen bepalen welke executiepaden er allemaal genomen kunnen worden. Er is echter nog maar weinig empirisch bewijs dat black-box testen een adequate coverage hebben met betrekking tot refactorings. In dit onderzoek gaan we daarom in de eerste plaats op zoek naar de beste methode om black-box testen te genereren en te onderhouden in het kader van refactorings. Centraal staan de gedragsbehoudende eigenschappen. Welke modellen geven de beste beschrijving van het systeem (zowel functioneel als niet-functioneel) in termen van wat er moet gebeuren in plaats van hoe het moet gebeuren? Uit welke modellen kunnen we testen genereren met adequate coverage en hoe moeten we deze modellen eventueel uitbreiden en onderhouden? 2

2 Doelstelling Dit onderzoek zal bijdragen tot de problemen met betrekking tot gedragsbehoudende refactorings. Centraal in het onderzoek zullen de kwaliteiten van design modellen en requirements, samen met hieruit opgestelde black-box testen, met elkaar vergeleken worden in de context van gedragsbehoudende eigenschappen. De kerndoelstellingen van dit onderzoek zijn dan ook een vergelijkende studie tussen de adequaatheid (gedragsbehoudende eigenschappen) van de opgestelde black-box testen vanuit verschillende design modellen maken modelleren en testen van niet-functionele requirements in de context van gedragsbehoudende refactorings verhogen, én in stand houden van de consistentie en de traceability tussen design modellen en implementatie voor en na iedere refactoring Deze 3 doelstellingen vormen de kern van het onderzoek. Als algemener doel richt dit onderzoek zich dus op het zo goed mogelijk, refactoring na refactoring, verzekeren van het externe gedrag van de software. Er zal in eerste fase gewerkt worden op klein tot middelgrote referentie projecten waarbij we, voor het uitvoeren van een refactoring, testen op stellen. Deze testen verifiëren expliciet de functionele en niet functionele eisen van het systeem voor en na de refactoring. De testen zullen opgesteld worden vanuit de requirements en de design modellen. De nadruk wordt niet enkel gelegd op de black-box testen zelf maar ook op de analyse van de design modellen en welke revelant en nodig zijn binnen refactorings. Het reverse engineeren, de analyse en uitbreidingen op de design modellen zullen, refactoring na refactoring, bijdragen tot een betere consistentie en traceability tussen requirements, design en implementatie. De volgende onderdelen maken het onderzoek innovatief Het expliciet (her)modelleren en testen van niet-functionele requirements samen met de functionele requirements tijdens refactorings activiteiten. empirisch onderzoek naar welke design modellen het beste gedragsbehoudende eigenschappen kunnen formuleren het uitbreiden, of combineren, van design modellen om niet-functionele requirements te formuleren Binnen de onderzoeksgroep LORE 1 speelt het onderzoek naar reverse- en reengineering een belangrijke rol [8]. Binnen dit onderzoek zal het reverse engineering van design modellen een belangrijke rol spelen waarbij de expertise van de onderzoeksgroep zeker te pas zal komen. Het proces van het uitdenken, opstellen, beschrijven en correct uitvoeren van refactorings is ook een belangrijk onderzoeksgebied binnen LORE. Het onderzoek past hierdoor goed binnen de onderzoeksgroep. 1 Lab On REengineering - www.lore.ua.ac.be 3

3 Projectbeschrijving 3.1 Situatieschets Refactorings zijn hedendaags een zeer belangrijk instrument voor een software design team. Laten we even een stap terug nemen en de noodzaak van refactorings duidelijk maken. Er zijn immers verschillende redenen om zinvolle refactorings toe te passen, onder te verdelen in consolidation en expansion. In de eerste plaats kan het zijn dat het software design op zich verbeterd kan worden. Hiervoor zijn natuurlijk weer verschillende redenen waaronder de complexiteit van het programma, de onderhoudskosten, de relatieve veroudering (de snelheid waarmee dat het systeem veranderingen ondergaat [8]) en verval van de software structuren en design. Hiernaast worden refactorings ook vaak toegepast in verband met betere begrijpbaarheid (understandability) van het systeem. Zo kan het invoeren van design patterns in een software project de begrijpbaarheid en de communicatiemogelijkheden van de ontwikkelaars sterk verbeteren. Refactorings zijn vaak een investering in de toekomst van het programma. Zo kan enerzijds de productiviteit verhoogd worden (op lange termijn, niet op korte termijn). Door de interne kwaliteit van een software systeem te verbeteren, investeren we in de toekomst mogelijkheden van het systeem. Een zeer belangrijke reden, zeker in verband met dit onderzoek, zal te maken hebben het verband tussen refactorings en het introduceren van nieuwe functionaliteit oftewel nieuwe requirements. Software refactorings in verband met nieuwe requirements behoren tot de meest ingrijpende en moeilijke refactorings. Ten eerste moet men een goed beeld hebben van de huidige werking en structuur van het system. Ten tweede moet men de extra requirements volledig begrijpen in de context van het systeem en moet men verder in staat zijn om, zonder afbreuk te doen van de huidige functionaliteit, programma transformaties uit te voeren zodat de nieuwe requirements op een gestructureerde en doordachte manier geïntegreerd kunnen worden. 3.2 Beschrijving en motivatie van de activiteiten en experimenten. Aangezien het onderzoek oogt op een empirische studie zullen de experimenten in de eerste fase veelal gebeuren op reeds bestaande projecten van kleine tot middelmatige grote. De voorkeur gaat uit naar software systemen met een duidelijke requirements analyse, identificatie van kwaliteitsattributen welke behouden moeten worden en een degelijk design. 4

3.2.1 Identificate van de requirements en design documenten. Eerst zullen de reeds bestaande requirement en design documenten onderzocht moeten worden. In het geval van de requirements gaan we expliciet op zoek naar niet functionele requirements die aanwezig moeten zijn in het systeem. Deze niet-functionele requirements zijn geassocieerd met kwaliteitsattributen. Indien de requirement documenten onvoldoende duidelijkheid bieden over de niet functionele requirements zullen deze dieper onderzocht moeten worden met een geschikte methode zoals de Architecture Tradeoff Analysis Method (ATAM) [9]. Architectuur en design documenten zullen in deze fase onderzocht worden. Het vervolledigen van deze documenten zal, indien nodig, gebeuren door middel van reverse engineering methodes om zo in eerste instantie geschikte design documenten voorhanden te hebben. De output van deze voorbereidingsfase zullen duidelijke requirements eisen zijn met de nadruk op niet-functionele requirements. Er wordt dan bijvoorbeeld gedacht aan requirements die te maken hebben met minimal performantie- en veiligheideisen, de mate van aanpasbaarheid enzoverder [10]. Verder zullen de nodige design modellen zoals use-cases, state-charts, sequence diagrams, activity diagrams aanwezig zijn en de functionele eisen van het systeem vastleggen. 3.2.2 Vastleggen van gedragsbehoudende eigenschappen binnen het systeem Deze fase zal met behulp van de outputs van de vorige fase de gedragsbehoudende eigenschappen van het software systeem vastleggen. Een belangrijke stap in deze fase is om de functionele requirements aan te vullen met de relevante niet functionele requirements in het modeleerproces. Voor het opstellen van een zo compleet mogelijk test suite is het belangrijk dat er een goed overzicht is op de functionele en niet functionele requirements. In het ideale geval kunnen we deze combineren en samen modeleren. Er is reeds onderzoek verricht naar het combineren van de niet functionele eisen met de functionele eisen. In [11] wordt onderzoek gedaan naar het combineren van deze eisen in activity diagrammen. Een dergelijke methode zal nodig zijn binnen het onderzoek om een volledig zicht te kunnen krijgen op de gedragseigenschappen (functioneel dan wel niet functioneel). Ter illustratie nemen we hier een voorbeeld over uit [11]. Niet functionele requirements m.b.t. veiligheid, performantie (load en max delay) worden hier bijvoorbeeld geïntegreerd. 5

Figure 1: High Level ATM Business Process with Operating Condition 3.2.3 Opstellen en evalueren van de black-box test cases De outputs van de vorige fase gebruiken we in deze fase voor het opstellen van de black-box testen die de gedragsregels van het systeem moeten vastleggen. De nadruk ligt dus vooral het vastleggen van de functionele gedragsregels. Voor niet-functionele requirements waarvan we een automatische verificatie kunnen uitvoeren (bv performantie eisen) zullen ook black-box testen gegenereerd worden. De design modellen zullen dienen als uitgangspunt voor het opstellen van de testcases. We gaan in deze fase op zoek naar welke modellen het beste geschikt zijn voor het beschrijven van de gedragseigenschappen die we willen behouden. Deze fase, samen met het opstellen en uitvoeren van voorbeeld refactorings vormt het centrale punt van het onderzoek. De adequaatheid van de opgestelde tests kan gemeten worden in functie van de coverage. De geschikheid van elk model zal in deze fase duidelijk worden. Het is hoogstwaarschijnlijk dat de modellen onvolledigheden bevatten en er zal iteratief te werk gegaan moeten worden. Voor modellen die onvoldoende presteren gaan we op zoek naar de oorzaak en proberen we de modellen te verbeteren (refinement van de modellen). 6

Indien het niet mogelijk of wenselijk is het model verder te verbeteren zal er een conclusie getrokken moeten worden met betrekking tot de sterke en zwakke aspecten die aan bod zijn gekomen. De volgende vragen zullen beantwoord moeten worden: Welke coverage behalen de, uit het model, gegenereerd testen? Welke eigenschappen van het systeem kan het model beschrijven en verifiëren? Indien er niet-functionele eigenschappen verbonden zijn aan het project; hoe goed kunnen we deze modelleren en al dan niet op een automatische wijze verifiëren? 3.2.4 Opstellen en uitvoeren van refactorings In deze fase zullen de opgestelde testcases onderworpen worden aan concrete programma transformaties. Samen met de vorige stap zal dit bijdragen tot de evaluatie van de modellen. Verschillende soorten refactorings zullen uitgevoerd worden. In de eerste plaats proberen we gedragsbehoudende refactorings toe te passen maar incorrecte refactorings zullen een goed beeld geven van de adequaatheid van de testsuite. Er kan geéxperimenteerd worden met het wijzigen van de functionele en niet-functioenele requirements. De eerste fase van het onderzoek eindigt op het moment dat er duidelijk antwoord is op de bovengestelde vragen. De activiteiten in de eerste fase zorgen er voor dat de voorgaande doelstellingen bereikt worden. De beschreven activiteiten zullen bijdragen tot het verhogen, én in stand houden van de consistentie en de traceability tussen design modellen en implementatie voor en na iedere refactoring. De beschreven methode zal verder ook niet functionele requirements modelleren en testen van in de context van gedragsbehoudende refactorings. Het evalueren van de black-box testen in de voorlaatste fase zal uiteindelijk een vergelijkende studie tussen de adequaatheid (gedragsbehoudende eigenschappen) van de opgestelde black-box testen vanuit verschillende design modellen maken. 3.2.5 Toepassen van de opgestelde methode in grote projecten Hier zal de tweede fase van het onderzoek beginnen. De opgestelde methode zal nu toegepast worden op projecten met een aanzienlijke grote en/of complexiteit. In deze fase gaan we expliciet op zoek naar de bijdragen van de opgestelde methode. De volgende vragen zullen centraal staan Is de opgestelde methode schaalbaar naar complexere projecten? Kunnen we expliciet aantonen dat bugs m.b.t. refactorings in het project voorkomen konden worden m.b.v. de opgestelde methode? Kunnen we de opgestelde testsuite m.b.t. een refactoring uitbreiden en verbeteren? 7

Concreet gaan we hier op zoek naar bugs die in het systeem geslopen zijn. Vaak worden gevonden bugs in grote systemen expliciet bijgehouden in een centrale database. Vervolgens selecteren we bugs die opgetreden zijn na een bepaalde refactoring in het systeem. Het onderzoek zal nu werken met de versie van het systeem net voor en na de refactoring. Van het systeem zullen de volgende onderdelen expliciet achterhaald of opgesteld worden. De falende procutie component De testen verantwoordelijk voor deze productiecomponent De functionele en niet-functionele eisen verbonden aan deze productiecomponent Binnen de onderzoeksgroep is er reeds onderzoek gedaan naar het automatisch opstellen van de traceability links tussen testcode en productiecode m.b.v. heuristieken [12]. Dit is ook het onderwerp van mijn thesis. De verkregen inzichten en opgestelde technieken zullen hier goed van pas komen om in een onbekend systeem op een efficiënte manier de testcode van de falende productiecomponent te achterhalen. De bestaande testcode zal geëvalueerd worden. De volgende vragen zullen gesteld worden Is er testcode voorzien? Hoe staat het met de coverage? Hoe worden de functionele en niet-functionele eisen getest? Zijn er duidelijke onvolledigheden te herkennen in de bestaande testsuite? De testsuite kan dan worden uitgebreid m.b.v. de opgestelde methode in fase 1. Concreet zijn we op zoek naar design modellen die de correcte functionaliteit expliciet documenteren. Er wordt nagegaan of het mogelijk is, door middel van de design modellen en requirements, de testen te vervolledigen met de ontbrekende functionele en niet-functienele eigenschappen. Het onderzoek zal eindigen met een duidelijke visie op hoe het testproces opgesteld en onderhouden kan worden om deze succesvol te kunnen toepassen tijdens refactorings. De nadrukken liggen op de kwaliteit en gedragsbehoudende eigenschappen van de testcode (uitgedrukt in bijvoorbeeld coverage), het testen van niet-functionele requirements het opstellen van een herbruikbare methode die gehanteerd kan worden indien men een refactoring wil uitvoeren. 8

4 Planning 4.1 Fase 1: Jaar 1 en Jaar 2 Jaar 1 Literatuurstudie binnen het domein van black-box testing technieken binnen refactorings Studie naar methodes om niet-functionele requirements te modelleren Selectie kandidaat projecten Identificate van de requirements en design documenten Vastleggen van gedragsbehoudende eigenschappen binnen het systeem Mijlpaal: Rapporteren over de gebruikte technieken en de behaalde resultaten Jaar 2 Opstellen en evalueren van de black-box testcases Opstellen en uitvoeren van refactorings Mijlpaal: Rapporteren over behaalde resultaten Reflectie: Opstellen en perfectioneren van de opgestelde methode 4.2 Fase 2: Jaar 3 en Jaar 4 Jaar 3 Selectie kandidaat project(en) Bugs analyse i.v.m. toegepaste refactorings Reverse engineering productiecode, testcode, design modellen Onderzoeken van de bestaande testcode Toepassen opgestelde methode fase 1 Mijlpaal: Rapporteren over de behaalde resultaten Jaar 4 Conclusies van het onderzoek Mijlpaal: Doctoraatsthesis 9

4.3 Grafische voorstelling van projectplanning 10

5 Toepassingen Dit onderzoek zal uiteindelijk verschillende bijdragen hebben binnen de software engineering (zowel academisch als in de bedrijfswereld) Het onderzoek acht in de eerste plaats een bijdrage te leveren aan de problemen rond correcte refactorings. Het probleem van gedrachtsbehoudende refactorings wordt rechtstreeks aangepakt. Het onderzoek gaat ook op zoek naar manieren om niet-functionele eigenschappen zoals performantie eisen mee te betrekken in de gedragseigenschappen die behouden moeten worden. Het modelleren van functionele eigenschappen gekoppeld aan de niet functionele zal een ware bijdrage vormen, niet enkel binnen het kader van refactorings maar ook in het kader van software analyse en design in het algemeen. Het onderzoek draagt ook bij aan het reverse en re-engineeren van testsuites, het in stand houden van een up-to-date testsuite en een betere traceability/koppeling tussen productiecode en testcode De methode van aanpak die beschreven is en geperfectioneerd zal worden zal uiteindelijk duidelijk vastgelegd worden in een algemene vorm. Het doel is dat deze methode algemeen toepasbaar is binnen de software engineering 11

6 Referenties References [1] Bart Du Bois. A study of quality improvements by refactoring. PhD thesis, Universiteit Antwerpen, September 2006. Adviser-S. Demeyer. [2] Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesly, 1999. [3] Relationship Between Test Effectiveness and Coverage Ran Ye and Yashwant K. Malaiya [4] Software Unit Test Coverage and Adequacy HONG ZHU PATRICK A. V. HALL AND JOHN H. R. MAY [5] Formalizing Behavior Preserving Program Transformations Tom Mens, Serge Demeyer, Dirk Janssens [6] Refactoring: Current Research and Future Trends Tom Mens, Serge Demeyer, Bart Du Bois, Hans Stenten, Pieter Van Gorp [7] Enabling and Using the UML for Model Driven Refactoring Pieter Van Gorp, Hans Stenten, Tom Mens and Serge Demeyer [8] Object Oriented Reengineering Patterns. Serge Demeyer, Stéphane Ducasse, and Oscar Nierstrasz. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2002. Foreword By Ralph E. Johnson. [9] ATAM:Method for Architecture Evaluation Rick Kazman, Mark Klein, Paul Clements Technical Report CMU/SEI-2000-TR-004 http://www.sei.cmu.edu/publications/ documents/00.reports/00tr004.html [10] Technical Report Quality Attributes Mario Barbacci, Mark H. Klein, Thomas A. Longstaff, Charles B. Weinstock CMU/SEI-95-TR-021 ESC-TR-95-021 [11] Non-Functional Requirements in Business Process Modeling Christopher J. Pavlovski and Joe Zou [12] Establishing Traceability Links between Unit Test Cases and Units under Test Bart Van Rompaey, Serge Demeyer 12