自動分析軟件缺陷報告間相關性的方法研究

摘 要:針對缺陷報告相關性分析的研究主要采用計算其文本信息相似度的方法使其查全率和查準率并不理想，提出了一種將結構化信息相似度與文本信息相似度計算相結合的方法，即同時提取出缺陷報告中的文本信息(包括主題和詳細描述)以及結構化信息(包括補丁、異常堆棧和代碼片段)，從缺陷外部表現和內部特征兩個角度共同衡量缺陷報告間的相關性。通過對Eclipse系統中的1 000個缺陷報告進行實驗，結果顯示，增加結構化信息相似度計算，可以有效地將缺陷報告間相關性分析的查準率和查全率均提高到90%左右。

關鍵詞:相關缺陷報告; 結構化信息; 相似度

中圖分類號:TP311.5文獻標志碼:A

文章編號:1001-3695(2010)06-2134-06

doi:10.3969/j.issn.1001-3695.2010.06.040

Approach to automatic analysis for relevance among software bug reports

LI Nan， WANG Xiaobo， LIU Chao

(Software Engineering Institute， Beihang University， Beijing 100191， China)

Abstract:The approaches to the relevance analysis of bug reports were studed based on natural language processing technology， but the precision and recall were hard to improve. The paper proposed the new approach based on both of structure information (including patches， exception stack and code fragments). With these information， the relevance of bug reports detected by using the similarity analysis of the structure and text information. It used 1 000 bug reports form Eclipse to test， and the experimental result shows that it can effectively improve precision rate and recall rate to about 90% by adding similarity analysis of the structure information.

Key words:related bug reports; structure information; similarity

0 引言

隨著軟件項目規模的不斷增長，使得維護工作日趨復雜。在軟件生命周期中，通過對其進行不斷的測試會產生各種各樣的缺陷報告，很多軟件系統直接基于這些缺陷報告進行軟件維護工作[1]。存儲這些缺陷報告并進行合理管理的系統即為軟件缺陷管理系統，如常用的開源軟件缺陷管理系統Bugzilla。Bugzilla能夠對軟件缺陷進行具體記錄，包括缺陷狀態跟蹤及缺陷修改過程等。它允許用戶和開發或測試人員提交缺陷報告，由缺陷分流人員將缺陷報告分配給相關開發人員，由他們對缺陷進行修復，通過此過程保證軟件系統的質量[2]。Bugzilla中定義的缺陷報告包括一些預定義內容，如缺陷主題、缺陷描述、缺陷優先級、嚴重級、產品版本號、所屬構件等。除此之外，開發人員或用戶還可以針對缺陷進行討論和添加附件信息，如補丁、異常堆棧或代碼片段等。

在軟件開發和不斷變更的整個生命周期中，將產生大量的缺陷報告，其中有許多報告是彼此相關的，甚至是重復的。例如Mozilla系統在2003—2005年產生的約27 000個缺陷報告中，重復缺陷報告約占36.3%;Eclipse系統在2001—2007年中共產生約213 000個缺陷報告。在這些缺陷報告中，約30%的缺陷報告是具有相關性的，其中約60%是重復缺陷報告。缺陷報告間的相關性主要體現在對缺陷的外部表現、產生原因、代碼環境或解決方法等方面描述的相似性。這些相關的缺陷報告將被分流人員或開發人員標志為“dependson”或“see bug”，以便于開發人員根據這些關聯，將相關的缺陷報告進行統一的分析和修改，以避免對該缺陷的修復而引起其他新的缺陷。缺陷的相關性分析也可以提供新報告缺陷的擴展信息或修復該缺陷的參考方法[3]。除此之外，還有助于將缺陷報告分配或抄送給相關開發人員。

傳統的缺陷報告相關性分析是通過人工檢測來完成，而大型軟件系統在整個生命周期中將產生相當數量的缺陷報告，例如Eclipse系統，在2007年中向Bugzilla提交了約42 000個缺陷報告，平均一天產生115個缺陷報告。在數據龐大的缺陷歷史記錄中分析缺陷報告間的相關性，需要耗費大量的時間和精力，所以自動分析軟件缺陷報告間的相關性具有重要意義。

