Opravy, ktoré si konkurujú človeku pri automatickej oprave programu pomocou opravára

Opravár je robot. Neustále monitoruje softvérové ​​chyby objavené počas nepretržitej integrácie softvéru s otvoreným zdrojom a snaží sa ich automaticky opraviť. Ak sa podarí syntetizovať platnú náplasť, spoločnosť Repairnator navrhne náplasť ľudským vývojárom, maskovanú pod falošnou ľudskou identitou. K dnešnému dňu bol opravár schopný vyrobiť 5 záplat, ktoré boli akceptované ľudskými vývojármi a trvalo zlúčené do kódovej základne. Je to míľnik konkurencieschopnosti človeka vo výskume softvérového inžinierstva v oblasti automatickej opravy programov. V tomto príspevku hovoríme o tomto výskume uskutočnenom na Kráľovskom technologickom inštitúte KTH v Inrii, na univerzite v Lille a na univerzite vo Valenciennes.

Výskum opráv programu sa zameriava na myšlienku, že algoritmy môžu nahradiť ľudí opraviť softvérové ​​chyby [4]. Oprava chyby je oprava, ktorá vkladá, odstraňuje alebo upravuje zdrojový kód. Napríklad v nasledujúcej oprave vývojár upravil stav príkazu if:

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

Programová oprava topánok je umelý agent, ktorý sa snaží syntetizovať záplaty zdrojového kódu. Analyzuje chyby a vytvára záplaty, rovnako ako vývojári pôsobiaci v oblasti údržby softvéru. Táto myšlienka topánok na opravu programov je rušivá, pretože dnes sú ľudia zodpovední za opravu chýb. Inými slovami, hovoríme o robotovi, ktorý má (čiastočne) nahradiť ľudských vývojárov únavnými úlohami.

Keď sa robot pokúša splniť úlohu, ktorú zvyčajne robia ľudia, je známa ako úloha konkurujúca človeku [1]. Empirické hodnotenia výskumu v oblasti opravy programov [3] ukazujú, že súčasné systémy opráv programov sú schopné syntetizovať záplaty na skutočné chyby v reálnych programoch. Všetky tieto záplaty však boli syntetizované pre minulé chyby, pre chyby, ktoré boli opravené ľudskými vývojármi v minulosti, zvyčajne pred rokmi. Aj keď to naznačuje technickú uskutočniteľnosť opravy programu, nepreukazuje to, že oprava programu je konkurencieschopná pre človeka.

Human-konkurencieschopnosť

Aby demonštroval, že oprava programu je konkurencieschopná pre človeka, musí robot na opravu programu nájsť kvalitnú náplasť skôr, ako to urobí človek. V tejto súvislosti možno náplasť považovať za konkurenčnú pre človeka, ak spĺňa dve podmienky včasnosti a kvality. Včasnosť sa týka skutočnosti, že systém musí nájsť náplasť pred ľudským vývojárom. Inými slovami, prototypový systém musí vytvárať záplaty rádovo minúty, nie dni. Náplasť vytvorená robotom musí byť dostatočne správna, podobnej kvality - správna a čitateľná - v porovnaní s náplasťou napísanou človekom. Všimnite si, že existujú náplasti, ktoré vyzerajú správne z hľadiska topánok, napriek tomu sú nesprávne (v literatúre sa to hovorí ako nadmerné výplachy [6, 3]). Tieto záplaty pravdepodobne nie sú konkurencieschopné pre človeka, pretože ich ľudia nikdy neprijímajú vo svojej kódovej základni.

V dôsledku toho, aby náplasť bola ľudská konkurencieschopná 1) topánok musí syntetizovať náplasť rýchlejšie ako ľudský vývojár 2), musí ju náplasť ľudský vývojár dostatočne dobre posúdiť a natrvalo sa zlúčiť do kódovej základne.

