Bản vá cạnh tranh của con người trong Sửa chữa chương trình tự động với Repairnator

Thợ sửa chữa là một bot. Nó liên tục theo dõi các lỗi phần mềm được phát hiện trong quá trình tích hợp liên tục phần mềm nguồn mở và cố gắng sửa chúng tự động. Nếu nó thành công trong việc tổng hợp một bản vá hợp lệ, Repairnator đề xuất bản vá cho các nhà phát triển con người, ngụy trang dưới danh tính người giả. Đến nay, Repairnator đã có thể tạo ra 5 bản vá được các nhà phát triển con người chấp nhận và hợp nhất vĩnh viễn trong cơ sở mã. Đây là một cột mốc quan trọng cho khả năng cạnh tranh của con người trong nghiên cứu kỹ thuật phần mềm về sửa chữa chương trình tự động. Trong bài đăng này, chúng tôi kể câu chuyện về nghiên cứu này được thực hiện tại Viện Công nghệ Hoàng gia KTH, Inria, Đại học Lille và Đại học Valenciennes.

Nghiên cứu sửa chữa chương trình theo đuổi ý tưởng rằng các thuật toán có thể thay thế con người để sửa lỗi phần mềm [4]. Một sửa lỗi là một bản vá chèn, xóa hoặc sửa đổi mã nguồn. Ví dụ, trong bản vá sau, nhà phát triển đã sửa đổi điều kiện của câu lệnh if:

- nếu (x <10)
+ nếu (x <= 10)
foo ();

Một bot sửa chữa chương trình là một tác nhân nhân tạo cố gắng tổng hợp các bản vá mã nguồn. Nó phân tích các lỗi và tạo ra các bản vá, giống như các nhà phát triển con người tham gia vào các hoạt động bảo trì phần mềm. Ý tưởng về một bot sửa chữa chương trình là đột phá, bởi vì ngày nay con người chịu trách nhiệm sửa lỗi. Nói cách khác, chúng ta đang nói về một bot có nghĩa là (một phần) thay thế các nhà phát triển con người cho các nhiệm vụ tẻ nhạt.

Khi bot cố gắng đạt được một nhiệm vụ thường được thực hiện bởi con người, nó được gọi là nhiệm vụ cạnh tranh của con người [1]. Các đánh giá thực nghiệm về nghiên cứu sửa chữa chương trình [3] cho thấy các hệ thống sửa chữa chương trình hiện tại có thể tổng hợp các bản vá cho các lỗi thực trong các chương trình thực. Tuy nhiên, tất cả các bản vá đó đã được tổng hợp cho các lỗi trong quá khứ, cho các lỗi đã được sửa bởi các nhà phát triển con người trong quá khứ, thường là nhiều năm trước. Mặc dù điều này cho thấy tính khả thi về kỹ thuật của sửa chữa chương trình, nhưng điều này không cho thấy rằng sửa chữa chương trình có tính cạnh tranh của con người.

Năng lực cạnh tranh của con người

Để chứng minh rằng sửa chữa chương trình là cạnh tranh của con người, một bot sửa chữa chương trình phải tìm một bản vá chất lượng cao trước khi con người làm như vậy. Trong bối cảnh này, một bản vá có thể được coi là cạnh tranh với con người nếu nó đáp ứng hai điều kiện về tính kịp thời và chất lượng. Tính kịp thời đề cập đến thực tế là hệ thống phải tìm một bản vá trước nhà phát triển con người. Nói cách khác, hệ thống nguyên mẫu phải tạo ra các bản vá theo thứ tự độ lớn của phút, chứ không phải ngày. Ngoài ra, bản vá do bot tạo ra phải đủ chính xác, có chất lượng tương tự - chính xác và dễ đọc - so với bản vá được viết bởi con người. Lưu ý rằng có các bản vá trông chính xác theo quan điểm bot bot, tuy nhiên không chính xác (điều này được gọi là các bản vá quá mức trong tài liệu [6, 3]). Những bản vá đó được cho là không cạnh tranh với con người, bởi vì con người sẽ không bao giờ chấp nhận chúng trong cơ sở mã của họ.