1 相關的研究現狀

缺陷管理系統可以將軟件測試過程中發現的缺陷、缺陷信息及缺陷發生的背景信息全面詳細地記錄下來，構成缺陷信息數據倉庫。分析挖掘已有缺陷中的信息及其相關性，有助于指導軟件測試工作，對提高缺陷發現率和改善軟件質量是一種行之有效的方法[4]。

當前國內外對于缺陷報告的分析研究主要包括:

a)對軟件缺陷數據的分析。軟件開發過程中的歷史信息為缺陷分析提供了很有價值的經驗數據，需要利用有效方法對這些數據進行如下缺陷分析[5]:

(a)將缺陷報告中的屬性值按照一元數據和多元數據進行分析，并說明缺陷數據分析對軟件質量保證、項目管理和過程改進具有重要意義[6]。

(b)通過文本挖掘。統計分析等方法，對軟件缺陷預處理、缺陷分類和缺陷數據挖掘[7]。

b)軟件缺陷分類的研究如下:

(a)缺陷分類是缺陷管理的基礎。當前國內研究主要使用正交缺陷分類，并在正交缺陷分類的基礎上制訂出適合軟件組織自身情況的軟件缺陷分類方法[8]。

c)自動檢測重復缺陷報告如下:

(a)通過缺陷報告的主要屬性和文本描述構造分類器，對Mozilla系統缺陷報告進行實驗，實驗結果顯示該方法可以自動過濾8%的重復缺陷報告[9]。利用缺陷報告間的文本相似度進行文本聚類[10]，并通過為分流人員提供候選分配人員列表的方式實現合理分配缺陷報告，實驗結果顯示查全率和查準率均為70%左右[11]。

(b)通過缺陷報告文本描述和缺陷執行信息(如缺陷重現步驟等)兩者來共同檢測重復缺陷報告，并對Firefox系統的缺陷報告進行實驗，實驗結果顯示，對比僅采用文本相似度分析過濾43%～72%的重復缺陷報告，增加缺陷執行信息分析可以過濾67%～93%的重復缺陷報告[12]。

d)自動分流缺陷報告。通過提取缺陷報告的文本描述、組件、操作系統、硬件、軟件版本、相關代碼所屬的開發人員等八個屬性來構造一個候選器，為分流人員提供可能適合修復該缺陷的開發人員候選列表[13]，并對Eclipse系統缺陷報告進行實驗，結果顯示該方法查準率達到80%左右，幫助分流人員對缺陷報告進行合理分配[14]。

綜上所述，當前對于缺陷報告間相關性的研究主要以計算缺陷報告間的文本相似度為主，并取得了顯著的研究成果，但由于查全率和查準率并不十分理想，造成了一定的局限性。

本文在當前研究的基礎上，提取缺陷報告中的另一項有價值的信息——結構化信息，包括補丁、異常堆棧和代碼片段。這項信息存儲于附件列表或嵌套于文本描述中。通過統計，含有這些信息的缺陷報告具有相當數量，例如Eclipse系統2001—2007年中提交的約213 000個缺陷報告中，含有結構化信息的缺陷報告約占35%左右，補丁信息約占16%，異常堆棧信息約占14%，代碼片段約占5%，這些結構化信息從不同角度記錄了程序中與缺陷報告相關的某些內部特征[15]。

對比文本信息，結構化信息具有以下特點:a)更能反應缺陷的產生原因和代碼環境，而不受自然語言多義性的影響;b)更能反映缺陷內部的本質，而這些可能是文本描述中沒有提到的[16]。本文利用文本相似度分析技術來處理缺陷報告的主題和詳細描述，并結合對缺陷報告中的結構化信息的相似度分析，兩者共同衡量缺陷報告間的相關性。

