Bug Localization Based on Code Change Histories and Bug Reports

Slides:



Advertisements
Similar presentations
1 텍스트 마이닝 기법을 이용한 소셜 미디어 데이터 분석 송민 연세대학교 문헌정보학과 Text and Social Media Mining (TSMM) Lab.
Advertisements

텍스트 마이닝을 활용한 신문사에 따른 내용 및 논조 차이점 분석 연세대학교 문헌정보학과 송민
“ PPT WORLD PowerPoint template, you can become an expert. Your wishes for the successful presentation. Our company wishes to own a successful presentation.
김예슬 김원석 김세환. Info Northcutt Bikes Northcutt Bikes The Forecasting problem The Forecasting problem The solution 1~6 The.
What Opinion mining? Abstract 이 논문에서는... 1.Different granularity levels (word, sentence, document) 2. Discussion about terms of challenges 3. Discussion.
Predicting User Interests from Contextual Information
3. C++와 객체지향 C++ 코딩 방법 객체 단위로 2 개의 파일 인터페이스 파일 구현파일
Hourglass-A library for incremental processing on Hadoop
Signal-to-Noise Ratio
Development and Initial Validation of Quality-of-Life Questionnaires for Intermittent Exotropia Ophthalmology 2010;117:163–168 Pf. 임혜빈 / R2 정병주.
Journals & Conferences
*노동문제 * -비정규직 유효림 박지희 전향숙 황연두.
ERP(Enterprise Resource Planning)
한국통신 멀티미디어연구소 김 영 환 인터넷 정보검색 제 10회 한글 및 한국어 정보처리 학술대회 인간과 기계와 언어 한국통신 멀티미디어연구소 김 영 환
전자정부 서비스 운영을 위한 SLA 적용 방안 남기찬 교수 서강대학교 아웃소싱연구센터 (
Homework #1 연관규칙, 분류, 클러시트링의 세 가지 마이닝 방법에 대해, 교재 및 강의노트에 나오지 않는 사례를 각각 1개씩 드시오. 교재 p. 86의 2번 문제 교재 p. 91의 19번 문제 문서는 각 단어의 빈도를 조사하여 문서 벡터로 나타낼 수 있다. 문서.
English Communication 2
Software development #5: Version Control System
Chapter 32 Analyzing Web Traffic
Internet Computing KUT Youn-Hee Han
12. 데이터베이스 설계.
HEC-HMS HEC-HMS를 이용한 강우-유출해석 담당교수명 : 서 영 민
This is our standard presentation Cover slide; the images used here are meant to provide a quick, pleasing representation of ProQuest content areas. The.
ProQuest Nursing & Allied Health Source
ProQuest Nursing & Allied Health Source
포항공과대학교 COMPUTER VISION LAB. 석박통합과정 여동훈
Accelerometer Data Collection and Preprocessing
6장. 물리적 데이터베이스 설계 물리적 데이터베이스 설계
PHP + Eclipse + Google Code를 이용한 개발환경
Technological Forecasting & social change(2014)
Information Retrieval (Chapter 5: 질의연산)
학업 성취도에 영향을 미치는 요인.
for Robust Facial Landmark Localization
운영체제 (Operating Systems)
INTRODUCTION TO WESTLAW NEXT V.1.0
ProQuest Dissertations Unlimited
이종효 이슬기 강민수 송강산 이해인 은혁진.
과학기술 문서작성 안 재 형.
Data Mining Final Project
Changing Objectives of Optimization
JCR 이용자 매뉴얼.
G 정동주 버그 로컬라이제이션에서 잠재적인 편향을 갖게하는 파일및 요소에 대한 논문
대리 이 강 헌 (Andrew Lee) / 02) (235) /
Index - Introduction - Preliminaries and Example - Approach
제 8 장 객체지향 데이타베이스와 데이타베이스의 새로운 응용 분야
정보 추출기술 (Data Mining Techniques ) : An Overview
정보 검색 연구 내용 및 연구 방향 충남대학교 정보통신공학부 맹 성 현 데이타베이스연구회 2000년도 춘계 튜토리얼
ERP 시스템의 구축 ERP 시스템의 구축 기업이 ERP 시스템의 도입을 검토하는 단계에서부터 실제 업무에 적용하고 사후관리에 들어가는 단계에 이르기까지 시스템을 효과적으로 사용하기 위해 필요한 모든 활동.
Course Guide - Algorithms and Practice -
Journal Citation Report
소프트웨어 종합설계 (Software Capstone Design)
McGraw-Hill Technology Education
9장 아웃소싱 보안구조 신수정.
사용자 경험 측정 (Measuring User Experience)
McGraw-Hill Technology Education
시스템 분석 및 설계 글로컬 IT 학과 김정기.
2015 한국연구재단 글로벌박사 양성사업 변경사항 안내
소프트웨어 형상관리: 목차 변경 및 형상관리의 기초 개념 형상항목 확인 및 버전관리 변경관리 감사 및 감사보고 99_11
Search Engine: Course Overview
CHAPTER 04 파일 설계(FiLE Design).
의료관리 연구방법론 강의 소개 - 지역보건 기획과 평가
고급 정보 검색 1. 개 요.
MR 댐퍼의 동특성을 고려한 지진하중을 받는 구조물의 반능동 신경망제어
소프트웨어 종합설계 (Software Capstone Design)
우리는 오늘도 동영상을 봅니다. 7조 (김예지, 민지선, 제해솔).
Progress Seminar 신희안.
ProQuest Dissertations Unlimited
USER GUIDE EBSCO Korea CUSTOMERFOCUSEDCONTENTDRIVEN.
Progress Seminar 이준녕.
CAJ – KNS55 (China Academic Journals)
Presentation transcript:

Bug Localization Based on Code Change Histories and Bug Reports

Author Klaus Changsun Youm June Ahn Jeongho Kim Eunseok Lee 성균관대학교 소프트웨어공학 연구실

Introduction

Introduction - 출시된 소프트웨어의 결함은 유지 보수 단계에서 개발팀에 보고됨 - 정확한 Bug Localize에는 많은 비용과 시간이 소요됨 - Bug Localize는 개발자에게 어렵고 시간이 많이 소모되는 행위임 - 자동으로 버그를 찾는 것은 버그 해결시간을 줄이고 소프트웨어 유지보수 비용을 절감함

Introduction - 지금까지 feature location, developer identification, impact analysis 를 위해 searching text domain 을 소프트웨어 유지보수에 적용시킴 - Information retrieval (IR) 기반의 Bug Localize 기술이 비용이 상대적으로 낮고 버그를 찾는 정확도가 높아 주목을 받고 있음 - 이러한 IR 접근 방식에서는 Bug Report를 쿼리(검색 조건)로서 처리하며 소프트웨어의 소 스 파일을 문서 컬렉션 (검색 대상) 으로 구성함 - 정확도를 높이기 위해 이전의 버그와 유사도 분석, 소스파일의 정보, Version change history, Stack trace analysis 등이 여러 조합으로 사용됨 버그 리포트를 통해 소스파일을 검색할 수 있도록 Indexing 함

Introduction - 본 논문에서는 BLIA 라는 IR 기반의 Bug Localize 방법을 제안함. BLIA는 Bug Report, Structured information of source files , Source code change histories 을 Stack trace 을 활용하여 Bug Localize 의 정확도를 높일 수 있는 방법을 제안함 - 각 정보가 어느정도 분석결과에 영향을 미치는지 확인하며, Stack-trace analysis 가 가장 영 향을 크게 미치는 정보임을 확인 - 소프트웨어의 규모가 큰 경우 계산을 할 때 시간등의 비용이 크게 증가하게됨. 그러나 본 논문에서는 연관성이 높은 소스 파일을 우선적으로 분석하여 정확도를 떨어뜨리지 않으면 서 계산 시간을 크게 줄이는 접근 방식을 제안함

Background

Background (Bug Reports) - Bug Report는 개발자가 버그가 발생한 위치 (Bug Localize)를 찾는 중요한 단서이며 버그 ID, 요약, 설명, 보고 날짜, 수정 날짜, 상태 등의 정보가 기술되어 있음 - 특정 버그 보고서에는 예외가 발생한 Stack-trace가 포함되어 있으며 이 정보는 Bug Localize를 위한 중요한 정보임. - 비슷한 Bug Report가 Bug Repository에서 발견되면, 수정된 파일은 유사한 버그를 해결하고 소프트웨어를 수정할 후보가 됨