Do đó, để một bản vá có khả năng cạnh tranh với con người 1) bot phải tổng hợp bản vá nhanh hơn nhà phát triển con người 2) bản vá phải được nhà phát triển con người đánh giá đủ tốt và được sáp nhập vĩnh viễn vào cơ sở mã.

Có một khía cạnh nữa để xem xét. Nó đã được chứng minh rằng các kỹ sư của con người không chấp nhận sự đóng góp từ bot dễ dàng như sự đóng góp từ những người khác, ngay cả khi chúng hoàn toàn giống nhau [5]. Lý do là con người có xu hướng thiên vị chống lại máy móc, và khoan dung hơn với các lỗi nếu sự đóng góp đến từ một người ngang hàng. Trong bối cảnh sửa chữa chương trình, điều này có nghĩa là các nhà phát triển có thể đặt thanh cao hơn về chất lượng của bản vá, nếu họ biết rằng bản vá đến từ bot. Điều này sẽ cản trở nhiệm vụ của chúng tôi cho một bằng chứng cạnh tranh của con người trong bối cảnh sửa chữa chương trình.

Để khắc phục vấn đề này, chúng tôi đã quyết định sớm trong dự án rằng tất cả các bản vá sửa chữa sẽ được đề xuất dưới danh tính người giả. Chúng tôi đã tạo ra một người dùng GitHub, được gọi là Luc Esape, người được giới thiệu là kỹ sư phần mềm trong phòng thí nghiệm nghiên cứu của chúng tôi. Luc có một hình ảnh hồ sơ và trông giống như một nhà phát triển cơ sở, mong muốn đóng góp nguồn mở trên GitHub. Bây giờ hãy tưởng tượng Repairnator, ngụy trang thành Luc Esape đề xuất một bản vá: nhà phát triển xem xét nó nghĩ rằng cô ấy đang xem xét đóng góp của con người. Việc ngụy trang này là cần thiết để kiểm tra giả thuyết khoa học của chúng tôi về khả năng cạnh tranh của con người. Bây giờ, vì đạo đức, danh tính thực sự của Luc đã được tiết lộ trên mỗi yêu cầu kéo của anh ta.

Sửa chữa tự động và tích hợp liên tục

Tích hợp liên tục, hay còn gọi là CI, là ý tưởng rằng máy chủ biên dịch mã và chạy tất cả các thử nghiệm cho từng cam kết được thực hiện trong hệ thống kiểm soát phiên bản của dự án phần mềm (ví dụ: Git). Theo cách nói của CI, có một bản dựng cho mỗi lần xác nhận. Bản dựng chứa thông tin về ảnh chụp nhanh mã nguồn được sử dụng (ví dụ: tham chiếu đến cam kết Git), kết quả của quá trình biên dịch và thực thi thử nghiệm (ví dụ: thất bại hoặc thành công) và nhật ký theo dõi thực thi. Bản dựng được cho là thất bại nếu quá trình biên dịch thất bại hoặc ít nhất một trường hợp thử nghiệm thất bại. Nó đã được chỉ ra rằng khoảng một trong 4 bản dựng bị lỗi và nguyên nhân phổ biến nhất gây ra lỗi bản dựng là lỗi thử nghiệm [8].

Ý tưởng chính của Repairnator là tự động tạo ra các bản vá sửa chữa các lỗi xây dựng, sau đó hiển thị chúng cho các nhà phát triển con người, để xem liệu những nhà phát triển con người đó có chấp nhận chúng như những đóng góp hợp lệ cho cơ sở mã hay không. Nếu điều này xảy ra, đó sẽ là bằng chứng về khả năng cạnh tranh của con người trong việc sửa chữa chương trình.