文本主要貢獻:a)說明僅使用文本信息來分析缺陷報告間的相關性存在局限，本文提取缺陷報告中另一項有價值的信息——結構化信息，包括補丁、異常堆棧和代碼片段;b)利用文本相似度分析技術來處理缺陷報告的主題和詳細描述，并結合對缺陷報告中的結構化信息的相似度分析，通過這兩種相似度從缺陷外部和內部共同衡量缺陷報告間的相關性。c)通過設置不同參數進行實驗，并對結果進行分析比較。

本文通過實例來說明缺陷報告間的相關性以及需要結構化信息相似度與文本信息相似度計算相結合來分析缺陷報告間的相關性的原因，介紹缺陷報告中的結構化信息及其提取方法，文本信息和結構化信息相似度的計算方法，以及如何通過這兩種相似度從缺陷外部和內部來共同衡量缺陷報告間的相關性。

2 相關缺陷報告

在本章中，以Eclipse系統中的相關缺陷報告為例，解釋需要結構化信息相似度與文本信息相似度來共同衡量缺陷報告間的相關性的原因。缺陷報告中的文本信息通常包括缺陷主題和詳細描述兩方面，為簡要起見，在這里僅顯示缺陷主題。

本文定義缺陷報告間的相關性主要包括:a)重復缺陷報告，如缺陷報告#212109和#212114;b)在問題現象、產生原因、代碼環境或解決方法等方面相關的缺陷報告，這種關聯被標志為“dependson”或“see bug”:(a)文本描述相似，如缺陷報告#208821和#211243;(b)文本描述不相似，但結構化信息具有一定相似度，如缺陷報告#188103和#190945。

缺陷報告#212109和#212114是一對已被標志為“duplicate”的重復缺陷報告，兩者的缺陷主題如下:

212109:[Automation][Acceptance]NPEis thrown out when previewing report

212114:[Automation][Regression]NPE is thrown out when preview a report containing a hidden chart

可見兩者具有很多共同詞匯，如“[Automation][Acceptance]”“NPE”“thrown out”等，通過文本相似度分析可以檢測出這對缺陷報告是重復的。

208821 :Change SDK to use individual source bundles

211243 :Migrate org.junit4 to individual source bundle

這兩個缺陷報告的文本描述具有一定的相似度，兩者已被開發人員標志為“dependson”。通過文本相似度分析可以檢測出這種相關性。

188103 :[1.5][compiler] Inappropriate usage of HashSet

190945:[1.5][compiler] failure to compile complex generic code

可見兩者的文本描述不相似，但通過比較兩者的異常堆棧信息，發現是相似的，即兩者產生問題的原因或代碼環境相關。在#188103中，已被分流人員標志出“seebug 190945”。

通過以上相關缺陷報告實例顯示，文本信息和結構化信息對于缺陷報告間的相關性分析同等重要:a)文本信息通常描述缺陷的外部表現，而結構化信息則反映缺陷的內部特征;b)由于自然語言通常包含多義性和不確定性，而結構化信息通常是確定的數據[17]，采用文本信息相似度和結構化信息相似度相結合的方法，從缺陷外部和內部來共同分析缺陷報告間的相關性。

3 缺陷報告間的相關性分析方法

如果新提交的缺陷報告與其他已有缺陷報告存在相關性，開發人員需要根據這些關聯，過濾掉重復缺陷報告，或者對于這些相關的缺陷進行統一的分析和修改，以避免對該缺陷的修復而引起其他新的缺陷。

本章將具體介紹缺陷報告間的相關性的分析方法，包括:a)提取缺陷報告中的結構化信息;b)通過計算缺陷報告間的文本相似度和結構化信息相似度，從缺陷外部和內部來共同衡量缺陷報告間的相關性。

3.1 缺陷報告中的結構化信息及其提取方法

結構化信息大部分以附件形式存儲于缺陷報告中，或嵌套于文本描述中，主要包括補丁、異常堆棧和代碼片段。對于以附件形式存儲的，可直接獲得;對于嵌套于文本描述中的，需要采用相應的方法將它們提取出來[18]。

a)補丁:用來更新原文件或修復問題的一段代碼。通常更新或修改多個文件。以統一的“diff”格式出現，標準格式為UNIX 命令diff uN file1 file2(N為數字，file1、file2為文件名)。結構如圖1所示。

