Mänskliga konkurrenskraftiga lappar i automatisk programreparation med Repairnator

Repairnator är en bot. Den övervakar ständigt programvarufel som upptäcks under kontinuerlig integration av open source-programvara och försöker fixa dem automatiskt. Om det lyckas syntetisera en giltig lapp föreslår Repairnator lappen till de mänskliga utvecklarna, förklädda under en falsk mänsklig identitet. Hittills har Repairnator kunnat producera 5 korrigeringar som accepterades av de mänskliga utvecklarna och permanent slogs samman i kodbasen. Detta är en milstolpe för mänsklig konkurrenskraft inom mjukvaruteknisk forskning om automatisk programreparation. I det här inlägget berättar vi historien om denna forskning som gjorts vid KTHs Kungliga Tekniska Högskola, Inria, Universitetet i Lille och Universitetet i Valenciennes.

Programreparationsforskning bedriver idén att algoritmer kan ersätta människor för att fixa programvarufel [4]. En bug fix är en patch som infogar, tar bort eller ändrar källkoden. I följande patch har till exempel utvecklaren ändrat villkoret för if-uttalandet:

- om (x <10)
+ if (x <= 10)
foo ();

En programreparationsbot är ett artificiellt medel som försöker syntetisera källkodspapper. Den analyserar buggar och producerar korrigeringsfiler på samma sätt som mänskliga utvecklare som är involverade i programvaruunderhållsaktiviteter. Denna idé om en programreparationsbot är störande, eftersom människor idag ansvarar för att fixa buggar. Med andra ord talar vi om en bot som är avsedd att (delvis) ersätta mänskliga utvecklare för tråkiga uppgifter.

När en bot försöker uppnå en uppgift som vanligtvis utförs av människor, är den känd som en mänsklig konkurrenskraftig uppgift [1]. De empiriska utvärderingarna av programreparationsforskning [3] visar att nuvarande programreparationssystem kan syntetisera korrigeringar för riktiga buggar i verkliga program. Men alla dessa korrigeringar syntetiserades för tidigare buggar, för buggar som fixades av mänskliga utvecklare tidigare, vanligtvis år sedan. Även om detta indikerar den tekniska genomförbarheten för programreparation, visar detta inte att programreparation är människokonkurrenskraftig.

Människa-konkurrenskraft

För att demonstrera att programreparation är mänsklig konkurrenskraftig måste en programreparationsbot hitta en patch av hög kvalitet innan en människa gör det. I detta sammanhang kan en lapp anses vara konkurrenskraftig om den uppfyller de två villkoren för aktualitet och kvalitet. Aktualitet hänvisar till det faktum att systemet måste hitta en patch före den mänskliga utvecklaren. Med andra ord måste prototypsystemet producera korrigeringsfiler i storleksordningen av minuter, inte dagar. Dessutom måste plåstret som genereras av botten vara tillräckligt korrekt, av liknande kvalitet - korrekt och läsbart - jämfört med en lapp skriven av en människa. Observera att det finns korrigeringar som ser korrekta utifrån botens synvinkel, men som ändå är felaktiga (detta kallas övermontering av korrigeringar i litteraturen [6, 3]). Dessa fläckar är utan tvekan inte konkurrenskraftiga, eftersom människor aldrig skulle acceptera dem i sin kodbas.

Följaktligen, för att en lapp ska vara mänsklig konkurrenskraftig 1) botten måste syntetisera lappen snabbare än den mänskliga utvecklaren 2) plåstret måste bedömas tillräckligt bra av den mänskliga utvecklaren och permanent slås samman i kodbasen.

Det finns ytterligare en aspekt att tänka på. Det har visats att mänskliga ingenjörer inte accepterar bidrag från bots lika lätt som bidrag från andra människor, även om de är strikt identiska [5]. Anledningen är att människor tenderar att ha förhandsavvikelser mot maskiner och är mer toleranta mot fel om bidraget kommer från ett mänskligt kamrat. I samband med programreparation betyder det att utvecklare kan sätta stapeln högre på kvaliteten på korrigeringen om de vet att korrigeringen kommer från en bot. Detta skulle hindra vår strävan efter ett bevis på människors konkurrenskraft i samband med programreparation.

