Záplaty pro automatickou opravu programu pomocí opraváře

Opravář je bot. Neustále sleduje softwarové chyby objevené během nepřetržité integrace open-source softwaru a snaží se je automaticky opravit. Pokud se mu podaří syntetizovat platnou opravu, Repairnator navrhne opravu pro lidské vývojáře, skryté pod falešnou lidskou identitou. K dnešnímu dni byl opravář schopen vyrobit 5 záplat, které byly přijaty lidskými vývojáři a trvale sloučeny do kódové základny. Jedná se o milník pro konkurenceschopnost člověka ve výzkumu softwarového inženýrství v oblasti automatické opravy programu. V tomto příspěvku vyprávíme příběh o tomto výzkumu provedeném na KTH Royal Institute of Technology, Inria, University of Lille a University of Valenciennes.

Výzkum programových oprav sleduje myšlenku, že algoritmy mohou nahradit lidi opravovat softwarové chyby [4]. Oprava chyby je oprava, která vkládá, odstraňuje nebo upravuje zdrojový kód. Například v následující opravě vývojář upravil stav příkazu if:

- pokud (x <10)
+ pokud (x <= 10)
foo ();

Oprava programu bot je umělý agent, který se snaží syntetizovat záplaty zdrojového kódu. Analyzuje chyby a vytváří záplaty stejným způsobem jako lidské vývojáře zapojené do činností údržby softwaru. Tato myšlenka na opravu programu bot je rušivý, protože dnes lidé jsou zodpovědní za opravu chyb. Jinými slovy, mluvíme o botu, který má (částečně) nahradit lidské vývojáře únavnými úkoly.

Když se bot snaží dosáhnout úkolu, který obvykle vykonávají lidé, je znám jako lidský úkol [1]. Empirická hodnocení výzkumu oprav programů [3] ukazují, že současné systémy oprav programů jsou schopny syntetizovat záplaty pro skutečné chyby v reálných programech. Všechny tyto záplaty však byly syntetizovány pro minulé chyby, pro chyby, které byly opraveny lidskými vývojáři v minulosti, obvykle před lety. I když to naznačuje technickou proveditelnost opravy programu, neprokazuje to, že oprava programu je konkurenceschopná pro člověka.

Lidská konkurenceschopnost

Aby bylo prokázáno, že oprava programu je konkurenceschopná pro člověka, musí bota pro opravu programu najít kvalitativní náplast, než to člověk udělá. V této souvislosti lze náplast považovat za lidskou konkurenceschopnou, pokud splňuje dvě podmínky včasnosti a kvality. Včasnost odkazuje na skutečnost, že systém musí najít náplast před lidským vývojářem. Jinými slovy, prototypový systém musí produkovat záplaty v řádu minut, ne dní. Oprava generovaná robotem musí být dostatečně správná, podobné kvality - správná a čitelná - ve srovnání s náplastí napsanou člověkem. Všimněte si, že existují záplaty, které vypadají správně z pohledu bota, ale přesto jsou nesprávné (v literatuře se to nazývá přeplněné záplaty [6, 3]). Tyto záplaty pravděpodobně nejsou lidské konkurence, protože lidé je nikdy nepřijímají ve své kódové základně.

V důsledku toho, aby náplast byla lidskou konkurenční 1) bota musí syntetizovat náplast rychleji než lidský vývojář 2), musí být náplast lidským vývojářem dostatečně dobře posouzena a trvale začleněna do kódové základny.

Je třeba zvážit ještě jeden aspekt. Ukázalo se, že inženýři člověka nepřijímají příspěvky od robotů tak snadno jako příspěvky od jiných lidí, i když jsou přísně totožné [5]. Důvod je ten, že lidé mají tendenci mít a priori zaujatosti vůči strojům a jsou tolerantní k chybám, pokud příspěvek pochází od lidského vrstevníka. V souvislosti s opravou programu to znamená, že vývojáři mohou zvýšit úroveň kvality záplaty, pokud vědí, že oprava pochází z robota. To by bránilo našemu hledání důkazu konkurenceschopnosti člověka v souvislosti s opravou programu.