Thiết lập này tự động sửa chữa các lỗi xây dựng xảy ra trong tích hợp liên tục - đặc biệt thích hợp và kịp thời vì những lý do sau. Đầu tiên, các lỗi xây dựng đáp ứng tuyên bố vấn đề cốt lõi của sửa chữa chương trình dựa trên bộ thử nghiệm [4], trong đó các lỗi được chỉ định là các trường hợp thử nghiệm bị lỗi và các trường hợp thử nghiệm thất bại này được sử dụng để thúc đẩy quá trình tổng hợp tự động của bản vá [4]. Thứ hai, nó cho phép so sánh các bot và con người trên cơ sở công bằng: khi một thử nghiệm thất bại được phát hiện trên máy chủ tích hợp liên tục, nhà phát triển con người và bot được thông báo về nó, cùng một lúc. Thông báo lỗi thử nghiệm này là điểm khởi đầu của cuộc thi giữa người và bot.

Repairnator từ tập trung vào các lỗi xây dựng là duy nhất, nhưng nó phù hợp với bức tranh lớn của các bot thông minh cho phần mềm [2]. Chẳng hạn, Facebook có một công cụ có tên là SapFix giúp sửa chữa các lỗi được tìm thấy bằng thử nghiệm tự động. Cũng liên quan, những kẻ tấn công và người bảo vệ bot DARPA Cyber ​​Grand Challenge cố gắng cạnh tranh với con người đối với các chuyên gia bảo mật.

Thợ sửa chữa trong một Nutshell

Trong 2017 20172018, chúng tôi đã thiết kế, triển khai và vận hành Repairnator, một bot để sửa chữa chương trình tự động. Repairnator là chuyên ngành để sửa chữa các lỗi xây dựng xảy ra trong quá trình tích hợp liên tục. Nó liên tục theo dõi hàng ngàn cam kết được đẩy lên nền tảng lưu trữ mã GitHub và phân tích các bản dựng tương ứng của chúng. Mỗi phút, nó khởi chạy các nỗ lực sửa chữa mới để sửa lỗi trước nhà phát triển con người. Nó được thiết kế để đi nhanh nhất có thể bởi vì nó tham gia vào một cuộc đua: nếu Repairnator tìm thấy một bản vá trước nhà phát triển con người, thì đó là sự cạnh tranh của con người.

Bây giờ chúng ta hãy đưa ra một cái nhìn tổng quan về cách bot Repairnator hoạt động.

Đầu vào chính của Repairnator là các bản dựng tích hợp liên tục, được kích hoạt bởi các cam kết được thực hiện bởi các nhà phát triển (phần trên cùng của hình, (a) và (b)) dựa trên các dự án GitHub (a). Các đầu ra của Repairnator là hai lần: (1) nó tự động tạo ra các bản vá để sửa chữa các bản dựng bị lỗi (g), nếu có; (2) nó thu thập dữ liệu có giá trị cho nghiên cứu sửa chữa chương trình trong tương lai (h) và (k). Vĩnh viễn, Repairnator giám sát tất cả hoạt động liên tục từ các dự án GitHub ©. Các bản dựng CI được đưa ra làm đầu vào cho một đường ống ba giai đoạn: (1) giai đoạn đầu tiên thu thập và phân tích nhật ký xây dựng CI (e); (2) giai đoạn thứ hai nhằm mục đích tái tạo cục bộ các lỗi xây dựng đã xảy ra trên CI (f); (3) giai đoạn thứ ba chạy các nguyên mẫu sửa chữa chương trình khác nhau đến từ nghiên cứu học thuật mới nhất. Khi tìm thấy một bản vá, một thành viên dự án Repairnator thực hiện kiểm tra độ tỉnh táo nhanh chóng, để tránh lãng phí thời gian quý báu của các nhà phát triển nguồn mở. (i) Nếu cô ấy tìm thấy bản vá không bị thoái hóa, thì cô ấy sẽ đề xuất nó cho các nhà phát triển ban đầu của dự án như một yêu cầu kéo trên GitHub (j). Các nhà phát triển sau đó làm theo quy trình thông thường của họ - xem xét và hợp nhất mã.