Patch Index:惟一標志每個子補丁區。

Patch Header:包括原文件和新文件的文件名、版本、日期以及Revision Control System (RCS)文件名。

Patch Hunks:描述文件內部的改變。包括一個Hunk Header和多個Hunk Lines。

Hunk Header:原文件被修改的位置，以“@@”作為起始和終止符。

Hunk Lines，即包括加入行:由單一的“+”開始，表示在原始文件的給定位置上加入這些行;刪除行:由單一的“-”開始，表示在原始文件的給定位置上刪除這些行。

補丁信息提取:

(a)首先尋找標志符“Index:”，如果沒有則表示沒有補丁信息;如果僅找到一個，則從“Index:”開始到結束都作為潛在補丁區域;若找到多個“Index:”，則每兩個“Index:”間的信息作為潛在的補丁區域。

(b)在潛在的補丁區域中提取Patch Headers和Hunk Header，每兩個Hunk Header間作為潛在Hunk區域，在其中提取Hunk Lines。

b)異常堆棧:程序執行時所引起的異常列表，用于幫助修復缺陷或定位缺陷產生原因。結構[19]如圖2所示。

它包括:方法調用行:顯示方法名和方法所屬類名，及其在代碼源文件中的行號。異常堆棧信息提取:

(a)采用正則表達式定義常見的異常集合E;

(b)從文本描述中檢測是否含有集合E中的異常，一旦找到，則將其后續行與方法調用行模板進行匹配。

c)代碼片段:描述問題、問題產生的代碼環境或修復問題的一段代碼。結構如圖3所示。

代碼片段信息提取:利用具有程序特性的語句，如條件判斷“if”“else”或賦值語句等，來尋找嵌套于文本信息中的代碼區域。

(a)將類定義(class definition)、方法定義(method definition)，條件判斷、賦值語句等具有程序特性的關鍵詞作為集合K={class， if， else， for， while， switch， “=”，…};

(b)用正則表達式描述方法定義的基本文法格式F;

(c)在缺陷文本描述中尋找是否出現集合K中的關鍵詞，或符合文法格式F的字符串，如果找到，則檢測周圍信息，以發現類定義的區域、方法定義區域或一個程序片段。

綜上所述，采用相應方法對嵌套于文本信息中的補丁、異常堆棧、代碼片段進行檢測和提取，通過隨機抽取Eclipse系統中的10 000個缺陷報告進行實驗，發現該提取方法具有很高的準確率，基于此，可以將結構化信息作為自動分析缺陷報告間相關性的重要因素之一，來展開下一步研究。

3.2 相關缺陷報告檢索方法

當前研究的基本理論:如果兩個缺陷報告是相關的，那么這兩個缺陷報告很有可能是相似的。通過采用信息檢索的方法自動檢測具有相似度的缺陷報告，從而分析缺陷報告間的相關性。

信息檢索研究的主要目標是采用相應算法和模型從信息庫中得到所需信息。這里的信息主要包括自然語言文本信息和結構化信息[20]。

3.2.1 缺陷報告間的文本信息相似度計算

自然語言處理技術主要包括:

a)標記化。通過去掉字母大寫、標點符號、括號等，將一系列詞匯流轉換為標志符流。每個標志符代表一個單詞。

b)提取詞干，相同的詞匯可以不同的語法形式存在。提取詞干的作用在于識別每個詞匯的本質信息。

c)去掉停用詞。停用詞指一些非常普遍使用的詞匯，如“the”“that”“what”等，這些詞沒有特別的含義，對相似度分析作用很小。

d)將文本信息表示為空間向量。將以上操作得到的詞匯基于向量空間模型(vector space model)表示為一個多維矩陣，每一個向量代表一個詞匯[21]。

e)相似度計算。兩個文本間的相似度計算定義為空間向量模型中兩個向量間的余玄值[22]。

用以上方法對缺陷報告中的文本信息進行處理，并計算缺陷報告間的文本相似度。在本文中提取缺陷報告的主題描述和詳細描述作為缺陷報告的文本信息。

