Łatki konkurencyjne dla ludzi w automatycznej naprawie programu za pomocą Repairnatora

Repairnator to bot. Stale monitoruje błędy oprogramowania wykryte podczas ciągłej integracji oprogramowania typu open source i próbuje je naprawić automatycznie. Jeśli uda się zsyntetyzować prawidłową łatkę, Repairnator proponuje łatkę ludzkim twórcom, ukrytym pod fałszywą tożsamością ludzką. Do tej pory Repairnator był w stanie wyprodukować 5 łatek, które zostały zaakceptowane przez ludzkich programistów i trwale scalone z bazą kodu. Jest to kamień milowy dla konkurencyjności człowieka w badaniach inżynierii oprogramowania w zakresie automatycznej naprawy programów. W tym poście opowiadamy o badaniach przeprowadzonych w KTH Royal Institute of Technology, Inria, University of Lille i University of Valenciennes.

Badania napraw programów podążają za ideą, że algorytmy mogą zastąpić ludzi w celu naprawy błędów oprogramowania [4]. Poprawka błędu to łatka, która wstawia, usuwa lub modyfikuje kod źródłowy. Na przykład w poniższej łatce programista zmodyfikował stan instrukcji if:

- jeśli (x <10)
+ if (x <= 10)
bla();

Bot do naprawy programów to sztuczny agent, który próbuje zsyntetyzować łaty kodu źródłowego. Analizuje błędy i tworzy łatki, w taki sam sposób, jak twórcy oprogramowania zaangażowani w czynności związane z konserwacją oprogramowania. Pomysł bota naprawiającego program jest destrukcyjny, ponieważ dzisiaj ludzie są odpowiedzialni za naprawianie błędów. Innymi słowy, mówimy o bocie, który ma (częściowo) zastąpić ludzkich programistów trudnymi zadaniami.

Kiedy bot próbuje wykonać zadanie zwykle wykonywane przez ludzi, jest to znane jako zadanie konkurencyjne dla człowieka [1]. Oceny empiryczne badań napraw programów [3] pokazują, że obecne systemy napraw programów są w stanie syntezować łatki dla prawdziwych błędów w prawdziwych programach. Jednak wszystkie te łaty zostały zsyntetyzowane pod kątem błędów z przeszłości, błędów, które zostały naprawione przez ludzkich programistów w przeszłości, zwykle lata temu. Chociaż wskazuje to na techniczną wykonalność naprawy programu, nie pokazuje to, że naprawa programu jest konkurencyjna dla ludzi.

Konkurencyjność człowieka

Aby wykazać, że naprawa programu jest konkurencyjna dla człowieka, bot naprawiający program musi znaleźć łatkę wysokiej jakości, zanim zrobi to człowiek. W tym kontekście łatkę można uznać za konkurencyjną dla ludzi, jeżeli spełnia ona dwa warunki terminowości i jakości. Terminowość odnosi się do faktu, że system musi znaleźć łatkę przed ludzkim deweloperem. Innymi słowy, prototypowy system musi wytwarzać łatki rzędu wielkości minut, a nie dni. Ponadto łatka wygenerowana przez bota musi być wystarczająco poprawna, podobnej jakości - poprawna i czytelna - w porównaniu z łatką napisaną przez człowieka. Zauważ, że istnieją łaty, które wyglądają poprawnie z punktu widzenia bota, ale są niepoprawne (jest to znane w literaturze jako nadmierne poprawki [6, 3]). Te łatki prawdopodobnie nie są konkurencyjne dla ludzi, ponieważ ludzie nigdy nie zaakceptowaliby ich w swojej bazie kodu.

W konsekwencji, aby łatka była konkurencyjna dla człowieka 1) bot musi zsyntetyzować łatkę szybciej niż ludzki programista 2) łata musi zostać oceniona przez człowieka jako wystarczająco dobra i trwale połączona z bazą kodu.