Abychom tento problém překonali, na začátku projektu jsme se rozhodli, že všechny opravy opraváře budou navrženy pod falešnou lidskou identitou. Vytvořili jsme uživatele GitHubu, jménem Luc Esape, který je prezentován jako softwarový inženýr v naší výzkumné laboratoři. Luc má profilový obrázek a vypadá jako juniorský vývojář, který se do GitHubu snaží přispívat otevřeným zdrojem. Nyní si představte opraváře, přestrojeného za Luc Esapea, který navrhuje opravu: vývojář, který si to prohlíží, si myslí, že zkoumá lidský přínos. Tato kamufláž je nutná k ověření naší vědecké hypotézy lidské konkurenceschopnosti. Nyní, kvůli etice, byla skutečná identita Luc zveřejněna na každé z jeho vyžádaných žádostí.

Automatické opravy a nepřetržitá integrace

Nepřetržitá integrace, aka CI, je myšlenka, že server kompiluje kód a provede všechny testy pro každý odevzdání provedené v systému řízení verzí softwarového projektu (např. Git). Ve větě CI je sestavení pro každý odevzdání. Sestavení obsahuje informace o použitém snímku zdrojového kódu (např. Odkaz na Git commit), výsledek kompilace a provádění testu (např. Selhání nebo úspěch) a protokol trasování provádění. Sestavení je považováno za selhání, pokud kompilace selže nebo selže alespoň jeden testovací případ. Ukázalo se, že přibližně jedna ze 4 sestavení selže a že nejčastější příčinou selhání sestavení je selhání testu [8].

Klíčovou myšlenkou programu Repairnator je automaticky generovat záplaty, které opravují selhání sestavení, a ukázat je lidským vývojářům, aby konečně zjistili, zda je tito vývojáři přijmou jako platné příspěvky do kódové základny. Pokud by k tomu došlo, bylo by to důkazem konkurenceschopnosti člověka při opravě programu.

Toto nastavení - automatické opravy selhání sestavení, k nimž dochází při nepřetržité integraci - je zvláště vhodné a aktuální z následujících důvodů. Za prvé, selhání sestavení uspokojí hlavní problémové prohlášení o opravě programu založeného na sadě testů [4], kde jsou chyby specifikovány jako neúspěšné testovací případy, a ty neúspěšné testovací případy se používají k řízení automatické syntézy záplaty [4]. Za druhé, umožňuje srovnávání robotů a lidí na spravedlivém základě: pokud je na serveru pro kontinuální integraci objeven neúspěšný test, jsou o něm lidský vývojář a robot informováni přesně ve stejnou dobu. Toto oznámení o selhání testu je výchozím bodem soutěže mezi lidmi a boty.

Zaměření opraváře na selhání sestavení je jedinečné, ale zapadá do celkového obrazu inteligentních robotů pro software [2]. Například Facebook má nástroj s názvem SapFix, který opravuje chyby nalezené při automatickém testování. Útočníci a obránci botů DARPA Cyber ​​Grand Challenge se také pokoušejí být vůči odborníkům na bezpečnost konkurenceschopní.

Opravář v kostce

V letech 2017–2018 jsme navrhli, implementovali a provozovali Repairnator, bota pro automatickou opravu programu. Opravář se specializuje na opravy chyb při sestavování, ke kterým dochází během nepřetržité integrace. Neustále sleduje tisíce odevzdaných příkazů, které jsou tlačeny na hostitelskou platformu kódu GitHub, a analyzuje jejich odpovídající sestavení. Každou minutu zahajuje nové pokusy o opravu, aby opravil chyby před lidským vývojářem. Je navržen tak, aby šel co nejrychleji, protože se účastní závodu: pokud Repairnator najde náplast před lidským vývojářem, je to lidská soutěž.

Podejme nyní přehled o tom, jak funguje robot opravář.

Primárním vstupem programu Repairnator jsou průběžné integrační sestavení, vyvolané závazky vývojářů (horní část obrázku, (a) a (b)) na základě projektů GitHub (a). Výstupy nástroje Repairnator jsou dvojí: (1) automaticky vytváří opravy pro opravu chybných sestav (g), pokud existují; (2) shromažďuje cenné údaje pro budoucí výzkum oprav programů (h) a (k). Opravář průběžně sleduje veškerou nepřetržitou činnost z projektů GitHub ©. Budování CI se uvádí jako vstup do třífázového potrubí: (1) první fáze shromažďuje a analyzuje protokoly vytváření CI (e); (2) druhá fáze je zaměřena na místní reprodukci selhání sestavení, ke kterým došlo na CI (f); (3) ve třetí fázi se provádějí různé prototypy oprav programů, které vycházejí z nejnovějšího akademického výzkumu. Když je nalezena oprava, provede člen projektu Repairnator rychlou kontrolu zdravého rozumu, aby nedošlo ke ztrátě drahocenného času vývojářů s otevřeným zdrojovým kódem. (i) Pokud shledá, že záplata není degenerovaná, navrhne ji původním vývojářům projektu jako žádost o vyžádání na GitHub (j). Vývojáři pak sledují obvyklý proces kontroly kódu a slučování.

