[논문 리뷰] How to Design a Program Repair Bot? Insights from the Repairnator Project

Simon Urli, Zhongxing Yu외 2명|arXiv (Cornell University)|2018. 11. 24.

Software Testing and Debugging Techniques참고 문헌 34인용 수 46

한 줄 요약

이 논문은 실패를 모니터링하고 버그를 재현하며 수리 도구를 실행하고 패치를 보고하는 CI 기반 프로그램 수리 봇 Repairnator를 제시하며, 11,523개의 실패를 가진 1,609개의 GitHub 프로젝트에서 경험적 결과를 얻고, 15개의 패치를 생성하였으나 모두 과적합으로 간주되었다.

ABSTRACT

Program repair research has made tremendous progress over the last few years, and software development bots are now being invented to help developers gain productivity. In this paper, we investigate the concept of a " program repair bot " and present Repairnator. The Repairnator bot is an autonomous agent that constantly monitors test failures, reproduces bugs, and runs program repair tools against each reproduced bug. If a patch is found, Repairnator bot reports it to the developers. At the time of writing, Repairnator uses three different program repair systems and has been operating since February 2017. In total, it has studied 11 317 test failures over 1 609 open-source software projects hosted on GitHub, and has generated patches for 17 different bugs. Over months, we hit a number of hard technical challenges and had to make various design and engineering decisions. This gives us a unique experience in this area. In this paper, we reflect upon Repairnator in order to share this knowledge with the automatic program repair community.

연구 동기 및 목표

• CI 워크플로우와 통합된 자율 프로그램 수리 봇의 엔드투엔드 설계를 탐구한다.
• Repairnator의 재현 능력과 대규모 오픈 소스 자바 프로젝트에 걸쳐 패치를 생성하는 능력을 경험적으로 평가한다.
• Repairnator 구축 및 운영에서 마주친 실무적 엔지니어링 결정과 도전과제를 식별하고 향후 수리 봇에 대한 실행 가능한 권고를 도출한다.
• 프로그램 수리 연구와 산업 현장 실천 사이의 간극을 메우기 위한 데이터와 인사이트를 제공한다.

제안 방법

• CI 빌드 분석, 버그 재현, 패치 합성의 3단계 Repairnator 파이프라인을 기술한다.
• 재현된 실패에 대해 NPol, NPEFix, Astor의 세 가지 수리 시스템을 사용하여 패치를 생성한다.
• Maven 기반 빌드와 고립된 의존성 관리로 로컬에서 실패를 재현한다.
• 개발자에게 보고하기 전에 패치를 인간 검수자가 패치를 점검하도록 한다.
• 오픈 사이언스 및 향후 연구를 지원하기 위해 패치와 재현/수리 로그를 아카이브한다.

실험 결과

연구 질문

• RQ1 현실 세계의 CI 환경에서 자율 프로그램 수리 봇의 실행 가능성과 효과는 어떠한가?
• RQ2 대규모 실무에서 버그 재현 및 패치 합성의 경험적 특성(양, 성공률, 실패 유형)은 어떠한가?
• RQ3 종단 간 수리를 제한하는 주요 도전 과제(예: 과적합, 재현성)는 무엇이며 설계 선택이 이를 어떻게 해결하는가?
• RQ4 향후 프로그램 수리 봇 개발을 안내하기 위한 실행 가능한 권고는 무엇인가?

주요 결과

• Repairnator는 2017년 2월부터 2018년 1월까지 1,609개의 오픈 소스 자바 프로젝트에서 11,523개의 CI 실패를 대상으로 작동했다.
• 패치는 15개의 서로 다른 버그에 대해 생성되었으나 과적합으로 인해 개발자에게 제안되지 않았다(패치가 실패한 빌드를 수정했지만 실제 버그를 수정하지는 못함).
• Repairnator는 11,523개의 실패한 빌드 중 3,551개를 성공적으로 재현했다(30.82%).
• 재현된 버그 중 세 가지 수리 도구를 통해 1,307개의 패치를 생성했으며, 이는 많은 탐색 공간과 테스트 스위트에 적합한 패치가 많았으나 대부분이 과적합임을 시사한다.
• 가장 흔한 실패 유형은 AssertionError와 NullPointerException으로, 상위 10가지 유형에서 전체 실패의 상당 부분을 차지했다(10가지 유형의 합계가 70% 이상).
• 빌드 재현성은 프로젝트에 따라 크게 다르며(druid-io/druid: 62% 재현; prestodb/presto: 19.40%), 이는 수리 잠재력의 프로젝트 차이 변동성을 강조한다.