Background (Bug Reports) Bug Zilla

Background (Information Retrieval based Bug Localization) - Information Retrieval based Bug Localization에서 소스 코드 파일은 검색할 문서 컬렉션 (검 색 대상)으로 구성하고 Bug Report는 쿼리(검색 조건) 로서 사용됨. Bug Report를 통해 의심 스러운 소스파일에 우선순위를 매김. - IR 방식에서의 사전처리는 Text Normalization, Stopword Removal, Stemming 3단계로 처리 가 됨. - Bug Report와 소스파일은 사전 처리를 통해 유사성을 계산함.

Background (Information Retrieval based Bug Localization) - Bug Report 및 소스 파일이 사전처리 되면 Term Frequency (TF, 용어가 사용된 횟수) 와 Document Frequency(DF, 용어가 사용된 문서의 갯수)와 같은 다양한 통계를 수집하며 이를 통해 Indexing 함 (문서 컬렉션 구성) - IDF 는 Inverse Document Frequency를 말하며 Bug Report와 소스 파일간의 관련도와 유사도 를 계산하는데에 사용됨 - Bug Report와 소스파일은 TF 와 IDF를 통해 벡터값으로 표현되며 성능 향상을 위해 Zhou et al.의 논문에서 제안된 Vector Space Model(rVSM)을 사용함 Where should the bugs be fixed? More accurate information retrieval-based bug localization based on bug reports Where should the bugs be fixed? More accurate information retrieval-based bug localization based on bug reports

Background (Code Change History) - Software configuration management(SCM) 시스템은 소프트웨어 개발의 중심에 자리잡고 있으며 일반적으로 개발팀은 Git, SVN, Mercurial등을 활용하여 버전을 관리함 - 이때 남은 기록은 소스파일의 결함을 추적할때 필요한 지표중 하나이며 이를 통해 의심스 러운 버그 파일을 발견하며 Bug Report를 통해 버그를 수정함

Approach

Approach (BLIA) - Bug Report에는 날짜, 시나리오, 제품버전등이 포함되며 버그가 발생할 시 Stack-trace를 통 해 Bug Report를 제출함 - Stack-trace는 버그가 있는 소스파일과 코드 라인을 특정하는 중요한 단서이며 코드 라인 은 Bug Report의 Method Name이나 Class Name을 통해 추적이 가능함 - BLIA 는 IR 모델로 rVSM을 활용하여 Bug Report 분석을 기반으로 하는 기술을 구축하며 소 스파일의 정보, Stack-trace 분석 정보, Commit 메시지를 통합적으로 분석하여 결과를 도출 함

Approach (BLIA)

Approach (BLIA) H2 Database 5. 이전 4단계에서 분석한 점수를 통합하여 의심되는 파일에 순위를 매겨 제시함 4. Bug Report가 보고 되기 전의 최근 커밋을 분석하여 커밋 로그 점수(CommScore) 를 계산 2. 새 Bug Report와 유사한 기존의 Bug Report를 검색하여 유사성 점수(SimiBugScore)를 계산 3. Stack-trace가 있는 경우 소스파일의 정보를 분석하고 의심도 (StraceScore)를 계산 1. Bug Report와 소스 파일을 통해 관련성 점수 (StructVsmScore) 계산

Approach (Analyzing Structured Source File Information) - 소스 코드 파일은 문서 컬렉션이며 Bug Report는 검색 쿼리임. 소스 파일을 하나의 문서로 서 취급함에 따라 파일의 Term이 추출되며 Vector of Term을 생성함 - 소스 코드를 단순한 Text File로 취급하는 대신 SourceFileIndexer는 파일을 구문 분석하여 AST를 추출하고 이를 통해 Class Name, Method Name, Variable Name, Comments로 분할함 - Bug Reports에는 Log Message나 Stack-trace에 의해 Class Name, Method Name 등이 포함되 기 때문에 이런 구조화된 정보는 결과 (순위가 매겨진 파일들)의 정확도를 향상시킴