Opravář musí pracovat v daném softwarovém ekosystému. Vzhledem k našim odborným znalostem s Javou v minulých výzkumných projektech se prototypová implementace Repairnator zaměřuje na opravu softwaru napsaného v programovacím jazyce Java, vytvořeného pomocí toolchainu Maven, v open-source projektech hostovaných na GitHub, které využívají kontinuální integrační platformu Travis CI .

Expediční úspěchy

Opravář provozujeme od ledna 2017 ve třech různých fázích. Během měsíce, v lednu 2017, jsme provedli pilotní experiment s počáteční verzí prototypu. Od 1. února 2017 do 31. prosince 2017 jsme provozovali Opravář s pevným seznamem 14 188 projektů, nazýváme to „Expedice # 1“. Od 1. ledna 2018 do 30. června 2018 opravuje opravovatel monitorovací proud Travis CI v reálném čase, nazýváme jej „Expedice # 2“

Hlavním cílem pilotního experimentu bylo ověření našeho návrhu a počáteční implementace. Zjistili jsme, že náš prototyp je schopen provádět přibližně 30 pokusů o opravu denně, vzhledem k našim výpočetním prostředkům. Ještě důležitější je, že tento pilotní experiment potvrdil naše klíčové technologické předpoklady: značná část populárních open-source projektů používá Travis a většina z nich používá Maven jako technologii výstavby. To znamenalo, že bychom měli v tomto kontextu spravedlivou šanci dosáhnout našeho cíle syntetizovat náplast konkurenční vůči člověku.

Během Expedice # 1, jejíž výsledky jsou podrobně uvedeny v [7], opravil analyzátor 11 523 sestavení se selháním testu. U 3,551 z nich (30,82%) byl opravář schopen lokálně reprodukovat selhání testu. Z 3 551 pokusů o opravu našel Repairnator 15 oprav, které by mohly vést k tomu, aby se stavba CI dostala. Naše analýza záplat však odhalila, že žádná z těchto náplastí nebyla konkurenceschopná pro člověka, protože přišly příliš pozdě (Repairnator vytvořil náplast po lidském vývojáři) nebo byly nízké kvality (učinily sestavení úspěšným náhodně).

Expedice # 2 je úspěšná. Ukázalo se, že technologie oprav programů překročila hranici lidské konkurenceschopnosti. Opravář vytvořil 5 záplat, které splňují výše uvedená kritéria konkurenceschopnosti člověka: 1) záplaty byly vyrobeny před lidskými, 2) vývojář přijal záplaty jako platné příspěvky a záplaty byly sloučeny do hlavní kódové základny.

Lidské konkurenční příspěvky na Githubu, opravy syntetizované robotem opraváře a přijaté lidským vývojářem:

  • 12. ledna 2018, aaime / geowebcache / pull / 1, „Díky za opravu!“
  • 23. března 2018, parkito / BasicDataCodeU […] / pull / 3 „sloučený odevzdaný 140a3e3 do parkito: rozvíjet se“
  • 5. dubna 2018, dkarv / jdcallgraph / pull / 2 „Díky!“
  • 3. května 2018, eclipse / ditto / pull / 151 „Cool, děkujeme, že jste prošli procesem Eclipse a za opravu.“
  • 25. června 2018, donnelldebnam / CodeU […] / pull / 151 „Díky !!“

První náplast sloučená s naším programem pro opravu bot byla přijata lidským vývojářem dne 12. ledna 2018. Zde je příběh: 12. ledna 2018 ve 12:28 hodin byla spuštěna stavba projektu aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Sestavení selhalo po 2 minutách provedení, protože dva testovací případy byly omylem. O čtyřicet minut později, 12. ledna 2018 v 13:08, opravář zjistil selhání sestavení během jeho pravidelného sledování a začal spouštět dostupné systémy oprav programů nakonfigurované v opraváři. O deset minut později, v 13:18, našel náplast.