Jest jeszcze jeden aspekt do rozważenia. Wykazano, że inżynierowie nie przyjmują wkładów botów tak łatwo, jak wkładów innych ludzi, nawet jeśli są one ściśle identyczne [5]. Powodem jest to, że ludzie zwykle mają uprzedzenia wobec maszyn i są bardziej tolerancyjni na błędy, jeśli wkład pochodzi od człowieka. W kontekście naprawy programu oznacza to, że programiści mogą podnieść poprzeczkę na jakość łatki, jeśli wiedzą, że łatka pochodzi od bota. Utrudniłoby to nasze poszukiwania dowodu na konkurencyjność człowieka w kontekście naprawy programu.

Aby rozwiązać ten problem, na początku projektu zdecydowaliśmy, że wszystkie łatki Repairnator będą proponowane pod fałszywą ludzką tożsamością. Stworzyliśmy użytkownika GitHub o nazwie Luc Esape, który jest prezentowany jako inżynier oprogramowania w naszym laboratorium badawczym. Luc ma zdjęcie profilowe i wygląda jak młodszy programista, chętny do wkładu w GitHub. Teraz wyobraź sobie Repairnator, przebrany za Luca Esape'a proponującego łatkę: recenzent, który go recenzuje, uważa, że ​​recenzuje wkład człowieka. Ten kamuflaż jest wymagany do przetestowania naszej naukowej hipotezy o konkurencyjności człowieka. Teraz, ze względu na etykę, prawdziwa tożsamość Luca została ujawniona w każdym z jego wniosków.

Automatyczna naprawa i ciągła integracja

Ciągła integracja, znana również jako CI, polega na tym, że serwer kompiluje kod i uruchamia wszystkie testy dla każdego zatwierdzenia dokonanego w systemie kontroli wersji projektu oprogramowania (np. Git). W języku CI istnieje kompilacja dla każdego zatwierdzenia. Kompilacja zawiera informacje o użytej migawce kodu źródłowego (np. Odniesienie do zatwierdzenia Git), wynik kompilacji i wykonania testu (np. Niepowodzenie lub sukces) oraz dziennik śledzenia wykonania. Mówi się, że kompilacja kończy się niepowodzeniem, jeśli kompilacja się nie powiedzie lub przynajmniej jeden przypadek testowy się nie powiedzie. Wykazano, że około jedna na 4 kompilacje kończy się niepowodzeniem, a najczęstszą przyczyną niepowodzenia kompilacji jest błąd testowy [8].

Kluczową ideą Repairnatora jest automatyczne generowanie łat naprawiających awarie kompilacji, a następnie pokazywanie ich ludzkim programistom, aby w końcu zobaczyć, czy ci ludzcy programiści zaakceptują je jako ważny wkład do bazy kodu. Jeśli tak się stanie, będzie to dowód na konkurencyjność człowieka w naprawie programu.

Ta konfiguracja - automatyczna naprawa błędów kompilacji występujących podczas ciągłej integracji - jest szczególnie odpowiednia i terminowa z następujących powodów. Po pierwsze, niepowodzenia kompilacji spełniają zasadnicze stwierdzenie problemu naprawy programu opartego na zestawie testów [4], gdzie błędy są określane jako niepowodzenia testów, a te niepowodzenia testów są wykorzystywane do sterowania automatyczną syntezą łatki [4]. Po drugie, pozwala na porównanie botów i ludzi na uczciwych zasadach: gdy na serwerze ciągłej integracji wykryty zostanie test zakończony niepowodzeniem, programista i bot zostaną o tym poinformowani dokładnie w tym samym czasie. To powiadomienie o niepowodzeniu testu jest punktem startowym rywalizacji człowiek-bot.

Repairnator koncentruje się na niepowodzeniach kompilacji jest wyjątkowy, ale mieści się w dużym obrazie inteligentnych botów do oprogramowania [2]. Na przykład Facebook ma narzędzie o nazwie SapFix, które naprawia błędy znalezione podczas automatycznego testowania. Powiązani również, atakujący i obrońcy botów DARPA Cyber ​​Grand Challenge starają się być konkurencyjni wobec ekspertów w dziedzinie bezpieczeństwa.