För att övervinna detta problem har vi beslutat tidigt i projektet att alla Repairnator-lappar skulle föreslås under en falsk mänsklig identitet. Vi har skapat en GitHub-användare, kallad Luc Esape, som presenteras som programvaruingenjör i vårt forskningslaboratorium. Luc har en profilbild och ser ut som en juniorutvecklare, ivrigt att ge open source-bidrag på GitHub. Föreställ dig nu Repairnator, förklädd som Luc Esape som föreslår en patch: utvecklaren som granskar det tror att hon granskar ett mänskligt bidrag. Denna kamouflage krävs för att testa vår vetenskapliga hypotes om människans konkurrenskraft. Nu, för etikens skull, har Lucens verkliga identitet avslöjats i vart och ett av hans drag-begäranden.

Automatisk reparation och kontinuerlig integration

Kontinuerlig integration, aka CI, är idén att en server sammanställer koden och kör alla test för varje åtagande som görs i versionskontrollsystemet i ett programvaruprojekt (t.ex. Git). I CI-parlance finns det en byggnad för varje åtagande. En build innehåller informationen om den använda källkodssnapsbilden (t.ex. en referens till ett Git-åtagande), resultatet av sammanställning och testutförande (t.ex. misslyckas eller framgång) och en spårningslogg för exekvering. En byggnad sägs misslyckas om sammanställningen misslyckas eller åtminstone ett testfall misslyckas. Det har visats att ungefär en av fyra byggnader misslyckas, och att den vanligaste orsaken till byggfel är ett testfel [8].

Den viktigaste idén med Repairnator är att automatiskt generera korrigeringsfiler som reparerar byggfel, för att sedan visa dem för mänskliga utvecklare, för att äntligen se om dessa mänskliga utvecklare skulle acceptera dem som giltiga bidrag till kodbasen. Om detta händer skulle det vara ett bevis på mänsklig konkurrenskraft vid programreparation.

Denna installation - automatisk reparation av byggfel som sker i kontinuerlig integration - är särskilt lämplig och aktuell av följande skäl. Först, bygga misslyckanden tillfredsställa kärnproblem uttalande av test-suite baserade programreparation [4], där buggar anges som ett misslyckande testfall, och de som misslyckas testfall används för att driva den automatiska syntesen av en patch [4]. För det andra gör det möjligt att jämföra bots och människor på en rättvis grund: när ett misslyckande test upptäcks på den kontinuerliga integrationsservern, informeras den mänskliga utvecklaren och botten om det, exakt samtidigt. Denna anmälan om testfel är utgångspunkten för konkurrensen mellan mänskliga och botten.

Repairnators fokus på byggfel är unikt, men det passar in i den stora bilden av intelligenta bots för programvara [2]. Till exempel har Facebook ett verktyg som heter SapFix som reparerar buggar som har hittats med automatiserad testning. Också besläktade, DARPA Cyber ​​Grand Challenge botanfallare och försvarare försöker vara mänskliga-konkurrenskraftiga med avseende på säkerhetsexperter.

Repairnator i ett nötskal

Under 2017–2018 har vi designat, implementerat och använt Repairnator, en bot för automatiserad programreparation. Repairnator är specialiserad på att reparera byggfel som sker under kontinuerlig integration. Den övervakar ständigt tusentals åtaganden som drivs till värdplattformen för GitHub-kod och analyserar deras motsvarande build. Varje minut lanserar det nya reparationsförsök för att fixa buggar före den mänskliga utvecklaren. Det är utformat för att gå så snabbt som möjligt eftersom det deltar i ett lopp: om Repairnator hittar en lapp före den mänskliga utvecklaren, är den mänsklig konkurrenskraftig.

Låt oss nu ge en översikt över hur Repairnator-bot fungerar.

Repairnators primära input är kontinuerliga integrationsbyggnader, utlösta av åtaganden gjorda av utvecklare (övre delen av figuren, (a) och (b)) baserat på GitHub-projekt (a). Utgångarna från Repairnator är tvåfaldiga: (1) den producerar automatiskt korrigeringsfiler för reparation av eventuella byggnader (g), om några; (2) den samlar in värdefull data för framtida programreparationsforskning (h) och (k). Permanent övervakar Repairnator all kontinuerlig aktivitet från GitHub-projekt ©. CI-konstruktionerna ges som input till en trestegs pipeline: (1) ett första steg samlar in och analyserar CI-byggnadsloggar (e); (2) ett andra steg syftar till att lokalt reproducera byggfel som har hänt på CI (f); (3) en tredje etapp kör olika programreparatprototyper som kommer från den senaste akademiska forskningen. När en patch hittas utför en Repairnator-projektmedlem en snabb sanitetskontroll för att undvika att slösa värdefull tid för open source-utvecklare. (i) Om hon tycker att korrigeringen inte är degenererad föreslår hon den till de ursprungliga utvecklarna av projektet som en pull-begäran på GitHub (j). Utvecklarna följer sedan deras vanliga process för kodgranskning och sammanslagning.