Je potrebné zvážiť ešte jeden aspekt. Ukázalo sa, že ľudskí inžinieri neakceptujú príspevky robotov tak ľahko ako príspevky iných ľudí, aj keď sú úplne totožné [5]. Dôvod je ten, že ľudia majú tendenciu mať apriorné predsudky proti strojom a sú tolerantnejší voči chybám, ak príspevok pochádza od ľudského rovesníka. V súvislosti s opravou programu to znamená, že vývojári môžu dať latku vyššiu kvalitu opravy, ak vedia, že oprava pochádza z robotov. To by bránilo nášmu hľadaniu dôkazu konkurencieschopnosti človeka v súvislosti s opravami programov.

Aby sme tento problém prekonali, na začiatku projektu sme sa rozhodli, že všetky opravy opravára budú navrhnuté pod falošnou ľudskou identitou. Vytvorili sme používateľa GitHubu, ktorý sa volá Luc Esape, ktorý je prezentovaný ako softvérový inžinier v našom výskumnom laboratóriu. Luc má profilový obrázok a vyzerá ako juniorský vývojár, ktorý túži prispievať na GitHub s otvoreným zdrojom. Teraz si predstavte opravára, prekrývaného tým, že Luc Esape navrhuje záplatu: vývojárka, ktorá ju kontroluje, si myslí, že hodnotí ľudský príspevok. Táto kamufláž sa vyžaduje na testovanie našej vedeckej hypotézy ľudskej konkurencieschopnosti. Teraz, kvôli etike, bola ozajstná identita Luc odhalená pri každej jeho žiadosti.

Automatická oprava a nepretržitá integrácia

Nepretržitá integrácia, nazývaná CI, je myšlienka, že server kompiluje kód a vykoná všetky testy pre každý záväzok vykonaný v systéme riadenia verzií softvérového projektu (napr. Git). V kóde CI je zostavenie každého záväzku. Zostavenie obsahuje informácie o použitom snímke zdrojového kódu (napr. Odkaz na Git commit), výsledok kompilácie a vykonania testu (napr. Zlyhanie alebo úspech) a protokol sledovania vykonávania. Zostavenie sa považuje za zlyhávajúce, ak zlyhá kompilácia alebo zlyhá aspoň jeden testovací prípad. Ukázalo sa, že približne jedna zo 4 zostáv zlyhá a že najbežnejšou príčinou zlyhania zostavy je zlyhanie testu [8].

Kľúčovou myšlienkou služby Repairnator je automaticky generovať záplaty, ktoré opravujú chyby pri zostavovaní, a potom ich ukázať ľudským vývojárom a konečne zistiť, či ich títo vývojári akceptujú ako platné príspevky do kódovej základne. Ak by sa to stalo, bolo by to dôkazom ľudskej konkurencieschopnosti pri oprave programu.

Toto nastavenie - automatické opravy porúch stavania, ku ktorým dochádza pri nepretržitej integrácii - je obzvlášť vhodné a aktuálne z nasledujúcich dôvodov. Po prvé, zlyhania zostavenia uspokoja základné vyhlásenie o probléme opravy programov založených na testovacích sadách [4], kde sú chyby špecifikované ako neúspešné testovacie prípady a tie zlyhávajúce testovacie prípady sa používajú na podporu automatizovanej syntézy záplaty [4]. Po druhé, umožňuje spravodlivé porovnávanie robotov a ľudí: keď sa na serveri na nepretržitú integráciu objaví neúspešný test, ľudský vývojár a robot sú o tom informovaní v rovnakom čase. Toto oznámenie o zlyhaní testu je východiskovým bodom súťaže medzi ľuďmi a robotmi.

Zameranie opravára na zlyhania pri zostavovaní je jedinečné, ale zapadá do celkového obrazu inteligentných robotov pre softvér [2]. Napríklad Facebook má nástroj s názvom SapFix, ktorý opravuje chyby nájdené pri automatizovanom testovaní. Útočníci a obhajcovia robotov DARPA Cyber ​​Grand Challenge sa tiež snažia byť konkurencieschopní, pokiaľ ide o odborníkov na bezpečnosť.