Repairnator w pigułce

W latach 2017–2018 zaprojektowaliśmy, wdrożyliśmy i działaliśmy Repairnator, bot do automatycznej naprawy programów. Repairnator specjalizuje się w naprawie błędów kompilacji występujących podczas ciągłej integracji. Stale monitoruje tysiące zatwierdzeń wypychanych na platformę hostingową kodu GitHub i analizuje odpowiadające im kompilacje. Co minutę uruchamia nowe próby naprawy, aby naprawić błędy przed ludzkim deweloperem. Został zaprojektowany tak, aby iść tak szybko, jak to możliwe, ponieważ bierze udział w wyścigu: jeśli Repairnator znajdzie łatkę przed ludzkim deweloperem, jest konkurencyjny dla ludzi.

Dajmy teraz przegląd działania bota Repairnator.

Podstawowym wkładem Repairnatora są ciągłe kompilacje integracyjne, uruchamiane przez zatwierdzenia dokonywane przez programistów (górna część rysunku, (a) i (b)) w oparciu o projekty GitHub (a). Wyniki działania Repairnatora są dwojakie: (1) automatycznie tworzy łatki do naprawy nieudanych kompilacji (g), jeśli takie istnieją; (2) zbiera cenne dane do przyszłych badań naprawczych programu (h) i (k). Na stałe Repairnator monitoruje wszystkie ciągłe działania z projektów GitHub ©. Kompilacje CI są podawane jako dane wejściowe do potoku trzyetapowego: (1) pierwszy etap zbiera i analizuje logi kompilacji CI (e); (2) drugi etap ma na celu lokalne odtworzenie błędów kompilacji, które miały miejsce na CI (f); (3) na trzecim etapie działają różne prototypy naprawy programu pochodzące z najnowszych badań akademickich. Po znalezieniu łatki członek projektu Repairnator przeprowadza szybką kontrolę poczytalności, aby uniknąć marnowania cennego czasu deweloperów open source. (i) Jeśli stwierdzi, że łatka nie jest zdegenerowana, wówczas proponuje ją oryginalnym twórcom projektu jako żądanie ściągnięcia na GitHub (j). Następnie programiści postępują zgodnie ze zwykłym procesem przeglądania kodu i scalania.

Repairnator musi działać w danym ekosystemie oprogramowania. Ze względu na naszą wiedzę z zakresu Java w poprzednich projektach badawczych prototypowa implementacja Repairnator koncentruje się na naprawie oprogramowania napisanego w języku programowania Java, zbudowanego za pomocą zestawu narzędzi Maven, w projektach open source hostowanych na GitHub, które wykorzystują platformę ciągłej integracji Travis CI .

Osiągnięcia ekspedycji

Repairnator działamy od stycznia 2017 r., W trzech różnych fazach. W ciągu miesiąca, w styczniu 2017 r., Przeprowadziliśmy eksperyment pilotażowy ze wstępną wersją prototypu. Od 1 lutego 2017 r. Do 31 grudnia 2017 r. Prowadziliśmy Repairnator ze stałą listą 14 188 projektów, nazywamy to „Ekspedycją nr 1”. Od 1 stycznia 2018 r. Do 30 czerwca 2018 r. Repairnator monitorował strumień kompilacji Travis CI w czasie rzeczywistym, nazywamy go „Ekspedycją nr 2”

Głównym celem eksperymentu pilotażowego była weryfikacja naszego projektu i wstępnej implementacji. Odkryliśmy, że nasz prototyp jest w stanie wykonać około 30 prób naprawy dziennie, biorąc pod uwagę nasze zasoby komputerowe. Co ważniejsze, ten pilotażowy eksperyment potwierdził nasze podstawowe założenia technologiczne: znaczna część popularnych projektów open source wykorzystuje Travis, a większość z nich wykorzystuje Maven jako technologię kompilacji. Oznaczało to, że mielibyśmy uczciwą szansę na osiągnięcie naszego celu, jakim jest synteza łatki konkurencyjnej dla ludzi w tym kontekście.