Approach (Analyzing Structured Source File Information) - AST의 모든 식별자는 Camel Case Splitting을 통해 분할하며, 분할된 단어 뿐 아니라 분할 전 의 전체 식별자 (Full Indentifier)로 Indexing 함. 이러한 방법은 단순한 확장에 불과하나, Saha et al. 의 논문에서 효과적인 방법인 것으로 증명됨 - 사전 처리에서 Stopword를 제거하는 동안 소스파일에서 자주 사용되지만 의미없는 단어 또한 제거함 (e.g. “args”, “param”, “string”). 패키지의 이름이나 프로젝트 이름 또한 제거됨 (e.g. AspectJ 프로젝트 에서 “aspectj”) - 주석은 Javadoc 태그나 html 태그를 포함할 수 있으므로 해당 태그들을 제거하여 정확성을 향상시킴. - BugReport도 이와 유사한 사전 처리 작업을 거친 뒤, BugRepoIndexer를 통해 쿼리로 작성됨 Improving bug localization using structured information retrieval

Approach (Analyzing Structured Source File Information) - SourceFileAnalyzer는 각 용어의 TF 및 IDF를 분석 한 다음 각 소스 파일 및 버그 보고서의 벡 터 값을 계산함 - 소스파일 (f)와 Bug Report (b)는 벡터 𝑓 와 𝑏 로 표현되고 { 𝑥 1 , …, 𝑥 𝑚 } 과 { 𝑦 1 , …, 𝑦 𝑛 }은 소스 파일과 Bug Report에서 추출된 Term이며 m과 n은 추출된 Term의 갯수로 가정함 𝑓 𝑡𝑑 = 문서 d에 있는 용어 t의 빈도 수 𝑑 𝑡 = 용어 t가 포함된 문서의 수