Opravár v kocke

V rokoch 2017 - 2018 sme navrhli, implementovali a prevádzkovali Repairnator, robot na automatickú opravu programu. Opravár je špecializovaný na opravu stavieb, ku ktorým dochádza počas nepretržitej integrácie. Neustále monitoruje tisíce potvrdení, ktoré sú tlačené na hostiteľskú platformu kódu GitHub, a analyzuje ich príslušné zostavenia. Každú minútu spúšťa nové pokusy o opravu s cieľom opraviť chyby pred ľudským vývojárom. Je navrhnutý tak, aby jazdil čo najrýchlejšie, pretože sa zúčastňuje pretekov: ak opravár nájde záplatu pred ľudským vývojárom, je to ľudská súťaž.

Teraz vám poskytneme prehľad o tom, ako funguje robot opravára.

Primárnym vstupom programu Repairnator sú neustále sa budujúce integračné procesy vyvolané záväzkami vývojárov (horná časť obrázku, (a) a (b)) na základe projektov GitHub (a). Výstupy nástroja Repairnator sú dvojaké: (1) automaticky vytvára záplaty na opravu chýbajúcich stavieb (g), ak existujú; (2) zbiera cenné údaje pre budúci výskumný program opráv (h) a (k). Opravárator neustále monitoruje všetku nepretržitú činnosť z projektov GitHub ©. Zostavenia CI sa uvádzajú ako vstup do trojstupňového plynovodu: (1) prvá fáza zhromažďuje a analyzuje protokoly vytvárania CI (e); (2) druhá etapa je zameraná na lokálnu reprodukciu porúch stavania, ku ktorým došlo na CI (f); (3) v tretej etape sa vykonávajú rôzne prototypy opráv programov, ktoré vychádzajú z najnovšieho akademického výskumu. Ak sa nájde oprava, člen projektu Repairnator vykoná rýchlu kontrolu rozumnosti, aby sa predišlo strate drahocenného času vývojárov s otvoreným zdrojom. (i) Ak zistí, že náplasť nie je degenerovaná, potom ju navrhne pôvodným vývojárom projektu ako žiadosť o ťah na GitHub (j). Vývojári potom sledujú zvyčajný proces kontroly kódu a zlúčenia.

Opravár musí pracovať v danom softvérovom ekosystéme. Vzhľadom na naše skúsenosti s Java v minulých výskumných projektoch sa prototypová implementácia programu Repairnator zameriava na opravu softvéru napísaného v programovacom jazyku Java, ktorý bol zostavený pomocou nástroja Maven, v open-source projektoch hostovaných na serveri GitHub, ktoré využívajú platformu kontinuálnej integrácie Travis CI. ,

Expedičné úspechy

Opravovňu prevádzkujeme od januára 2017 v troch rôznych fázach. Počas jedného mesiaca, v januári 2017, sme vykonali pilotný experiment s pôvodnou verziou prototypu. Od 1. februára 2017 do 31. decembra 2017 sme prevádzkovali opravovňu s pevným zoznamom 14 188 projektov, nazývame to „Expedícia č. 1“. Od 1. januára 2018 do 30. júna 2018, opravovňa monitoruje budovací prúd Travis CI v reálnom čase, nazývame ho „Expedícia # 2“

Hlavným cieľom pilotného experimentu bolo overiť náš návrh a počiatočnú implementáciu. Zistili sme, že náš prototyp je schopný vykonať približne 30 pokusov o opravu denne, vzhľadom na naše počítačové zdroje. Čo je dôležitejšie, tento pilotný experiment potvrdil naše hlavné technologické predpoklady: veľká časť populárnych open-source projektov využíva Travis a väčšina z nich používa Maven ako technológiu budovania. To znamenalo, že by sme mali v tomto kontexte spravodlivú šancu dosiahnuť náš cieľ syntetizovať náplast konkurenčnú pre človeka.