Podczas Ekspedycji # 1, której wyniki zostały szczegółowo przedstawione w [7], Repairnator przeanalizował 11.523 kompilacji z błędami testowymi. W przypadku 3551 z nich (30,82%) firma Repairnator była w stanie lokalnie odtworzyć błąd testu. Spośród 3551 prób naprawy, Repairnator znalazł 15 łatek, które mogły sprawić, że kompilacja CI przebiegła pomyślnie. Jednak nasza analiza łatek ujawniła, że ​​żadna z tych łat nie była konkurencyjna dla ludzi, ponieważ pojawiły się zbyt późno (Repairnator stworzył łatkę po ludzkim deweloperze) lub były niskiej jakości (sprawiły, że kompilacja zakończyła się sukcesem).

Wyprawa nr 2 jest udana. Wykazało, że technologia naprawy programów przekroczyła granicę konkurencyjności człowieka. Repairnator wyprodukował 5 łatek, które spełniają kryteria konkurencyjności ludzkiej określone powyżej: 1) łatki zostały wyprodukowane przed ludzkimi, 2) ludzki programista zaakceptował łatki jako ważne wkłady, a łatki zostały połączone w główną bazę kodu.

Konkurencyjny dla ludzi wkład w Github, łatki zsyntetyzowane przez robota Repairnator i zaakceptowane przez człowieka:

  • 12 stycznia 2018, aaime / geowebcache / pull / 1, „Thanks for the patch!”
  • 23 marca 2018, parkito / BasicDataCodeU […] / pull / 3 „scalone commit 140a3e3 w parkito: develop”
  • 5 kwietnia 2018 r., Dkarv / jdcallgraph / pull / 2 „Thanks!”
  • 3 maja 2018 r., Eclipse / ditto / pull / 151 „Fajnie, dziękuję za przejście przez proces Eclipse i poprawkę.”
  • 25 czerwca 2018 r., Donnelldebnam / CodeU […] / pull / 151 „Thanks !!”

Pierwsza łatka scalona przez naszego robota naprawczego programu została zaakceptowana przez ludzkiego programistę 12 stycznia 2018 r. Oto historia: 12 stycznia 2018 r. O 12:28 uruchomiono kompilację projektu aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Kompilacja nie powiodła się po 2 minutach wykonania, ponieważ wystąpiły błędy w dwóch testach. Czterdzieści minut później, 12 stycznia 2018 o 13:08, Repairnator wykrył wadliwą kompilację podczas regularnego monitorowania i zaczął uruchamiać dostępne systemy naprawy programów skonfigurowane w Repairnator. Dziesięć minut później, o 13:18, znaleziono łatkę.

12 stycznia 2018 r. O 13:35 członek zespołu Repairnator wziął łatkę wygenerowaną przez Repairnator i potwierdził otwarcie odpowiedniego żądania ściągnięcia na GitHub. 12 stycznia 2018 r. O 14:10 programista zaakceptował łatkę i połączył ją z komentarzem: „Dziwne, myślałem, że już to naprawiłem… może zrobiłem to w innym miejscu. Dzięki za łatkę! ”. Była to pierwsza łatka wyprodukowana przez Repairnator i zaakceptowana jako ważny wkład przez twórcę oprogramowania, ostatecznie połączona z bazą kodu. Innymi słowy, Repairnator po raz pierwszy był konkurencyjny dla ludzi.

Po kolejnych 6 miesiącach działania Repairnator połączył 5 łatek przez ludzkich programistów, wymienionych powyżej.

Ogólnie rzecz biorąc, projekt Repairnator spełnił swoją misję. Wykazało, że naprawa programu może być uważana za konkurencyjną dla ludzi: Repairnator znalazł łatki 1) przed ludźmi, 2), które zostały uznane przez samych ludzi za dobrą jakość.

Przyszłość