Approach (Analyzing Structured Source File Information) - Bug Locator 는 Classic VSM과 Document Length Score - g (#term)를 결합함. BRIA에서는 계산 을 위해 식 (6)과 같은 수정된 rVSM 모델을 제안함 - BLUiR (Saha et al. 의 논문에서 제안한 소스파일의 정보를 구조화 하는 방법) 에서는 소스파 일을 Class, Method, Variable, Comments 4개의 문서로 분리하고 Bug Report를 Summary 와 Description의 두개의 쿼리로 구분함

Approach (Analyzing Structured Source File Information) - 𝑓 𝑝 는 소스 파일의 구조화된 정보를 나타내는 벡터, 𝑏 𝑝 는 Bug Report의 필드를 나타내는 벡 터 - 𝑓 𝑝 와 𝑏 𝑝 의 관련성은 식 (4)와 같이 코사인 유사성으로 계산하며 관련성 점수는 식(5)로 계 산. 𝑤 𝑓𝑝 는 주석과 코드 본문의 가중치를 계산한 것이며 주석은 50%, 본문은 100%의 가중치 를 둠

Approach (Analyzing Similar Bug Reports) - BugRepoIndexer 는 Bug Report를 분석하여 데이터 베이스에 Indexing을 하며 BugRepoAnalyzer 는 기존 Bug Report와의 유사성을 분석함 - 기존에 보고된 Bug Report를 통해 수정된된 파일이 새로 보고된 Bug Report의 버그를 수정 할 수 있다고 가정함 - B는 기존에 보고되어 수정된 Bug Report와 새로 보고된 Bug Report이며 b’은 B에서 기존에 보고되어 수정된 Bug Report이며 b’. 은 b’의 수정된 소스 파일임 버그 리포트의 관련성 점수

Approach (Analyzing Stack-trace Information In The Bug Report) - b.strace.import는 b.strace의 가져온 파일 세트 - BugRepoIndexer는 정규 표현식을 사용하여 스택 추적의 모든 파일 이름을 추출하며 StackTraceAnalyzer는 파일을 분석 한 호출되는 다음 파일에 대한 StraceScore를 계산함. 버그 리포트의 관련성 점수

Approach (Analyzing Code Change History Information) - CommitLogCollector는 커밋 로그 메시지와 커밋 된 파일을 SCM에서 수집하며 ScmRepoAnalyzer는 Bug Report가 보고되기 전의 관련 커밋 로그에 대해 분석함 - 커밋 로그는 정규표현식 (. * fix. *) | (. * bug. *) 과 일치하는 구문만 분석되며 이 정규 표현 식은 “수정”이나 “버그” 가 포함된 커밋 로그만을 가져옴. 매개변수 k는 커밋 로그의 범위를 나타내며 지난 k일의 기록을 가져옴. c는 커밋으로 C는 지난 k일동안의 커밋 로그 집함임 𝑑 𝑐 는 커밋 c 이후의 새로운 Bug Report가 보고 되기 까지의 경과 일수 임. 버그 리포트의 관련성 점수

Approach (Combining All Analyzed Scores) - BLIA 모듈은 앞서 분석된 4개의 점수를 통합하여 보고된 Bug Report와 연관된 파일들을 순 위를 매겨 산출함 - α 와 β 는 각 점수의 영향률임 (임의의 가변값) 파일 관련 점수, 버그 관련 점수 와 stack-tarce 점수를 합한 것이 c(f,b,a)

Evaluation

Evaluation (Subject Project)

Evaluation (Subject Project) - Zhou et al. : BugLocator - Wong et al. : BRTracer - Saha et al. : BLUiR - S. Wang, and D. Lo : AmaLgam

Evaluation (Evaluation Metrics) - 평가를 위해 Top N Rank, Mean Average Precision (MAP), Mean Reciprocal Rank 을 사용함 - MAP 및 MRR은 IR에서 널리 사용되는 Metric 임 - Top N Rank 는 IR 기반의 Bug Localization 을 평가할때 널리 사용됨

Evaluation (Evaluation Metrics – Top N Rank) - Top N Rank 는 산출한 버그가 발견된 파일의 순위가 (1, 5, 10) 인 Bug Report의 개수를 산출 함 - 예를들어 어떤 특정 Bug Report를 통해 파일을 산출한 뒤, 실제로 수정된 파일이 N 랭크 이 내에서 포함되면 N랭크에서 성공적으로 버그 파일을 찾은 것으로 간주함 - Top N Rank 는 초기 정확도에 초점을 둠

Evaluation (Evaluation Metrics – Mean Average Precision ) - MAP은 IR은 Ranking Approach 에서 가장 일반적으로 사용되는 Metric임 - 순위가 매겨진 모든 파일을 고려하며 모든 쿼리의 평균 밀도값의 평균임 - k는 파일의 순위이며 d는 파일의 수. pos(k)는 k 순위의 파일이 버그가 있던 파일인지에 대 한 이진값이며 P(k)는 주어진 k순위 내에서 버그 파일이 있는지에 대한 정확도임

Evaluation (Evaluation Metrics – Mean Reciprocal Rank ) - MRR은 쿼리 집합 Q의 결과에 대한 순위의 평균임 - Top N Rank 는 전반적인 품질은 고려하지 않으며 MAP, MRR은 산출된 파일의 순위를 전반 적으로 평가하며 값이 클수록 정확도가 높음

Results and Discussion

Results and Discussion (best parameter - α and β )

Results and Discussion (best parameter – k )

Results and Discussion - 대규모 프로젝트의 경우 수천개의 소스파일과 Bug Report가 있기 때문에 분석시간이 크게 증가함 - 순위가 낮은 파일은 제외하고 순위가 높은 파일만 계속해서 활용하면 분석시간을 크게 줄 일 수 있음

Results and Discussion (Effects of each analyzed scores) - When excluding the stack-trace, the relevance score of the bug report and the source file (StructVSMScore) are the most influential score. -When including the stack-trace, the suspicious score (StraceScore) are the most influential score.

Conclusions

Conclusions - Recently, researchers have proposed various approaches for automatic bug localization by using information retrieval and data mining. - BRIA analyze texts and stack traces in bug reports, structured information of source files and source code change history, which are used differently in previous researches. - BRIA also propose an approach to reduce computing time and resources of integrated analysis when the count of the source files in the subject project is large. - Removal of project keywords, which are frequently used but meaningless, is also a method to improve the accuracy of IR-based bug localization. - Results show that accuracy is significantly improved further.