Repairnator phải hoạt động trong một hệ sinh thái phần mềm nhất định. Do chuyên môn của chúng tôi với Java trong các dự án nghiên cứu trước đây, việc triển khai nguyên mẫu của Repairnator tập trung vào sửa chữa phần mềm được viết bằng ngôn ngữ lập trình Java, được xây dựng bằng chuỗi công cụ Maven, trong các dự án nguồn mở được lưu trữ trên GitHub, sử dụng nền tảng tích hợp liên tục Travis CI .

Thành tựu thám hiểm

Chúng tôi đã vận hành Repairnator từ tháng 1 năm 2017, theo ba giai đoạn khác nhau. Trong một tháng, vào tháng 1 năm 2017, chúng tôi đã thực hiện một thử nghiệm thử nghiệm với phiên bản ban đầu của nguyên mẫu. Từ ngày 1 tháng 2 năm 2017 đến ngày 31 tháng 12 năm 2017, chúng tôi đã chạy Repairnator với một danh sách cố định gồm 14.188 dự án, chúng tôi gọi đó là Cuộc thám hiểm số 1. Từ ngày 1 tháng 1 năm 2018 đến ngày 30 tháng 6 năm 2018, Repairnator đã theo dõi luồng xây dựng Travis CI trong thời gian thực, chúng tôi gọi đó là Cuộc thám hiểm số 2

Mục tiêu chính của thí nghiệm là xác nhận thiết kế và triển khai ban đầu của chúng tôi. Chúng tôi thấy rằng nguyên mẫu của chúng tôi có khả năng thực hiện khoảng 30 lần sửa chữa mỗi ngày, dựa trên tài nguyên máy tính của chúng tôi. Quan trọng hơn, thí nghiệm thử nghiệm này đã xác thực các giả định công nghệ cốt lõi của chúng tôi: một tỷ lệ đáng kể các dự án nguồn mở phổ biến sử dụng Travis và phần lớn trong số chúng sử dụng Maven làm công nghệ xây dựng. Điều này có nghĩa là chúng tôi sẽ có cơ hội công bằng để đạt được mục tiêu tổng hợp một bản vá cạnh tranh của con người trong bối cảnh đó.

Trong Cuộc thám hiểm số 1, có kết quả được trình bày chi tiết trong [7], Repairnator đã phân tích 11,523 bản dựng với các lỗi thử nghiệm. Đối với 3.551 người trong số họ (30,82%), Repairnator đã có thể tái tạo cục bộ lỗi thử nghiệm. Trong số 3.551 nỗ lực sửa chữa, Repairnator đã tìm thấy 15 bản vá có thể khiến CI xây dựng vượt qua. Tuy nhiên, phân tích bản vá của chúng tôi cho thấy rằng không có bản vá nào có khả năng cạnh tranh với con người vì chúng đến quá muộn (Repairnator đã tạo ra một bản vá sau khi nhà phát triển con người) hoặc có chất lượng thấp (họ đã tạo ra bản dựng thành công một cách trùng hợp).

Cuộc thám hiểm # 2 là một trong những thành công. Nó đã chỉ ra rằng công nghệ sửa chữa chương trình đã vượt qua biên giới của khả năng cạnh tranh của con người. Repairnator đã tạo ra 5 bản vá đáp ứng các tiêu chí về khả năng cạnh tranh của con người được xác định ở trên: 1) các bản vá được tạo ra trước người, 2) một nhà phát triển con người chấp nhận các bản vá là đóng góp hợp lệ và các bản vá được hợp nhất trong cơ sở mã chính.

