Patch Berasaskan Manusia dalam Pembaikan Program Automatik dengan Repairnator

Repairnator adalah bot. Ia sentiasa memantau pepijat perisian yang ditemui semasa integrasi berterusan perisian sumber terbuka dan cuba untuk membetulkannya secara automatik. Jika ia berhasil mensintesis patch yang sah, Repairnator mencadangkan patch kepada pemaju manusia, menyamar di bawah identiti manusia palsu. Setakat ini, Repairnator dapat menghasilkan 5 patch yang diterima oleh pemaju manusia dan secara kekal digabungkan dalam pangkalan kod. Ini adalah satu pencapaian penting untuk daya saing manusia dalam penyelidikan kejuruteraan perisian mengenai pembaikan program automatik. Dalam jawatan ini, kami menceritakan kisah tentang penyelidikan yang dilakukan di KTH Royal Institute of Technology, Inria, Universiti Lille dan Universiti Valenciennes.

Kajian pembaikan program mengejar idea bahawa algoritma dapat menggantikan manusia untuk memperbaiki bug perisian [4]. Pembetulan pepijat adalah tampalan yang menyisipkan, memadam atau mengubah suai kod sumber. Sebagai contoh, dalam patch berikut, pemaju telah mengubah keadaan pernyataan jika:

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

Bot pembaikan program adalah ejen buatan yang cuba mensintesiskan patch kod sumber. Ia menganalisis pepijat dan menghasilkan patch, dengan cara yang sama seperti pemaju manusia yang terlibat dalam aktiviti penyelenggaraan perisian. Idea bot perbaikan program ini mengganggu, kerana hari ini manusia bertanggungjawab untuk membetulkan pepijat. Dalam kata lain, kita bercakap tentang bot yang bertujuan untuk (sebahagiannya) menggantikan pemaju manusia untuk tugas yang membosankan.

Apabila bot cuba untuk mencapai tugas yang biasanya dilakukan oleh manusia, ia dikenali sebagai tugas berdaya saing manusia [1]. Penilaian empirikal penyelidikan perbaikan program [3] menunjukkan bahawa sistem pembaikan program semasa dapat mensintesis patch untuk bug nyata dalam program sebenar. Walau bagaimanapun, semua patch telah disintesis untuk pepijat yang lepas, untuk bug yang ditetapkan oleh pemaju manusia pada masa lalu, biasanya tahun lalu. Walaupun ini menunjukkan kelayakan teknikal pembaikan program, ini gagal menunjukkan bahawa pembaikan program adalah daya saing manusia.

Daya saing manusia

Untuk menunjukkan pembaikan program itu adalah kompetitif manusia, bot pembaikan program perlu mencari patch berkualiti tinggi sebelum manusia melakukannya. Dalam konteks ini, patch boleh dianggap sebagai daya saing manusia jika ia memenuhi kedua-dua syarat ketepatan masa dan kualiti. Ketepatan masa merujuk kepada hakikat bahawa sistem mesti mencari patch sebelum pemaju manusia. Dengan kata lain, sistem prototaip mesti menghasilkan patch dalam urutan magnitud minit, bukan hari. Juga, tampalan yang dihasilkan oleh bot mestilah betul-betul, kualiti yang sama - betul dan boleh dibaca - berbanding patch yang ditulis oleh manusia. Perhatikan bahawa ada patch yang kelihatan betul dari sudut pandangan bot, namun itu tidak betul (ini dikenali sebagai patch yang terlalu banyak dalam kesusasteraan [6, 3]). Tompok-tompok itu boleh dikatakan tidak berdaya saing manusia, kerana manusia tidak akan menerima mereka dalam asas kod mereka.

Oleh itu, untuk patch menjadi daya saing manusia 1) bot harus mensintesis patch lebih cepat daripada pemaju manusia 2) patch harus dinilai cukup baik oleh pemaju manusia dan secara kekal digabungkan dalam asas kod.