缺陷報告文本信息的標記化、提取詞干、去掉停用詞處理:

如缺陷報告#204401的缺陷主題描述:“[Smoke]OutofMemory occurs when preview attached report in Web viewer.”。表1為標記化、提取詞干和去掉停用詞的處理過程。

表1 標記化、提取詞干和去掉停用詞的處理過程

缺陷報告文本信息缺陷主題描述

原文本[Smoke]OutofMemory occurs when preview attached report in Web viewer

標記化smoke outofmemory occurs when preview attached report in Web viewer

提取詞干smoke outofmemory occur when preview attach report in Web viewer

去掉停用詞Smoke outofmemory occur preview Web viewer

注:因為在缺陷報告文本描述中，“attach”和“report”也是普遍出現的詞，所以也作為停用詞處理。

將缺陷報告的主題描述和詳細描述兩項文本信息按照以上過程處理后，分別建立兩個語料庫，每個語料庫中的所有文本構成一個包含n個獨立詞匯的集合，基于向量空間模型，將語料庫中的每個文本表示為一個n維向量v， v[i]表示第i個詞匯的權重，這里一般采用逆詞頻率方法計算詞匯權重[23，24]。

逆詞頻率，在自然語言處理中用于描述詞匯的重要性。它與文本語料庫寬度(即詞匯總數)，和該詞匯出現的次數有關。它基于假設:在文本中出現次數越少的詞，對于文本相似度計算越重要。如果一個詞匯在文本中多次出現，那么該詞對相似度分析影響很小，它的權重值通常被設定得很小。

在實驗中在缺陷報告文本描述的相似度計算中，使用了逆詞頻率作為詞匯權重計算方法，但通過結果顯示，使用逆詞頻率對缺陷報告間相關性分析的結果影響很小。

同一語料庫中的兩個文本向量v1和v2間的相似度定義為余玄相似度:

similarity=cos(θ)=v1#8226;v2|v1|×|v2|

通過以上方法得到缺陷報告間主題描述和詳細描述的相似度后，通過兩者來度量缺陷報告間的文本相似度。

首先分別設定缺陷主題的相似度閾值(TT)和詳細描述的相似度閾值(DT)，并根據這兩個閾值以及缺陷主題的相似度(TS)和詳細描述的相似度(DS)將缺陷報告劃分為三類:

(a)TS和DS分別超過TT和DT的值，即TS≥TT且DS≥DT;

(b)TS和DS都沒有超過TT和DT的值，即TS

(c)TS和DS兩者中有且僅有一個超過其對應閾值，即TS≥TT且DS

以上三種情況下，缺陷報告間文本相似度(TDS)定義為

(TS+DS)2，TS≥TT且DS≥DT或TS

且DS

TS，TS≥TT且DS

DS，DS≥DT且TS

3.2.2 缺陷報告間的結構化信息相似度計算

得到提取出來的三種類型的結構化信息后，通過比較它們的相似度特征來計算結構化信息間的相似度。

1)補丁 以圖2為例，采用以下三項信息作為補丁的相似度特征:

a)以“Index:”作為起始標志符的Patch Index，這項信息通常為被修改或更新的原文件名，如“Index:precisionRectangle.java”;

b)表示源文件被修改位置的Hunk Header，如“@@-182，6 +182，31”;

c)表示源文件被修改內容的Hunk Lines，包括以“+”起始的“加入行”和以“-”起始的“刪除行”。

2)異常堆棧 以圖3為例，本文中選取異常堆棧棧頂的五個調用序列作為異常堆棧的相似度特征。

3)代碼片段

(a)對明確給出代碼片段所屬文件名的，提取其文件名作為相似度特征之一。

(b)對于沒有標志出所屬文件名的代碼片段，提取代碼片段的相關信息，包括包名、類名、接口名、方法名、方法返回值類型、方法參數(參數個數、類型、參數名)等作為相似度特性。如圖4所示的代碼片段示例，獲得其類名“someClass”、方法名“someMethod”和方法返回值類型“void”作為相似度特征。

3.2.3 度量缺陷報告間的相關性