Đóng góp cạnh tranh của con người trên Github, các bản vá được tổng hợp bởi robot Repairnator và được nhà phát triển con người chấp nhận:

  • Ngày 12 tháng 1 năm 2018, aaime / geowebcache / pull / 1, Burg Cảm ơn bản vá!
  • Ngày 23 tháng 3 năm 2018, parkito / BasicDataCodeU [Tiết] / pull / 3 đã hợp nhất cam kết 140a3e3 thành parkito: phát triển Tiết
  • Ngày 5 tháng 4 năm 2018, dkarv / jdcallgraph / pull / 2 ăn Cảm ơn!
  • Ngày 3 tháng 5 năm 2018, nhật thực / ditto / pull / 151, Cool, cảm ơn vì đã trải qua quá trình Eclipse và để khắc phục.
  • Ngày 25 tháng 6 năm 2018, donnelldebnam / CodeU [Tiết] / pull / 151 Kiếm Cảm ơn !!

Bản vá đầu tiên được hợp nhất bởi bot sửa chữa chương trình của chúng tôi đã được chấp nhận bởi một nhà phát triển con người vào ngày 12 tháng 1 năm 2018. Đây là câu chuyện: vào ngày 12 tháng 1 năm 2018 lúc 12:28, một bản dựng đã được kích hoạt trên dự án aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Việc xây dựng thất bại sau 2 phút thực hiện, vì hai trường hợp thử nghiệm bị lỗi. Bốn mươi phút sau, vào ngày 12 tháng 1 năm 2018 lúc 1:08 chiều, Repairnator đã phát hiện ra bản dựng bị lỗi trong quá trình theo dõi thường xuyên của nó và bắt đầu chạy các hệ thống sửa chữa chương trình có sẵn được cấu hình trong Repairnator. Mười phút sau, lúc 1:18 chiều, nó tìm thấy một bản vá.

Vào ngày 12 tháng 1 năm 2018, lúc 1:35 chiều, một thành viên nhóm Repairnator đã lấy bản vá được tạo bởi Repairnator và xác thực việc mở yêu cầu kéo tương ứng trên GitHub. Vào ngày 12 tháng 1 năm 2018, lúc 2:10, nhà phát triển đã chấp nhận bản vá và hợp nhất nó với một bình luận: khăn Weird, tôi nghĩ rằng tôi đã sửa lỗi này có lẽ tôi đã làm ở một nơi khác. Cảm ơn các bản vá! Đó là bản vá đầu tiên do Repairnator sản xuất và được chấp nhận như một đóng góp hợp lệ của một nhà phát triển con người, được kết hợp chắc chắn trong cơ sở mã. Nói cách khác, Repairnator lần đầu tiên cạnh tranh với con người.

Sau 6 tháng hoạt động, Repairnator đã có 5 bản vá được hợp nhất bởi các nhà phát triển con người, được liệt kê ở trên.

Nhìn chung, dự án Repairnator đã hoàn thành nhiệm vụ của mình. Nó đã chỉ ra rằng sửa chữa chương trình có thể được coi là cạnh tranh với con người: Repairnator đã tìm thấy các bản vá 1) trước con người, 2) được coi là có chất lượng tốt bởi chính con người.

Tương lai

Ngoài việc cho thấy rằng sửa chữa chương trình là cạnh tranh của con người, dự án Repairnator đã cung cấp rất nhiều thông tin về lỗi và tích hợp liên tục, và về những thiếu sót hiện tại của nghiên cứu sửa chữa chương trình, được trình bày trong [7].