Terdapat satu lagi aspek untuk dipertimbangkan. Telah ditunjukkan bahawa jurutera manusia tidak menerima sumbangan dari bot dengan mudah seperti sumbangan dari manusia lain, walaupun mereka sama sekali identik [5]. Alasannya ialah manusia cenderung mempunyai kecenderungan priori terhadap mesin, dan lebih toleran terhadap kesilapan jika sumbangan berasal dari rakan sebaya manusia. Dalam konteks pembaikan program, ini bermakna bahawa pemaju mungkin meletakkan bar lebih tinggi pada kualiti patch, jika mereka tahu bahawa patch datang dari bot. Ini akan menghalang usaha kami untuk membuktikan daya saing manusia dalam konteks pembaikan program.

Untuk mengatasi masalah ini, kami telah membuat keputusan awal dalam projek itu bahawa semua patch Repairnator akan dicadangkan di bawah identiti manusia palsu. Kami telah mencipta pengguna GitHub, yang dipanggil Luc Esape, yang dibentangkan sebagai jurutera perisian di makmal penyelidikan kami. Luc mempunyai gambar profil dan kelihatan seperti pemaju junior, tidak sabar-sabar untuk membuat sumbangan sumber terbuka pada GitHub. Sekarang bayangkan Repairnator, menyamar sebagai Luc Esape mencadangkan patch: pemaju mengkaji ia berfikir bahawa dia sedang mengkaji sumbangan manusia. Penyamaran ini diperlukan untuk menguji hipotesis sains kami daya saing manusia. Kini, demi etika, identiti sebenar Luc telah didedahkan pada setiap permintaannya.

Pembaikan Automatik dan Integrasi Berterusan

Integrasi berterusan, aka CI, adalah idea bahawa pelayan mengkompilasi kod dan menjalankan semua ujian bagi setiap komit yang dibuat dalam sistem kawalan versi projek perisian (contohnya Git). Dalam istilah CI, ada binaan untuk setiap komit. Binaan mengandungi maklumat tentang snapshot kod sumber yang digunakan (mis. Rujukan kepada komit Git), hasil penyusunan dan pelaksanaan ujian (misalnya gagal atau kejayaan), dan log jejak pelaksanaan. Binaan dikatakan gagal jika penyusunan gagal atau sekurang-kurangnya satu kes ujian gagal. Telah terbukti bahawa kira-kira satu dari 4 membina gagal, dan bahawa punca kegagalan yang paling umum ialah kegagalan ujian [8].

Idea utama Repairnator adalah untuk secara automatik menghasilkan patch yang membaiki kegagalan membina, kemudian menunjukkannya kepada pemaju manusia, akhirnya dapat melihat sama ada pemaju manusia akan menerima mereka sebagai sumbangan yang sah ke pangkalan kod. Jika ini berlaku, itu akan menjadi bukti daya saing manusia dalam pembaikan program.

Persediaan ini - secara automatik memperbaiki membina kegagalan yang berlaku dalam integrasi berterusan - amat sesuai dan tepat pada masanya untuk sebab-sebab berikut. Pertama, membina kegagalan memenuhi pernyataan masalah utama bagi program pembaikan ujian berdasarkan suite [4], di mana pepijat ditentukan sebagai kes ujian yang gagal, dan kes-kes ujian yang gagal digunakan untuk menggerakkan sintesis automatik patch [4]. Kedua, ia membolehkan membandingkan bot dan manusia secara adil: apabila ujian gagal ditemui pada pelayan integrasi yang berterusan, pemaju manusia dan bot diberitahu mengenainya, pada masa yang sama. Pemberitahuan kegagalan ujian ini adalah titik permulaan persaingan manusia vs bot.

Tumpuan Repairnator untuk membina kegagalan adalah unik, tetapi ia sesuai dengan gambaran besar bot pintar untuk perisian [2]. Sebagai contoh, Facebook mempunyai alat yang dipanggil SapFix yang memperbaiki bug yang terdapat dengan ujian automatik. Juga berkaitan, penyerang bot DARPA Cyber ​​Grand Challenge dan pembela cuba menjadi daya saing manusia berkenaan dengan pakar keselamatan.

Repairnator secara ringkas