12. ledna 2018, v 13:35, vzal člen týmu Repairnator opravu generovanou společností Repairnator a potvrdil otevření odpovídajícího vyžádaného požadavku na GitHub. 12. ledna 2018, ve 14:10, vývojář přijal náplast a spojil ji s poznámkou: „Divné, myslel jsem, že jsem to už opravil ... možná jsem to udělal na jiném místě. Díky za opravu! “. To byl první patch vytvořený firmou Repairnator a přijatý jako platný příspěvek lidského vývojáře, definitivně sloučený do kódové základny. Jinými slovy, opravář byl poprvé lidsky konkurenceschopný.

Po dalších 6 měsících provozu měl Repairnator 5 patchů sloučených lidskými vývojáři, které jsou uvedeny výše.

Celkově projekt Opravář splnil své poslání. Ukázalo se, že oprava programu může být považována za konkurenceschopnou na člověka: Opravář našel záplaty 1) před lidmi, 2) které byly považovány samotnými lidmi za kvalitní.

Budoucnost

Kromě toho, že oprava programu je lidská konkurenceschopnost, projekt Opravář poskytl velké množství informací o chybách a nepřetržité integraci ao současných nedostatcích výzkumu oprav programu uvedených v [7].

Budeme se zabývat zejména otázkou duševního vlastnictví. Dne 3. května 2018 společnost Repairnator vytvořila dobrý patch pro projekt GitHub eclipse / ditto. Krátce poté, co navrhl opravu, se jeden z vývojářů zeptal: „Můžeme přijímat pouze žádosti vyžádané od uživatelů, kteří podepsali licenční smlouvu na přispěvatele Nadace Eclipse Foundation.“. Byli jsme zmatení, protože robot nemůže fyzicky nebo morálně podepsat licenční smlouvu a pravděpodobně k tomu není oprávněn. Kdo vlastní duševní vlastnictví a odpovědnost za příspěvek na robot: robotický robot, implementátor botu nebo návrhář algoritmu pro opravu? To je jedna ze zajímavých otázek odhalených v projektu Opravář.

Věříme, že Repairnator předurčuje určitou budoucnost vývoje softwaru, kde roboti a lidé budou hladce spolupracovat a dokonce spolupracovat na softwarových artefaktech.

Chcete se připojit k komunitě opravovatelů? Chcete-li dostávat pravidelné zprávy o opraváři, natočte e-mail na adresu repairnator.subscribe@4open.science!

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

V médiích:

  • Tajemný život Luc Esapea, mimozemšťan opravující chyby. Jeho velké tajemství? Není člověk (Thomas Claburn, The Register)

Reference

  • [1] J. R. Koza (2010) Výsledky konkurenceschopnosti člověka produkované genetickým programováním. Genetické programování a vývojové stroje 11 (3–4), s. 251–284. Citováno v:.
  • [2] C. Lebeuf, M. D. Storey a A. Zagalsky (2018) Softwarové roboty. Software IEEE 35, s. 18–23. Citováno: Automatické opravy a kontinuální integrace.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan a M. Monperrus (2016) Automatická oprava skutečných chyb v Javě: experiment ve velkém měřítku na datovém souboru Defects4j. Empirické softwarové inženýrství, s. 1–29. Citace: Lidská konkurenceschopnost,.
  • [4] Automatické opravy softwaru M. Monperrus (2017): Bibliografie. Výpočty ACM. Citováno: Automatické opravy a kontinuální integrace,.
  • [5] A. Murgia, D. Janssens, S. Demeyer a B. Vasilescu (2016) Mezi stroji: Interakce člověk-bot na sociálních q & a webech. Ve sborníku konference CHI 2016 rozšířené abstrakty o lidských faktorech ve výpočetních systémech, s. 1272–1279. Citace: Lidská konkurenceschopnost.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues a Y. Brun (2015) Je léčba horší než nemoc? overfitting v automatizované opravě programu. Ve sborníku 10. společné schůze 2015 o základech softwarového inženýrství, s. 532–543. Externí odkazy: Dokument Citováno: Lidská konkurenceschopnost.
  • [7] S. Urli, Z. Yu, L. Seinturier a M. Monperrus (2018) Jak navrhnout program na opravu bot? Statistiky z projektu Opravář. Na mezinárodní konferenci ICSE 2018–40. O softwarovém inženýrství, sledování softwarového inženýrství v praxi, externí odkazy: Odkaz Citováno: Expedice Achievementy, Budoucnost.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta a S. Panichella (2017) Příběh selhání CI: Otevřený zdroj a perspektiva finanční organizace. Na mezinárodní konferenci o údržbě a vývoji softwaru, citováno: Automatické opravy a kontinuální integrace.