Počas expedície č. 1, ktorej výsledky sú podrobne uvedené v [7], opravil analyzátor 11 523 stavieb so zlyhaním testu. Z toho 3 551 (30,82%) bol opravár schopný lokálne reprodukovať zlyhanie testu. Z 3 551 pokusov o opravu, opravár našiel 15 záplat, ktoré by mohli viesť k tomu, aby stavba CI prešla. Naša analýza záplat však odhalila, že žiadna z týchto náplastí nebola konkurencieschopná pre človeka, pretože prišli príliš neskoro (opravár vytvoril náplasť po ľudskom vývojárovi) alebo boli nízkej kvality (stavba sa stala náhodou úspešnou).

Expedícia # 2 je úspešná. Ukázalo sa, že technológia opráv programov prekročila hranicu ľudskej konkurencieschopnosti. Opravár vytvoril 5 náplastí, ktoré spĺňajú vyššie uvedené kritériá konkurencieschopnosti pre človeka: 1) náplasti boli vyrobené pred ľudskými, 2) ľudský vývojár prijal náplasti ako platné príspevky a náplasti boli zlúčené do základnej kódovej základne.

Ľudské konkurenčné príspevky na Github, náplasti syntetizované robotom opravára a akceptované ľudským vývojárom:

  • 12. januára 2018, aaime / geowebcache / pull / 1, „Ďakujeme za opravu!“
  • 23. marca 2018, parkito / BasicDataCodeU […] / pull / 3 „zlúčený záväzok 140a3e3 do parketu: rozvíjať sa“
  • 5. apríla 2018, dkarv / jdcallgraph / pull / 2 „Vďaka!“
  • 3. mája 2018, eclipse / ditto / pull / 151 „Cool, ďakujeme za absolvovanie procesu Eclipse a za opravu.“
  • 25. júna 2018, donnelldebnam / CodeU […] / pull / 151 „Vďaka !!“

Prvý patch, ktorý našiel náš program na opravu programov, bol prijatý ľudským vývojárom 12. januára 2018. Tu je príbeh: 12. januára 2018 o 12:28 hod. Sa spustilo zostavenie projektu aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Zostavenie zlyhalo po 2 minútach vykonávania, pretože dva testovacie prípady boli omylom. O štyridsať minút neskôr, 12. januára 2018 o 13:08 hod., Opravár zistil zlyhanie zostavenia počas jeho pravidelného monitorovania a začal spúšťať dostupné systémy opráv programov nakonfigurované v opravníku. O desať minút neskôr, o 13:18, našla náplasť.

12. januára 2018, o 13:35, si člen tímu opravár vzal opravu vygenerovanú opravcom a potvrdil otvorenie príslušnej žiadosti o stiahnutie na serveri GitHub. 12. januára 2018 o 14:10 vývojár prijal náplasť a spojil ju s komentárom: „Divné, myslel som, že som to už opravil ... možno som to urobil na inom mieste. Vďaka za opravu! “. Bola to prvá záplata, ktorú vytvoril Repairnator a ktorá bola prijatá ako platný príspevok ľudského vývojára, definitívne zlúčeného do kódovej základne. Inými slovami, opravár bol prvýkrát v súťaži s človekom.

Po ďalších 6 mesiacoch prevádzky mal opravár 5 záplat zlúčených ľudskými vývojármi, ktoré sú uvedené vyššie.

Celkovo projekt Repairnator splnil svoje poslanie. Ukázalo sa, že oprava programu sa môže považovať za súťaživú pre človeka: Opravovňa našla náplasti 1) pred ľuďmi, 2) ktoré samotní ľudia považovali za kvalitné.

Budúcnosť