Pada 2017-2018, kami telah merangka, melaksanakan dan mengendalikan Repairnator, sebuah bot untuk pembaikan program automatik. Repairnator khusus untuk membaiki kegagalan membina yang berlaku semasa integrasi berterusan. Ia sentiasa memantau beribu-ribu orang yang didorong ke platform pengehosan kod GitHub, dan menganalisis binaan mereka yang sepadan. Setiap minit, ia melancarkan percubaan pembaikan baru untuk menyelesaikan pepijat sebelum pemaju manusia. Ia direka untuk pergi secepat mungkin kerana ia menyertai perlumbaan: jika Repairnator mendapati patch sebelum pemaju manusia, ia adalah daya saing manusia.

Marilah kita beri gambaran keseluruhan bagaimana bot Repairnator berfungsi.

Input utama dari Repairnator adalah integrasi yang berterusan, yang dicetuskan oleh komitmen yang dibuat oleh pemaju (bahagian atas angka, (a) dan (b)) berdasarkan projek GitHub (a). Output Repairnator dua kali ganda: (1) secara automatik menghasilkan patch untuk memperbaiki gagal membina (g), jika ada; (2) ia mengumpul data berharga untuk penyelidikan perbaikan program masa depan (h) dan (k). Secara tetap, Repairnator memantau semua aktiviti berterusan dari projek GitHub ©. Binaan CI diberikan sebagai input kepada tiga saluran peringkat: (1) peringkat pertama mengumpulkan dan menganalisis CI membina log (e); (2) peringkat kedua bertujuan untuk menghasilkan semula kegagalan membina yang telah berlaku pada CI (f); (3) peringkat ketiga menjalankan prototaip pembaikan program yang berbeza dari penyelidikan akademik terkini. Apabila patch ditemui, ahli projek Repairnator melakukan pemeriksaan kewarasan yang cepat, untuk mengelakkan membuang masa berharga pemaju sumber terbuka. (i) Jika dia mendapati tampalan tidak merosot, dia kemudian mencadangkannya kepada pemaju asal projek itu sebagai permintaan menarik pada GitHub (j). Pemaju kemudian mengikuti proses semakan kod biasa dan menggabungkannya.

Repairnator perlu beroperasi dalam ekosistem perisian yang diberikan. Oleh kerana kepakaran kami dengan Java dalam projek-projek penyelidikan masa lalu, pelaksanaan prototype Repairnator memberi tumpuan kepada membaiki perisian yang ditulis dalam bahasa pengaturcaraan Java, yang dibina dengan toolkain Maven, dalam projek sumber terbuka yang dianjurkan di GitHub, yang menggunakan platform integrasi Travis CI .

Pencapaian Ekspedisi

Kami telah beroperasi Repairnator sejak Januari 2017, dalam tiga fasa yang berbeza. Sepanjang satu bulan, pada Januari 2017, kami melakukan percubaan perintis dengan versi awal prototaip. Dari 1 Februari 2017 hingga 31 Disember 2017, kami menjalankan Repairnator dengan senarai tetap 14,188 projek, kami panggilnya "Expedition # 1". Dari 1 Januari 2018 hingga 30 Jun 2018, Repairnator telah memantau aliran Travis CI secara real time, kami memanggilnya "Ekspedisi # 2"

Matlamat utama eksperimen perintis adalah untuk mengesahkan reka bentuk dan pelaksanaan awal kami. Kami mendapati bahawa prototaip kami mampu melakukan kira-kira 30 percubaan pembaikan setiap hari, memandangkan sumber pengkomputeran kami. Lebih penting lagi, eksperimen perintis ini mengesahkan andaian teknologi teras: sebahagian besar projek sumber terbuka popular menggunakan Travis dan majoriti mereka menggunakan teknologi Maven sebagai membina. Ini bermakna kita akan mempunyai peluang yang adil untuk mencapai matlamat kami untuk mensintesiskan patch persaingan manusia dalam konteks itu.

