[논문 리뷰] Large-Scale Manual Validation of Bug Fixing Commits: A Fine-grained Analysis of Tangling.

Steffen Herbold, Alexander Trautsch외 46명|arXiv (Cornell University)|2020. 11. 12.

Software Engineering Research참고 문헌 4인용 수 5

한 줄 요약

이 연구는 버그 수정 커밋 내 4,000줄 이상의 수동 레이블링을 통해, 버그 수정 코드 변경 중 17–32%가 직접적으로 버그를 수정함을 밝혀내었으며, 생산 코드에서는 이 비율이 66–87%로 상승한다. 연구는 높은 수준의 혼선(타이틀링)이 존재함을 확인했으며, 최대 47%의 데이터가 노이즈일 수 있음을 시사하며, 이는 경험적 소프트웨어 공학 연구에서 수동 검증이 잘못된 결과를 방지하기 위해 필수적임을 강조한다.

ABSTRACT

Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective: We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods: We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus. Results: We estimate that between 17\% and 32\% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66\% to 87\%. We find that about 11\% of lines are hard to label leading to active disagreements between participants. Due to confirmed tangling and the uncertainty in our data, we estimate that 3\% to 47\% of data is noisy without manual untangling, depending on the use case. Conclusion: Tangled commits have a high prevalence in bug fixes and can lead to a large amount of noise in the data. Prior research indicates that this noise may alter results. As researchers, we should be skeptics and assume that unvalidated data is likely very noisy, until proven otherwise.

연구 동기 및 목표

• 버그 수정 커밋에서 여러 관심사가 한 번에 처리되는 경우가 얼마나 흔한지, 타이틀링의 진정한 빈도를 이해하기 위해.
• 버그 수정 커밋 내 코드 변경 중 실제로 보고된 버그를 수정하는 데 기여하는 비율을 평가하기 위해.
• 버그 수정으로 간주되는 변경을 분류하는 데서 발생하는 불확실성과 이견을 정량화하고, 분류가 어려운 라인을 식별하기 위해.
• 자동 커밋 분석에 의존하는 기존 경험적 소프트웨어 공학 연구에서 타이틀링으로 인해 유발될 수 있는 노이즈의 정도를 추정하기 위해.
• 수동 검증이 경험적 소프트웨어 공학 연구에서 노이즈를 줄이고 신뢰성을 향상시키기 위해 필수적인 단계임을 주장하기 위해.

제안 방법

• 각 라인을 '버그 수정', '관련 없음', 또는 '모호함'으로 분류하는 데 네 명의 독립된 참여자가 참여한 커뮤니티 기반 수단을 활용함.
• 공동 레이블링: 최소 세 명 이상의 참여자가 동일한 레이블을 선택한 경우에만 해당 라인이 신뢰성 있게 레이블링된 것으로 간주함.
• 실제 버그 수정에 직접 기여하는 비율을 평가하기 위해 생산 코드 파일 내 라인에 집중함.
• 참가자 간 이견이 발생하는 라인(이견이 있는 라인)을 '레이블링이 어려운' 라인으로 분류하여 레이블링의 불확실성을 평가함.
• 사용 사례에 따라 타이틀링으로 인해 잘못 분류될 수 있는 데이터 비율을 측정하여 노이즈 추정치를 계산함.
• 통계적 탄탄함을 확보하기 위해 여러 오픈소스 프로젝트에서 4,000줄 이상을 분석함.

실험 결과

연구 질문

• RQ1 수동 레이블링을 통해 확인된 바, 버그 수정 커밋 내 변경 중 실제로 보고된 버그를 수정하는 비율은 어느 정도인가요?
• RQ2 특히 생산 코드 파일에서 버그 수정 커밋 내 타이틀링은 얼마나 퍼져 있나요?
• RQ3 버그 수정 커밋 내 라인 중 얼마나 많은 비율이 레이팅자 간의 모호함이나 이견으로 인해 레이블링이 어려운가요?
• RQ4 타이틀링은 경험적 소프트웨어 공학 데이터셋에 얼마나 많은 노이즈를 유발하며, 이는 사용 사례에 따라 어떻게 달라지나요?
• RQ5 실제 버그 수정을 식별하는 데 있어 수동 공식 레이블링은 자동 커밋 분석 대비 얼마나 더 신뢰할 수 있나요?

주요 결과

• 버그 수정 커밋 내 모든 코드 변경 중 17%에서 32%가 기반 버그를 직접 수정함.
• 생산 코드 파일로 제한할 경우, 버그를 수정하는 변경 비율은 66%에서 87%로 크게 증가함.
• 버그 수정 커밋 내 약 11%의 라인이 레이블링이 어려운 편이며, 이는 레이팅자 간 이견과 높은 모호성을 시사함.
• 확인된 타이틀링과 레이블링 불확실성으로 인해 일부 사용 사례에서는 최대 47%의 데이터가 노이즈일 수 있으며, 보수적인 하한선로 3%의 노이즈가 존재함.
• 이 연구는 검증되지 않은 커밋 데이터가 타이틀링으로 인해 상당한 노이즈를 포함할 가능성이 높다는 점을 확인하며, 이는 이전 자동화된 연구의 타당성을 도전함.
• 결과적으로, 타이틀링과 검증되지 않은 데이터로 인한 오해를 피하기 위해 경험적 소프트웨어 공학 연구에서 수동 검증이 필수적임을 강조함.