Chúng ta hãy tập trung vào một điểm đặc biệt, câu hỏi về sở hữu trí tuệ. Vào ngày 3 tháng 5 năm 2018, Repairnator đã tạo ra một bản vá tốt cho nhật thực / ditto của dự án GitHub. Ngay sau khi đã đề xuất bản vá, một trong những nhà phát triển đã yêu cầu chúng tôi chỉ có thể chấp nhận các yêu cầu kéo đến từ những người dùng đã ký Thỏa thuận cấp phép cộng tác viên của Eclipse. Chúng tôi đã rất bối rối vì một bot không thể ký hợp đồng về mặt thể chất hoặc đạo đức và có lẽ không được quyền làm như vậy. Ai sở hữu tài sản trí tuệ và trách nhiệm của một đóng góp bot: người vận hành robot, người thực hiện bot hoặc người thiết kế thuật toán sửa chữa? Đây là một trong những câu hỏi thú vị được phát hiện bởi dự án Repairnator.

Chúng tôi tin rằng Repairnator định trước một tương lai nhất định về phát triển phần mềm, nơi các bot và con người sẽ hợp tác trơn tru và thậm chí hợp tác trên các tạo phẩm phần mềm.

Bạn muốn tham gia cộng đồng Repairnator? Để nhận được tin tức thường xuyên về Repairnator, hãy bắn email tại Repairnator.subscribe@4open.science!

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

Trong các phương tiện truyền thông:

  • Cuộc đời bí ẩn của Luc Esape, người sửa lỗi ngoại cỡ. Bí mật lớn của anh ấy? Anh ấy không phải là con người (Thomas Claburn, The Register)

Người giới thiệu

  • [1] J. R. Koza (2010) Kết quả cạnh tranh của con người được tạo ra bởi lập trình di truyền. Lập trình di truyền và các máy có thể tiến hóa 11 (3 Hay4), trang 251 Than284. Trích dẫn: .
  • [2] C. Lebeuf, M. D. Storey và A. Zagalsky (2018) Các bot phần mềm. Phần mềm IEEE 35, trang 18 1823. Trích dẫn bởi: Sửa chữa tự động và tích hợp liên tục.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan và M. Monperrus (2016) Tự động sửa chữa các lỗi thực sự trong Java: một thử nghiệm quy mô lớn trên bộ dữ liệu Defects4j. Kỹ thuật phần mềm thực nghiệm, trang 1 lồng29. Trích dẫn bởi: Khả năng cạnh tranh của con người,.
  • [4] M. Monperrus (2017) Sửa chữa phần mềm tự động: Tài liệu tham khảo. Khảo sát tính toán ACM. Trích dẫn bởi: Sửa chữa tự động và tích hợp liên tục,.
  • [5] A. Murgia, D. Janssens, S. Demeyer và B. Vasilescu (2016) Trong số các máy: Tương tác giữa người và bot trên mạng xã hội. Trong Kỷ yếu của Hội nghị CHI 2016 tóm tắt về các yếu tố con người trong các hệ thống máy tính, trang 1272 Ảo1279. Trích dẫn bởi: Năng lực cạnh tranh của con người.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues và Y. Brun (2015) Liệu phương pháp chữa bệnh có tệ hơn bệnh? quá mức trong sửa chữa chương trình tự động. Trong Kỷ yếu của Cuộc họp chung lần thứ 10 năm 2015 về các nền tảng của Kỹ thuật phần mềm, trang 535. Liên kết ngoài: Tài liệu được trích dẫn bởi: Khả năng cạnh tranh của con người.
  • [7] S. Urli, Z. Yu, L. Seinturier và M. Monperrus (2018) Làm thế nào để thiết kế một chương trình sửa chữa Bot? Hiểu biết sâu sắc từ Dự án Repairnator. Trong ICSE 2018 Hội nghị quốc tế lần thứ 40 về Kỹ thuật phần mềm, Theo dõi kỹ thuật phần mềm trong thực tế, Liên kết ngoài: Liên kết được trích dẫn bởi: Thành tựu thám hiểm, Tương lai.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta và S. Panichella (2017) Câu chuyện về CI Build Thất bại: Nguồn mở và một quan điểm tổ chức tài chính. Trong hội nghị quốc tế về bảo trì và phát triển phần mềm, được trích dẫn bởi: Sửa chữa tự động và tích hợp liên tục.