Semasa Expedition # 1, hasilnya dibentangkan secara terperinci dalam [7], Repairnator telah menganalisis 11,523 membina dengan kegagalan ujian. Bagi 3,551 daripadanya (30.82%), Repairnator berjaya membiak kegagalan ujian tempatan. Daripada 3,551 percubaan pembaikan, Repairnator mendapati 15 patch yang boleh membuat lulus membina CI. Walau bagaimanapun, analisis patch kami mendedahkan bahawa tiada satu pun patch tersebut adalah kompetitif manusia kerana mereka terlambat (Repairnator menghasilkan patch selepas pemaju manusia) atau berkualiti rendah (mereka membuat binaan berjaya secara kebetulan).

Ekspedisi # 2 adalah yang berjaya. Ia telah menunjukkan bahawa teknologi pembaikan program telah menyeberang sempadan daya saing manusia. Repairnator telah menghasilkan 5 patch yang memenuhi kriteria daya saing manusia yang ditakrifkan di atas: 1) patch telah dihasilkan sebelum manusia, 2) pemaju manusia menerima patch sebagai sumbangan yang sah, dan patch telah digabungkan dalam pangkalan kode utama.

Sumbangan kompetitif manusia di Github, patch disintesis oleh robot Repairnator dan diterima oleh pemaju manusia:

  • Jan 12, 2018, aaime / geowebcache / pull / 1, "Terima kasih kerana patch!"
  • Mar 23, 2018, parkito / BasicDataCodeU [...] / pull / 3 "bergabung koma 140a3e3 ke parkito: membangunkan"
  • April 5, 2018, dkarv / jdcallgraph / tarik / 2 "Terima kasih!"
  • 3 Mei 2018, gerhana / ditto / pull / 151 "Hebat, terima kasih kerana meneruskan proses Eclipse dan untuk menetapkannya."
  • 25 Jun, 2018, donnelldebnam / CodeU [...] / tarik / 151 "Terima kasih !!"

Patch pertama yang disatukan oleh bot pembaikan program kami diterima oleh pemaju manusia pada 12 Jan, 2018. Berikut adalah kisahnya: pada 12 Januari 2018 pada 12:28 petang, pembina dicetuskan pada projek aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Binaan itu gagal selepas 2 minit pelaksanaan, kerana dua kes uji kesilapan. Empat puluh minit kemudian, pada 12 Jan 2018 pada 1:08 petang, Repairnator mengesan pembaikan gagal dalam pemantauan biasa, dan mula menjalankan sistem pembaikan program yang ada yang dikonfigurasi dalam Repairnator. Sepuluh minit kemudian, pada jam 1:18 petang, ia menemui patch.

Pada 12 Jan 2018, pada pukul 1:35 petang, seorang ahli pasukan Repairnator mengambil patch yang dihasilkan oleh Repairnator, dan membuktikan pembukaan permintaan menarik yang sama pada GitHub. Pada 12 Jan 2018, pada jam 2:10 petang, pemaju menerima patch itu, dan menggabungkannya dengan komen: "Pelik, saya fikir saya sudah menetapkan ini ... mungkin saya lakukan di tempat lain. Terima kasih kerana patch! ". Itulah patch pertama yang dihasilkan oleh Repairnator dan diterima sebagai sumbangan yang sah oleh pemaju manusia, secara muktamad digabungkan dalam asas kod. Dengan kata lain, Repairnator adalah kompetitif manusia untuk kali pertama.

Selepas 6 bulan lagi operasi, Repairnator mempunyai 5 patch yang digabungkan oleh pemaju manusia, yang disenaraikan di atas.

Secara keseluruhannya, projek Repairnator telah memenuhi misinya. Ia telah menunjukkan bahawa pembaikan program boleh dianggap sebagai daya saingan manusia: Repairnator telah menemui patch 1) sebelum manusia, 2) yang dianggap berkualiti baik oleh manusia sendiri.

Masa depan

Di samping menunjukkan bahawa pembaikan program adalah daya saing manusia, projek Repairnator telah menyediakan banyak maklumat tentang pepijat dan integrasi yang berterusan, dan mengenai kekurangan semasa penyelidikan perbaikan program yang dibentangkan di [7].