通過以上方法得到了缺陷報告間的文本相似度和結構化信息相似度(對于含有結構化信息的缺陷報告而言)，采用以下方法度量缺陷報告間的相關性:

首先分別設定缺陷報告文本信息的相似度閾值(TDT)和結構化信息的相似度閾值(AT)的值，并根據這兩個閾值以及文本相似度(TDS)和結構化信息的相似度(AS)度量相關性:

缺陷報告間相關， TDS≥TDT或AS≥AT

不相關，TDS

4 實驗及結果分析

為了驗證本文提出的缺陷報告間的相關性分析方法的有效性，本章設計了相應實驗，并對實驗結果進行了分析。

實驗采用Eclipse系統2007年11月和12月提交的1 000個缺陷報告作為實驗數據，首先采用對缺陷報告中的文本信息進行相似度計算來分析缺陷報告間的相關性，得出實驗結果并加以分析。在此基礎上，增加對缺陷報告中結構化信息的提取和相似度分析，通過文本相似度和結構化信息相似度來共同分析缺陷報告間的相關性。

實驗數據:

a)采用的實驗數據是開源軟件Eclipse系統的缺陷報告。由于Eclipse系統包含很多模塊，并被不同類型的用戶所使用，實驗數據集具備了多樣性。

b)分別抽取2007年11月和12月提交的前1 000個缺陷報告，因為太近時期提交的缺陷報告可能存在一些錯誤未被改正。

建立實驗:

實驗1 通過文本相似度分析缺陷報告間的相關性。

對缺陷報告的主題和詳細描述進行文本相似度計算，分別采用以下三種閾值設定來進行實驗，相關性分析結果的查全率和查準率如表2和表3所示。

(a)設定TT=0.60，DT=0.50，相關缺陷相似度閾值為0.55;

(b)設定TT=0.50，DT=0.40，相關缺陷相似度閾值為0.45;

(c)設定TT=0.40，DT=0.30，相關缺陷相似度閾值為0.35。

表2 實驗1查全率結果

方案一方案二

閾值設定(a)(b)(c)(a)(b)(c)

查全率/% 43 61 79 43 6281

注:方案一沒有調整詞匯特征項的權重，方案二采用逆詞頻率作為詞匯特征項的權重。

表3 實驗一查準率結果

方案一方案二

閾值設定(a)(b)(c)(a)(b)(c)

查準率/% 91 84 66 91 8667

方案一沒有調整詞匯特征項的權重，方案二采用逆詞頻率作為詞匯特征項的權重。

通過結果分析得到:方案二比方案一的查全率和查準率相差很少，說明通過逆詞頻率方法設計詞匯權重并不能從根本上提高分析缺陷報告間相關性的準確度。閾值設定(a)雖然使檢索相關缺陷報告的查準率達到了90%以上，但查全率卻比較低，僅有40%左右;而閾值設定(c)雖然使查全率達到80%以上，但查準率卻也降低到60%左右，說明隨著缺陷主題相似度和詳細描述相似度閾值的降低，雖然可以找到更多的相關缺陷從而提高查全率，但同時也將一些實際上并不相關的缺陷報告檢索出來，從而降低了查準率。筆者認為由于某些不相關的缺陷報告的文本描述中存在共有詞匯，或文本描述沒有反映出缺陷的本質特征，造成了缺陷報告相關性分析結果不夠理想。

實驗2在實驗1的基礎上，增加對結構化信息相似度計算來共同分析缺陷報告間相關性。

基于實驗1中表現出的僅用文本信息相似度來分析缺陷報告間相關性的不足，在實驗2中增加了對缺陷報告中的結構化信息(包括補丁、代碼片段、異常堆棧)的相似度(AS)的計算，通過文本相似度和結構化信息相似度來共同分析缺陷報告的相關性。

當文本相似度(TDS)超過了文本相似度閾值(TDT)，或者結構化信息相似度(AS)超過了結構化信息相似度閾值AT，則認為缺陷報告間是有相關性的。分別采用以下三種閾值設定來進行實驗，相關性分析的查全率和查準率結果如表4和表5所示。