Okrem toho, že program Repairnator dokazuje, že oprava programu je konkurencieschopná pre človeka, poskytol množstvo informácií o chybách a nepretržitej integrácii ao súčasných nedostatkoch vo výskume opráv programov, ktorý je uvedený v [7].

Budeme sa zaoberať najmä otázkou duševného vlastníctva. 3. mája 2018 spoločnosť Repairnator vyrobila dobrú náplasť pre zatmenie / ditto projektu GitHub. Krátko po navrhnutí opravy sa jeden z vývojárov opýtal: „Môžeme akceptovať iba žiadosti o stiahnutie, ktoré pochádzajú od používateľov, ktorí podpísali licenčnú zmluvu prispievateľov nadácie Eclipse Foundation.“. Boli sme zmätení, pretože robot nemôže fyzicky ani morálne podpísať licenčnú zmluvu a pravdepodobne nie je oprávnený tak urobiť. Kto vlastní duševné vlastníctvo a zodpovednosť za príspevok na robot: robotický robot, implementátor robotov alebo návrhár algoritmov opráv? Toto je jedna zo zaujímavých otázok odhalených v projekte Opravár.

Veríme, že Repairnator predurčuje určitú budúcnosť vývoja softvéru, kde roboti a ľudia budú hladko spolupracovať a dokonca budú spolupracovať na softvérových artefaktoch.

Chcete sa pripojiť k komunite opravárov? Ak chcete dostávať pravidelné správy o službe Repairnator, pošlite e-mail na adresu repairnator.subscribe@4open.science!

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

V médiách:

  • Tajomný život Luc Esapea, opravca chýb. Jeho veľké tajomstvo? Nie je človek (Thomas Claburn, Register)

Referencie

  • [1] J. R. Koza (2010) Výsledky porovnateľné s človekom, ktoré boli výsledkom genetického programovania. Genetické programovanie a vývojové stroje 11 (3–4), s. 251–284. Citoval:.
  • [2] Softvérové ​​roboty C. Lebeuf, M. D. Storey a A. Zagalsky (2018). Softvér IEEE 35, s. 18–23. Citované: Automatické opravy a kontinuálna integrácia.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan a M. Monperrus (2016) Automatická oprava skutočných chýb v Jave: rozsiahly experiment na súbore údajov Defects4j. Empirical Software Engineering, s. 1–29. Citácia: Ľudská konkurencieschopnosť,.
  • [4] M. Monperrus (2017) Automatické opravy softvéru: bibliografia. Výpočty ACM. Citované v: Automatické opravy a kontinuálna integrácia,.
  • [5] A. Murgia, D. Janssens, S. Demeyer a B. Vasilescu (2016). Medzi strojmi: Interakcia človek-topánok na sociálnych sieťach a webových stránkach. V zborníku konferencie CHI 2016, rozšírené abstrakty o ľudských faktoroch vo výpočtových systémoch, s. 1272 - 1279. Citácia: Ľudská konkurencieschopnosť.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues a Y. Brun (2015) Je liečba horšia ako choroba? nadmerné vybavenie v automatizovanej oprave programu. V zborníku z 10. spoločného zasadnutia o nadáciách softvérového inžinierstva v roku 2015, s. 532–543. Externé odkazy: Dokument Citoval: Ľudská konkurencieschopnosť.
  • [7] S. Urli, Z. Yu, L. Seinturier a M. Monperrus (2018) Ako navrhnúť program na opravu opráv? Štatistiky z projektu Opravár. Na Medzinárodnej konferencii o softvérovom inžinierstve ICSE 2018 - 40. Sledovanie softvérového inžinierstva v praxi, Externé odkazy: Odkaz Citoval: Expedition Achievements, The Future.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta a S. Panichella (2017) Príbeh zlyhaní stavieb KI: otvorený zdroj a perspektíva finančnej organizácie. Na medzinárodnej konferencii o údržbe a vývoji softvéru, citovanej: Automatické opravy a kontinuálna integrácia.