Oprócz wykazania, że ​​naprawa programu jest konkurencyjna dla ludzi, projekt Repairnator dostarczył wiele informacji na temat błędów i ciągłej integracji, a także na temat bieżących niedociągnięć w badaniach napraw programów, przedstawionych w [7].

Zastanówmy się w szczególności nad jednym zagadnieniem własności intelektualnej. 3 maja 2018 roku Repairnator wydał dobrą łatkę do projektu GitHub eclipse / ditto. Niedługo po zaproponowaniu łatki jeden z programistów zapytał: „Możemy akceptować tylko żądania ściągania pochodzące od użytkowników, którzy podpisali Umowę licencyjną dla współtwórców Eclipse Foundation”. Zaskoczyło nas, ponieważ bot nie może fizycznie ani moralnie podpisać umowy licencyjnej i prawdopodobnie nie jest do tego uprawniony. Kto jest właścicielem własności intelektualnej i odpowiedzialnością za wkład bota: operator robota, implementator bota lub projektant algorytmu naprawy? To jedno z interesujących pytań odkrytych w ramach projektu Repairnator.

Wierzymy, że Repairnator zapowiada pewną przyszłość tworzenia oprogramowania, w której boty i ludzie będą płynnie współpracować, a nawet współpracować w zakresie artefaktów oprogramowania.

Chcesz dołączyć do społeczności Repairnator? Aby otrzymywać regularne wiadomości o Repairnator, wyślij wiadomość e-mail na adres repairnator.subscribe@4open.science!

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

W mediach:

  • Tajemnicze życie Luca Esape'a, nadzwyczajnego narzędzia do usuwania błędów. Jego wielki sekret? On nie jest człowiekiem (Thomas Claburn, The Register)

Bibliografia

  • [1] J. R. Koza (2010) Konkurencyjne wyniki uzyskane przez programowanie genetyczne. Programowanie genetyczne i maszyny ewoluowalne 11 (3–4), s. 251–284. Cytowany przez: .
  • [2] C. Lebeuf, M. D. Storey i A. Zagalsky (2018) Boty programowe. Oprogramowanie IEEE 35, s. 18–23. Cytowany przez: Automatyczna naprawa i ciągła integracja.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan i M. Monperrus (2016) Automatyczna naprawa prawdziwych błędów w Javie: eksperyment na dużą skalę w zestawie danych Defects4j. Empirical Software Engineering, s. 1–29. Cytowany przez: Konkurencyjność człowieka,.
  • [4] M. Monperrus (2017) Automatyczna naprawa oprogramowania: bibliografia. Ankiety komputerowe ACM. Cytowany przez: Automatyczna naprawa i ciągła integracja,.
  • [5] A. Murgia, D. Janssens, S. Demeyer i B. Vasilescu (2016). Wśród maszyn: interakcja człowiek-bot w społecznościowych pytaniach i na stronach internetowych. W materiałach z konferencji CHI 2016 Extended Abstracts on Human Factors in Computing Systems, s. 1272–1279. Cytowany przez: Konkurencyjność człowieka.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues i Y. Brun (2015) Czy leczenie jest gorsze niż choroba? przeregulowanie w automatycznej naprawie programu. W materiałach z 10. wspólnego spotkania w sprawie podstaw inżynierii oprogramowania w 2015 r., S. 532–543. Linki zewnętrzne: Dokument cytowany przez: Konkurencyjność człowieka.
  • [7] S. Urli, Z. Yu, L. Seinturier i M. Monperrus (2018) Jak zaprojektować program naprawy bota? Informacje z projektu Repairnator. W ICSE 2018–40. międzynarodowa konferencja na temat inżynierii oprogramowania, śledzenie inżynierii oprogramowania w praktyce, linki zewnętrzne: Link cytowany przez: Expedition Achievements, The Future.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta i S. Panichella (2017) A Tale of CI Build Build: A Open-source and perspektywa organizacji finansowej. Na międzynarodowej konferencji na temat konserwacji i ewolucji oprogramowania, cytowanej przez: Automatyczna naprawa i ciągła integracja.