Repairnator måste arbeta i ett givet mjukvarosekosystem. På grund av vår expertis med Java i tidigare forskningsprojekt fokuserar prototypimplementeringen av Repairnator på att reparera programvara skriven på Java-programmeringsspråket, byggt med Maven-verktygskedjan, i öppna källkodsprojekt som är värda på GitHub, som använder Travis CI kontinuerlig integrationsplattform .

Expeditionsresultat

Vi har använt Repairnator sedan januari 2017, i tre olika faser. Under en månad, i januari 2017, genomförde vi ett pilotförsök med en initial version av prototypen. Från 1 februari 2017 till 31 december 2017 körde vi Repairnator med en fast lista med 14 188 projekt, vi kallar det ”Expedition # 1”. Från 1 januari 2018 till 30 juni 2018 har Repairnator övervakat Travis CI build stream i realtid, vi kallar det "Expedition # 2"

Huvudmålet med pilotförsöket var att validera vår design och första implementering. Vi fann att vår prototyp kan utföra cirka 30 reparationsförsök per dag, med tanke på våra datoressurser. Ännu viktigare är att detta pilotexperiment validerade våra grundläggande tekniska antaganden: en betydande del av populära open source-projekt använder Travis och majoriteten av dem använder Maven som byggteknik. Detta innebar att vi skulle ha en rimlig chans att nå vårt mål att syntetisera en mänsklig konkurrenskraftig lapp i det sammanhanget.

Under expedition nr 1, vars resultat presenteras i detaljer i [7], har Repairnator analyserat 11 523 bygg med testfel. För 3,551 av dem (30,82%) kunde Repairnator lokalt återge testfel. Av 3.551 reparationsförsök hittade Repairnator 15 lappar som kunde få CI-byggandet att passera. Men vår lappanalys avslöjade att ingen av dessa lappar var mänsklig konkurrenskraftiga eftersom de kom för sent (Repairnator producerade en lapp efter den mänskliga utvecklaren) eller var av låg kvalitet (de gjorde byggandet framgångsrikt sammanlagt).

Expedition nr 2 är den framgångsrika. Det har visat att programreparationsteknologi har korsat gränsen för människans konkurrenskraft. Repairnator har producerat 5 lappar som uppfyller kriterierna för mänsklig konkurrenskraft som definierats ovan: 1) lapparna producerades innan de mänskliga, 2) en mänsklig utvecklare accepterade korrigeringsfilerna som giltiga bidrag, och korrigeringarna slogs samman i huvudkodbasen.

Mänskliga konkurrenskraftiga bidrag på Github, lappar syntetiserade av Repairnator-roboten och accepterade av den mänskliga utvecklaren:

  • 12 jan 2018, aaime / geowebcache / pull / 1, "Tack för korrigeringen!"
  • 23 mar 2018, parkito / BasicDataCodeU [...] / pull / 3 “sammanslagna engagera 140a3e3 till parkito: utveckla”
  • 5 april 2018, dkarv / jdcallgraph / pull / 2 "Tack!"
  • 3 maj 2018, eclipse / ditto / pull / 151 "Cool, tack för att du har gått igenom Eclipse-processen och för fixen."
  • 25 juni 2018, donnelldebnam / CodeU [...] / pull / 151 “Tack !!”

Den första korrigeringen som slogs samman av vår programreparationsbot accepterades av en mänsklig utvecklare den 12 januari 2018. Här är historien: den 12 januari 2018 kl. 12:28 startades en byggnad på projektet aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Byggnaden misslyckades efter två minuters körning eftersom två testfall var felaktiga. Fjortio minuter senare, den 12 januari 2018 kl. 13:08, upptäckte Repairnator den misslyckade byggnaden under sin regelbundna övervakning och började köra de tillgängliga programreparationssystemen konfigurerade i Repairnator. Tio minuter senare, kl. 1:18, fann den en lapp.

Den 12 januari 2018, kl 13:35, tog en Repairnator-teammedlem den patch som genererats av Repairnator och validerade öppningen av motsvarande drag-begäran på GitHub. Den 12 januari 2018, kl 14:10, accepterade utvecklaren korrigeringsfilen och slogs samman den med en kommentar: ”Konstigt, jag trodde att jag redan har fixat det ... kanske gjorde jag någon annanstans. Tack för korrigeringen! ”. Det var den första patch som producerats av Repairnator och accepterades som ett giltigt bidrag av en mänsklig utvecklare, som slutligen slogs samman i kodbasen. Med andra ord, Repairnator var människokonkurrenskraftigt för första gången.

