Bug Localization Based on Code Change Histories and Bug Reports

Presentation on theme: "Bug Localization Based on Code Change Histories and Bug Reports"— Presentation transcript:

1 Bug Localization Based on Code Change Histories and Bug Reports

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

3 Introduction

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

5 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 함

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

7 Background

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

9 Background (Bug Reports)
Bug Zilla

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

11 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

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

13 Approach

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

15 Approach (BLIA)

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

17 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 등이 포함되 기 때문에 이런 구조화된 정보는 결과 (순위가 매겨진 파일들)의 정확도를 향상시킴

18 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

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

20 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의 두개의 쿼리로 구분함

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

22 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’의 수정된 소스 파일임 버그 리포트의 관련성 점수

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

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

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

26 Evaluation

27 Evaluation (Subject Project)

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

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

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

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

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

33 Results and Discussion

34 Results and Discussion (best parameter - α and β )

35 Results and Discussion (best parameter – k )

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

37 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.

38 Conclusions

39 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.