(a)設定TT=0.60，DT=0.50，TDT=0.55，AT=0.60;

(b)設定TT=0.50，DT=0.40，TDT=0.45，AT=0.55;

(c)設定TT=0.40，DT=0.30，TDT=0.35， AT=0.50。

表4 實驗2查全率結果

方案一方案二

閾值設定(a)(b)(c)(a)(b)(c)

查全率/%84 88 88 84 8990

方案一沒有調整詞匯特征項的權重，方案二采用逆詞頻率作為詞匯特征項的權重。

表5 實驗2查準率結果

方案一方案二

閾值設定(a)(b)(c)(a)(b)(c)

查全率/% 91 86 71 91 8773

方案一沒有調整詞匯特征項的權重，方案二采用逆詞頻率作為詞匯特征項的權重。

通過實驗結果可見，文本信息相似度和結構化信息相似度共同分析缺陷報告間的相關性可以得到較高的查全率和查準率。如圖4和5所示，實驗2在結果的查全率和查準率方面對比實驗1都有所提高，尤其在查全率方面如閾值設定(a)中，實驗2在保證查準率在90%左右的基礎上，將查全率從40%提高到85%左右。這主要是由于結構化信息更能反映缺陷的本質特征，包括產生原因和代碼環境，且避免了自然語言多義性對分析結果的不利影響。

在實驗的1 000個缺陷報告中，通過統計得到三種結構化信息所占比例，以及它們對查全率的提高，將三種結構化信息對相關性分析的貢獻定義為:該結構化信息對查全率的提高與含有該結構化信息的缺陷個數的比值，如表6所示。

表6 三種結構化信息含量和對實驗結果的貢獻

補丁代碼片段異常堆棧

含有該信息的缺陷報告個數15989137

該信息對查全率的提高/%18.67.814.6

該信息的貢獻/%0.116 9810.08 7640.106 569

其中代碼片段的貢獻最小，原因主要是由于某些代碼片段沒有標志出所屬源文件名，且其代碼信息對相似度分析沒有幫助。通過分析發現，這是由于這些代碼片段不是來自Eclipse系統的文件，也不是來自缺陷提交者對系統原文件的修改，而是由缺陷報告提交者編寫的測試代碼等，如圖6所示。

這里類名A、X等，以及方法名foo是缺陷報告提交者自己隨意命名的，所以無法幫助分析代碼片段間的相似度。

5 結束語

本文提出一種自動分析軟件缺陷報告間相關性的方法，采用缺陷報告中的文本信息相似度和結構化信息(包括補丁、代碼片段和異常堆棧)相似度，從缺陷外部和內部來共同衡量缺陷報告間的相似度，從而分析缺陷報告間的相關性。本文從Eclipse系統中抽取了1 000個缺陷報告作為實驗數據，結果顯示:對比僅使用文本信息相似度來分析缺陷報告相關性的結果，增加結構化信息相似度計算可以在保證查準率90%左右的條件下，將查全率從40%提高到85%左右。

缺陷報告間相關性的自動分析可以幫助開發人員根據這些關聯，將相關的缺陷報告進行統一的分析和修改，以避免對該缺陷的修復而引起其他新的缺陷。缺陷的相關性分析也可以提供新報告缺陷的擴展信息或修復該缺陷的參考方法，從而有利于提高軟件測試的效率和軟件質量。

本文提及的自動分析缺陷報告間相關性的技術也存在一些不足，例如對于代碼片段信息，一些由缺陷提交人員編寫的測試代碼等，由于命名是隨意的，會對代碼片段間相似度的計算形成影響;另外，相關性閾值的設定問題也是影響查全率和查準率的重要因素，對此筆者將對不同的系統的缺陷報告進行實驗，以便給用戶較合理的閾值設定意見。

參考文獻:

[1]CANFORA G， CERULO L. How software repositories can help in reoslving a new change request[C]//Proc of Workshop on Empirical Studies in Reverse Engineering.2005.

[2]ANVIK J， HIEW L， MURPHY G C. Who should fix this bug[C]//Proc the 28th of International Conference on Software Engineering. New York: ACM Press， 2006:361-370.