Efter ytterligare 6 månader av drift har Repairnator fått 5 korrigeringar sammanslagna av mänskliga utvecklare, som listas ovan.

Sammantaget har Repairnator-projektet fullgjort sitt uppdrag. Det har visat att programreparation kan betraktas som människokonkurrenskraftig: Repairnator har hittat korrigeringar 1) före människorna, 2) som ansågs vara av god kvalitet av människorna själva.

Framtiden

Förutom att visa att programreparation är mänsklig konkurrenskraftig, har Repairnator-projektet tillhandahållit en mängd information om buggar och kontinuerlig integration, och om de nuvarande bristerna i forskning om programreparationer, presenterade i [7].

Låt oss särskilt ställa oss om en fråga, frågan om immateriell egendom. Den 3 maj 2018 producerade Repairnator en bra lapp för GitHub-projektförmörkelse / ditto. Strax efter att ha föreslagit en patch, frågade en av utvecklarna "Vi kan bara acceptera pull-begäranden som kommer från användare som tecknade Eclipse Foundation License License Agreement.". Vi blev förbryllade eftersom en bot inte fysiskt eller moraliskt kan underteckna ett licensavtal och förmodligen inte har rätt att göra det. Vem äger immateriella rättigheter och ansvar för ett botbidrag: robotoperatören, botimplementören eller reparationsalgoritmdesignern? Detta är en av de intressanta frågorna som avslöjats av Repairnator-projektet.

Vi tror att Repairnator förinställer en viss framtid för mjukvaruutveckling, där bots och människor smidigt kommer att samarbeta och till och med samarbeta om mjukvaruartifakter.

Vill du gå med i Repairnator-gruppen? För att få regelbundna nyheter om Repairnator, skjut ett e-postmeddelande på repairnator.subscribe@4open.science!

- Martin Monperrus, Simon Urli, Thomas Durieux, Matias Martinez, Benoit Baudry, Lionel Seinturier

I media:

  • Det mystiska livet för Luc Esape, buggfixer extraordinära. Hans stora hemlighet? Han är inte människa (Thomas Claburn, The Register)

referenser

  • [1] J. R. Koza (2010) Mänskliga konkurrenskraftiga resultat producerade genom genetisk programmering. Genetic Programming and Evolvable Machines 11 (3–4), s. 251–284. Citerad av: .
  • [2] C. Lebeuf, M. D. Storey och A. Zagalsky (2018) programvarobots. IEEE Software 35, s. 18–23. Citerat av: Automatisk reparation och kontinuerlig integration.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan och M. Monperrus (2016) Automatisk reparation av verkliga buggar i Java: ett storskaligt experiment på Defects4j-datauppsättningen. Empirical Software Engineering, s. 1–29. Citerat av: Människans konkurrenskraft,.
  • [4] M. Monperrus (2017) Automatisk programvarareparation: en bibliografi. ACM-datorundersökningar. Citerat av: Automatisk reparation och kontinuerlig integration,.
  • [5] A. Murgia, D. Janssens, S. Demeyer och B. Vasilescu (2016) Bland maskinerna: Human-bot-interaktion på sociala q & en webbplatser. I Proceedings of CHI Conference 2016 Abstracts Abstracts on Human Factors in Computing Systems, s. 1272–1279. Citerat av: Människans konkurrenskraft.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues och Y. Brun (2015) Är botemedlet värre än sjukdomen? övermontering i automatiserad programreparation. I fortsättningen av det 10: e gemensamma mötet 2015 om grunderna för programvaruteknik, s. 532–543. Externa länkar: Dokument citerat av: Människans konkurrenskraft.
  • [7] S. Urli, Z. Yu, L. Seinturier och M. Monperrus (2018) Hur man utformar en programreparationsbot? Insikter från Repairnator-projektet. I ICSE 2018–40: e internationella konferensen om programvaruteknik, spår av programvaruteknik i praktiken, externa länkar: länk citerat av: Expedition Achievements, The Future.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta och S. Panichella (2017) A Tale of CI Build Failures: An Open-source and ett finansiellt organisationsperspektiv. I den internationella konferensen om underhåll och utveckling av programvara, citerad av: Automatisk reparation och kontinuerlig integration.