自動分析軟件缺陷報告間相關(guān)性的方法研究

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

關(guān)鍵詞:相關(guān)缺陷報告; 結(jié)構(gòu)化信息; 相似度

中圖分類號:TP311.5文獻標(biāo)志碼: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 引言

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

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

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

1 相關(guān)的研究現(xiàn)狀

缺陷管理系統(tǒng)可以將軟件測試過程中發(fā)現(xiàn)的缺陷、缺陷信息及缺陷發(fā)生的背景信息全面詳細(xì)地記錄下來，構(gòu)成缺陷信息數(shù)據(jù)倉庫。分析挖掘已有缺陷中的信息及其相關(guān)性，有助于指導(dǎo)軟件測試工作，對提高缺陷發(fā)現(xiàn)率和改善軟件質(zhì)量是一種行之有效的方法[4]。

當(dāng)前國內(nèi)外對于缺陷報告的分析研究主要包括:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 相關(guān)缺陷報告

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

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

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

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”等，通過文本相似度分析可以檢測出這對缺陷報告是重復(fù)的。

208821 :Change SDK to use individual source bundles

211243 :Migrate org.junit4 to individual source bundle

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

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

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

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

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

3 缺陷報告間的相關(guān)性分析方法

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

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

3.1 缺陷報告中的結(jié)構(gòu)化信息及其提取方法

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

a)補丁:用來更新原文件或修復(fù)問題的一段代碼。通常更新或修改多個文件。以統(tǒng)一的“diff”格式出現(xiàn)，標(biāo)準(zhǔn)格式為UNIX 命令diff uN file1 file2(N為數(shù)字，file1、file2為文件名)。結(jié)構(gòu)如圖1所示。

Patch Index:惟一標(biāo)志每個子補丁區(qū)。

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

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

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

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

補丁信息提取:

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

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

b)異常堆棧:程序執(zhí)行時所引起的異常列表，用于幫助修復(fù)缺陷或定位缺陷產(chǎn)生原因。結(jié)構(gòu)[19]如圖2所示。

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

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

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

c)代碼片段:描述問題、問題產(chǎn)生的代碼環(huán)境或修復(fù)問題的一段代碼。結(jié)構(gòu)如圖3所示。

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

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

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

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

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

3.2 相關(guān)缺陷報告檢索方法

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

信息檢索研究的主要目標(biāo)是采用相應(yīng)算法和模型從信息庫中得到所需信息。這里的信息主要包括自然語言文本信息和結(jié)構(gòu)化信息[20]。

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

自然語言處理技術(shù)主要包括:

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

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

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

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

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

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

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

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

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

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

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

標(biāo)記化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”也是普遍出現(xiàn)的詞，所以也作為停用詞處理。

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

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

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

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

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

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

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

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

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

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

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

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

且DS

TS，TS≥TT且DS

DS，DS≥DT且TS

3.2.2 缺陷報告間的結(jié)構(gòu)化信息相似度計算

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

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

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

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

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

2)異常堆棧 以圖3為例，本文中選取異常堆棧棧頂?shù)奈鍌€調(diào)用序列作為異常堆棧的相似度特征。

3)代碼片段

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

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

3.2.3 度量缺陷報告間的相關(guān)性

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

首先分別設(shè)定缺陷報告文本信息的相似度閾值(TDT)和結(jié)構(gòu)化信息的相似度閾值(AT)的值，并根據(jù)這兩個閾值以及文本相似度(TDS)和結(jié)構(gòu)化信息的相似度(AS)度量相關(guān)性:

缺陷報告間相關(guān)， TDS≥TDT或AS≥AT

不相關(guān)，TDS

4 實驗及結(jié)果分析

為了驗證本文提出的缺陷報告間的相關(guān)性分析方法的有效性，本章設(shè)計了相應(yīng)實驗，并對實驗結(jié)果進行了分析。

實驗采用Eclipse系統(tǒng)2007年11月和12月提交的1 000個缺陷報告作為實驗數(shù)據(jù)，首先采用對缺陷報告中的文本信息進行相似度計算來分析缺陷報告間的相關(guān)性，得出實驗結(jié)果并加以分析。在此基礎(chǔ)上，增加對缺陷報告中結(jié)構(gòu)化信息的提取和相似度分析，通過文本相似度和結(jié)構(gòu)化信息相似度來共同分析缺陷報告間的相關(guān)性。

實驗數(shù)據(jù):

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

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

建立實驗:

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

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

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

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

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

表2 實驗1查全率結(jié)果

方案一方案二

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

查全率/% 43 61 79 43 6281

注:方案一沒有調(diào)整詞匯特征項的權(quán)重，方案二采用逆詞頻率作為詞匯特征項的權(quán)重。

表3 實驗一查準(zhǔn)率結(jié)果

方案一方案二

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

查準(zhǔn)率/% 91 84 66 91 8667

方案一沒有調(diào)整詞匯特征項的權(quán)重，方案二采用逆詞頻率作為詞匯特征項的權(quán)重。

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

實驗2在實驗1的基礎(chǔ)上，增加對結(jié)構(gòu)化信息相似度計算來共同分析缺陷報告間相關(guān)性。

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

當(dāng)文本相似度(TDS)超過了文本相似度閾值(TDT)，或者結(jié)構(gòu)化信息相似度(AS)超過了結(jié)構(gòu)化信息相似度閾值A(chǔ)T，則認(rèn)為缺陷報告間是有相關(guān)性的。分別采用以下三種閾值設(shè)定來進行實驗，相關(guān)性分析的查全率和查準(zhǔn)率結(jié)果如表4和表5所示。

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

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

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

表4 實驗2查全率結(jié)果

方案一方案二

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

查全率/%84 88 88 84 8990

方案一沒有調(diào)整詞匯特征項的權(quán)重，方案二采用逆詞頻率作為詞匯特征項的權(quán)重。

表5 實驗2查準(zhǔn)率結(jié)果

方案一方案二

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

查全率/% 91 86 71 91 8773

方案一沒有調(diào)整詞匯特征項的權(quán)重，方案二采用逆詞頻率作為詞匯特征項的權(quán)重。

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

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

表6 三種結(jié)構(gòu)化信息含量和對實驗結(jié)果的貢獻

補丁代碼片段異常堆棧

含有該信息的缺陷報告?zhèn)€數(shù)15989137

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

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

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

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

5 結(jié)束語

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

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

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

參考文獻:

[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]韓衛(wèi)崗，周紅建，趙祿豐.軟件缺陷信息分析研究[J].計算機工程與設(shè)計，2008，29(13):3381-3383，3387.

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

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

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

[8]尹相樂，馬力，關(guān)昕.軟件缺陷分類的研究[J].計算機工程與設(shè)計，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]龐劍鋒，卜東波， 白碩. 基于向量空間模型的文本自動分類系統(tǒng)的研究與實現(xiàn)[J]. 計算機應(yīng)用研究，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..