Mari kita tinggalkan pada satu titik khususnya, persoalan harta intelektual. Pada 3 Mei, 2018, Repairnator menghasilkan patch yang baik untuk gerhana / ditto projek GitHub. Tidak lama selepas mencadangkan patch itu, salah seorang pemaju bertanya "Kami hanya boleh menerima permintaan menarik yang datang dari pengguna yang menandatangani Perjanjian Lesen Penyumbang Simpanan Eclipse Foundation.". Kami hairan kerana bot tidak boleh menandatangani perjanjian lesen secara fizikal atau moral dan mungkin tidak berhak berbuat demikian. Siapa yang memiliki harta intelektual dan tanggungjawab sumbangan bot: pengendali robot, pelaksana bot atau perancang algoritma pembaikan? Ini adalah salah satu daripada soalan menarik yang ditemui oleh projek Repairnator.

Kami percaya bahawa Repairnator menyiapkan masa depan tertentu dalam pembangunan perisian, di mana bot dan manusia lancar akan bekerjasama dan juga bekerjasama dengan artifak perisian.

Mahu menyertai komuniti Repairnator? Untuk menerima berita tetap tentang Repairnator, menangkap e-mel di repairnator.subscribe@4open.science!

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

Dalam media:

  • Kehidupan misteri Luc Esape, pembetulkan pepijat yang luar biasa. Rahsia besarnya? Dia bukan manusia (Thomas Claburn, The Register)

Rujukan

  • [1] J. R. Koza (2010) Hasil Persaingan Manusia Dihasilkan oleh Pengaturcaraan Genetik. Pengaturcaraan Genetik dan Mesin yang Boleh Ditarik 11 (3-4), ms 251-284. Dipetik oleh:.
  • [2] C. Lebeuf, M. D. Storey dan A. Zagalsky (2018) Bot perisian. Perisian IEEE 35, ms 18-23. Dipetik oleh: Pembaikan Automatik dan Integrasi Berterusan.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan dan M. Monperrus (2016) Pembaikan Automatik Bug Serupa di Jawa: Eksperimen Besar-besaran pada Dataset Defects4j. Kejuruteraan Perisian Empirikal, ms. 1-29. Dipetik oleh: Daya saing manusia,.
  • [4] M. Monperrus (2017) Pembaikan Perisian Automatik: Bibliografi. Suruhanjaya Pengkomputeran ACM. Dipetik oleh: Pembaikan Automatik dan Integrasi Berterusan,.
  • [5] A. Murgia, D. Janssens, S. Demeyer dan B. Vasilescu (2016) Antara mesin: Interaksi manusia-bot di laman sesawang sosial & laman web. Dalam Prosiding Persidangan CHI 2016 Abstrak Yang Dihapuskan pada Faktor Manusia dalam Sistem Pengkomputeran, ms 1272-1279. Dipetik oleh: Daya saing manusia.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues dan Y. Brun (2015) Adakah penyembuhan lebih teruk daripada penyakit ini? yang berlebihan dalam pembaikan program automatik. Dalam Prosiding Mesyuarat Bersama Ke-10 pada Yayasan Kejuruteraan Perisian, ms 532-543. Pautan Luar: Dokumen Dipetik oleh: Daya saing manusia.
  • [7] S. Urli, Z. Yu, L. Seinturier dan M. Monperrus (2018) Bagaimana Menghasilkan Bot Perbaikan Program? Wawasan dari Projek Repairnator. Dalam Persidangan Antarabangsa ICSE 2018-40 mengenai Kejuruteraan Perisian, Kejuruteraan Perisian Tracking in Practice, Pautan Luar: Pautan Dipetik oleh: Pencapaian Ekspedisi, Masa Depan.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta dan S. Panichella (2017) Tale of CI Build Failures: Open-source and Perspektif Organisasi Kewangan. Dalam Persidangan Antarabangsa mengenai Penyelenggaraan dan Evolusi Perisian, Dipetik oleh: Pembaikan Automatik dan Integrasi Berterusan.