[3]FISCHER M， PINZGER M，GALL H. Analyzing and relating bug report data for feature tracking[C]//Proc of the 10th WCRE IEEE. Washington DC: IEEE Compnter Society， 2003:90-99.

[4]韓衛崗，周紅建，趙祿豐.軟件缺陷信息分析研究[J].計算機工程與設計，2008，29(13):3381-3383，3387.

[5]劉英博，王建民.面向缺陷分析的軟件庫挖掘方法綜述[J].計算機科學，2007，34(9):1-4，11.

[6]劉海 郝克剛.軟件缺陷數據的分析方法及其實現[J].計算機科學，2008，35(8):262-264.

[7]李寧，李戰懷.軟件缺陷數據處理研究綜述[J].計算機科學，2009，36(8):21-25，78.

[8]尹相樂，馬力，關昕.軟件缺陷分類的研究[J].計算機工程與設計，2008，29(19):4910-4913.

[9]JALBERT N， WEIMER W. Automated duplicate detection for bug tracking systems[C]//Proc of IEEE International Conference on Dependable Systems and Networks with FTCS and DCC，DSN. 2008:52-61，24-27.

[10]CUBRANIC D， MURPHY G C. Automatic bug triage using text classification[C]//Proc of SEKE.[S.l.]: KSI Press， 2004: 92-97.

[11]ANVIK J K. Assisting bug report triage through recommendation[R]. [S.l.]: University of British Columbia， 2007.

[12]WANG Xiaoyin， ZHANG Lu， ANVIK J， et al . An approach to detecting duplicate bug reports using natural language and execution information[C]//Proc of the 30th International Conference on Software Engineering. New York: ACM Press， 2008:461-470.

[13]WEISS C， PREMRAJ R， ZIMMERMANN T， et al. How long will it take to fix this bug[C]//Proc of the 4th International Workshop on Mining Software Repositories. Washington DC: IEEE Computer Society， 2007.

[14]ANVIK J. Automating bug report Assignment[C]//Proc of the 28th International Conference on Software Engineering. New York: ACM Press，2006:937-940.

[15]BETTENBURG N， JUST S， SCHRTER A， et al. Quality of bug reports in Eclipse[C]//Proc of OOPSLA Workshop on Eclipse Technology Exchange. New York: ACM Press， 2007: 21-25.

[16]BETTENBURG N， JUST S， SCHRTER A， et al. What makes a good bug report[C]//Proc of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering. New York: ACM Press， 2008:308-318.

[17]KO A J， MYERS B A， CHAU D H. A linguistic analysis of how people describe software problems[C]//Proc of IEEE Conference on Visual Language and HumanCentric Computing.2006:127-134.

[18]BETTENBURG N， PREMRAJ R， ZIMMERMANN T， et al. Extracting structural information from bug reports[C]//Proc of the 5th Working Conference on Mining Software Repositories. New York: ACM Press，2008:27-30.

[19]BETTENBURG N， PREMRAJ R， ZIMMERMANN T， et al. Duplicate bug reports considered harmful... really[C]//Proc of the 24th IEEE International Conference on Software Maintenance.2008:337-345.

[20]BAEZAYATES R， RIBEIRONETO B. Modern information retrieval[M]. New York: Addison Wesley， 1999.

[21]GUNN S R. Support vector machines for classification and regression[R]. [S.l.]: University of Southampton， Faculty of Engineering， Science and Mathematics; School of Electronics and Computer Science， 1998.

[22]RUNESON P， ALEXANDERSON M， NYHOLM O. Detection of duplicate defect reports using natural language processing[C]//Proc of ICSE. Washington DC: IEEE Computer Society，2007:499-510.

[23]龐劍鋒，卜東波， 白碩. 基于向量空間模型的文本自動分類系統的研究與實現[J]. 計算機應用研究，2001，18(9):23-26.

[24]ALLAN J， ASLAM J， BELKIN N， et al. Challenges in information retrieval and language modeling[J]. ACM SIGIR Forum， 2003，37(1):31-47..