萬瑩，張光蘭，譚武坤

（四川大學計算機學院，成都610065）

0 引言

隨著軟件規(guī)模和復雜度的不斷增加，軟件中出現(xiàn)缺陷是不可避免的。對于軟件中的缺陷，開發(fā)人員通過對代碼進行調(diào)試然后定位到真正的缺陷語句。然而，軟件調(diào)試是一項既困難又昂貴的活動。美國國家標準與技術研究所在2002 年指出，軟件缺陷每年給美國經(jīng)濟大約造成595 億美元的損失[1]，其中為了找到缺陷對軟件進行測試和調(diào)試的活動占了30-90%的花銷[2]。近年來，越來越多國內(nèi)外的學者開始研究缺陷定位技術，并取得了許多不錯的結果。現(xiàn)今對缺陷定位的方法主要分為兩種：動態(tài)定位和靜態(tài)定位。動態(tài)定位是通過程序執(zhí)行測試用例，收集程序執(zhí)行跟蹤信息等進行定位，其中基于頻譜的缺陷定位方法研究最多。靜態(tài)定位是通過使用缺陷報告和代碼進行各種形式的分析進行缺陷定位[3]，研究者主要是使用基于信息檢索的方法進行缺陷定位，該方法中與缺陷報告相似度分數(shù)越高的源代碼文件越有可能含有缺陷。雖然動態(tài)定位方法準確率較高，但動態(tài)方法通常既耗時又昂貴，而靜態(tài)方法比較易用，且它的即時推薦性使其具有吸引力。Ngyuen等人提出了BugScout[4]，它使用LDA（Latent Dirichlet Allocation）方法進行缺陷定位，幾個大型數(shù)據(jù)集的結果顯示了其良好的性能。Zhou 等人[5]提出了BugLocator，它使用了TF-IDF 公式，并加入以前修復過的相似缺陷的報告。在對大約3400 個bug 的大規(guī)模評估中，BugLocator 顯示出比BugScout 更強的性能。Ripon[6]等人提出的BLUiR 將缺陷報告以及源代碼進行結構化處理后進行定位，得到的定位效果更好。但是傳統(tǒng)的靜態(tài)缺陷定位沒有考慮到缺陷報告是用自然語言進行描述的，因此缺陷報告與源代碼文件中的代碼會有詞匯不匹配的問題，如果考慮最極端的情況，源代碼文件和缺陷報告沒有共同的詞，那么它們在標準TF-IDF 矢量空間模型中的余弦相似度為0。這也是導致靜態(tài)缺陷定位效率低的原因之一。為了提高缺陷定位的準確率，本文提出使用項目相關文檔，如用戶手冊、項目API 說明文檔等進行訓練獲得Word2Vec 模型，根據(jù)Word2Vec 模型得到缺陷報告與源代碼文件之間的相似度，解決缺陷報告與源代碼文件之間的詞匯鴻溝，在基于信息檢索的缺陷定位方法上進一步提高了缺陷的準確度。

1 基于Word2Vec模型的缺陷定位

1.1 問題分析

目前靜態(tài)缺陷定位方法的研究，如基于信息檢索的缺陷定位主要是通過TF-IDF 對缺陷報告和源代碼文件進行詞向量化后計算兩者之間的距離，以判斷出含有缺陷的源代碼文件。由于缺陷報告大多數(shù)是用自然語言進行編寫的，而源代碼文件是由編程語言組成，因此直接將缺陷報告和源代碼文件進行詞向量距離的計算，將會導致定位的準確率降低。如圖1、圖2 分別是與Eclipse 項目的缺陷報告和對應的缺陷源代碼文件。

圖1 Bugzilla系統(tǒng)上獲取Eclipse項目的缺陷報告

圖2 Eclipse項目源代碼文件

圖3 、圖4 分別是Eclipse 項目的用戶手冊和API文檔。從圖中可以看出，圖1 的缺陷報告中關于缺陷描述的關鍵詞與缺陷的描述與真正含有缺陷的源代碼文件PartServiceImpl.java 中的代碼單詞不相關，因此如果直接使用信息檢索技術計算將會判斷兩者不相關。但根據(jù)圖3、圖4 中對PartServiceImpl.java 中該功能的介紹，可以判斷BugID=384108 的缺陷報告與PartServiceImpl.java 中的某些方法在語義上是相關的。

為了提高傳統(tǒng)靜態(tài)缺陷定位的準確率，本文提出可以根據(jù)項目的API 說明文檔，用戶手冊等相關文檔判斷缺陷報告和源代碼文件之間的語義相關進行缺陷定位，通過上下文語義可以很好的解決自然語言與編程語言之間的詞匯鴻溝問題。本文的整體框架如圖5。

圖4 Eclipse項目API文檔

圖5 基于Word2Vec缺陷定位方法的整體框架

1.2 Word2Vec模型簡介

Harris[7]等人提出了分布假設，即在同一語境下的詞往往具有相似的含義。這一假設引發(fā)了許多學者進行研究。Pantel 和Lin[8]將Mij 計算為wi 和cj 之間的點互信息（PMI），以衡量它們之間的相關性。Landauer和Dumais[9]提出通過“矢量語義空間”來提取文檔與詞中的概念意義，進一步分析文檔與詞之間存在的關系，即潛在語義分析（LSA）。近年來，人們提出可以使用神經(jīng)網(wǎng)絡模型直接學習向量以此來最優(yōu)地預測上下文，這類方法稱為“neural embedding”或“word embedding”[10]。這些模型被成功地應用于各種NLP 任務中[11-13]。在這些模型中，Mikolov 在2013 年提出的Word2Vec 模型[14]因其在訓練過程中的簡單和高效而廣受歡迎。

Word2Vec 模型主要有兩種訓練模型：CBOW、Skip-gram。在文獻[11,13]中，可以得到基于信息檢索的一組自然語言處理任務中，Skip-gram 模型也明顯優(yōu)于其他傳統(tǒng)方法，因此本文使用的訓練模型選擇Skipgram 模型。Skip-gram 模型是根據(jù)當前詞來優(yōu)化預測出它的上下文的概率，因此其目標函數(shù)[15]為式（1）。

其中，T 是語料庫單詞的總個數(shù)，p（wt+j|wt）是已知當前詞wt，預測周圍詞的總概率對數(shù)值。其條件概率函數(shù)p（c|w）的計算公式[15]如式（2）。

其中wt 是當前詞語的詞向量，wk 是任意詞語的詞向量。

本文使用用戶手冊、API 文檔作為語料訓練三個單層神經(jīng)網(wǎng)絡結構來建立Word2Vec 模型，通過Word2Vec 模型獲得缺陷報告與源代碼文件的詞向量表示，由于詞向量附加語義級別的信息，因此即使是兩句話中有不相似或相同的詞匯，只要二者在語義上大意相同，我們?nèi)云渥R別為相同。Word2Vec 模型的優(yōu)勢在于其反映了文本的語義信息，即可以將語義相似的句子識別出來，而不像TF-IDF 算法一樣需要有相同詞匯才能判斷出文本之間的相似性。通過Word2Vec 模型，我們得到了兩文本的向量表示。

1.3 詞向量的相似度計算

本文使用余弦相似度來度量文本之間的相似程度，即將每兩個文本向量映射到空間中的兩個線段，且線段均從原點出發(fā)，兩條線段相交的夾角大小就可以反映出兩個文本之間的相似程度。

給定經(jīng)過Word2Vec 模型計算后的缺陷報告B={B1,B2,...,Bn}與源代碼文件S={S1,S2,..,Sn}，使用余弦相似度公式計算B 與S 之間的相似距離。余弦相似度計算公式如式（3）。

這是兩個向量的內(nèi)積，用歐幾里德范數(shù)標準化。其WB 代表一個缺陷報告的詞向量，WS 代表一個源代碼文件的詞向量。本文根據(jù)實驗結果獲得文本相似閾值，當最終的結果高于閾值時，則判斷兩個文本相似，若低于此閾值則認為這兩個是不相似的，并將最終計算所得的余弦值按照降序輸出源代碼文件名，該源代碼列表即為缺陷推薦列表，排名越靠前的源代碼文件越有可能含有缺陷。

2 實驗驗證

本文設計的基于Word2Vec 模型的缺陷定位系統(tǒng)原型是以缺陷報告B 作為輸入，從大量的源代碼文件庫中對所有的源文件S 進行排序，排名越靠前的源代碼文件越有可能含有缺陷，本文使用PyCharm 作為實驗過程中的開發(fā)工具。為了研究本文所提方案是否能提高缺陷定位發(fā)準確率，本文收集了Eclipse、AspectJ等多個開源項目數(shù)據(jù)來驗證所提方法的有效性，各項目的詳細信息如表1 所示。

表1 實驗項目的數(shù)據(jù)

在進行缺陷定位前，本文需要對缺陷報告文檔、源代碼文檔以及其他與項目相關文檔進行預處理。其中對源代碼文件需要使用JDT 技術對其構建一棵抽象語法樹（AST），該語法樹的程序結構為：類名、方法名、變量名。本文在Bugzilla 缺陷跟蹤系統(tǒng)中爬蟲獲取的缺陷報告xml 文檔中含有許多字段，如BugID、summary、description 等，在本文中，我們主要使用缺陷報告的summary 和description 兩個部分的文本內(nèi)容。本文使用Python 的nltk 庫對所有文檔進行分詞、去停用詞、詞干化等。處理好的項目用戶手冊、API 文檔等的信息如表2。

表2 訓練Word2Vec 的數(shù)據(jù)

本文使用與項目相關文檔用戶手冊、API 文檔等數(shù)據(jù)訓練Word2Vec 模型。使用Word2Vec 模型獲取缺陷報告與源代碼文件的詞向量，并使用余弦相似度計算公式計算兩者相似度。

3 實驗分析

本文使用目前靜態(tài)缺陷定位研究中使用的評價標準平均準確率（MAP）和平均排序倒數(shù)（MRR）[6]來對本文所提方案進行評估。其中MRR 和MAP 值越高，說明缺陷定位技術的性能越好。

MRR 是第一個定位到正確的缺陷源代碼文件位置的倒數(shù)的累加均值，它是通過正確的結果值在所有搜索結果中的排名來評估該方法的結果。因此MRR的值越高，就代表缺陷定位方法的性能越好。MRR 在本文中的計算方法為公式（4）：

其中Q 是缺陷報告的數(shù)量，firsti表示第i 個缺陷報告為第一個含有缺陷的源代碼文件的位置。

MAP 是指第一個定位到正確的缺陷源代碼文件的準確率平均值，因此MAP 的值越高，就代表缺陷定位方法的準確率越高。MAP 在本文中的計算為公式（5）:

其中ind（R）表示位于第j 個源代碼文件是否為真正的含有缺陷的源代碼文件（ind（R）=1 代表為是，0代表否），NB(i)表示查找的第i 個缺陷報告的源代碼文件數(shù)量。

本文用WBugLocator 代表本文所提的基于Word2Vec 模型的缺陷定位方法。缺陷報告與源代碼文件的相似度分數(shù)在[0,1]之間,為了找到合適的相似閾值，本文將相似分數(shù)按每0.1 劃分為一個區(qū)間，并統(tǒng)計每個區(qū)間找到的缺陷個數(shù)。結果如圖6 所示。

在圖6 中，可以發(fā)現(xiàn)相似分數(shù)大于等于0.75 時反饋給開發(fā)者的源代碼文件排序列表中含有的缺陷最多，因此本文所提方法的相似閾值為0.75。

WBugLocator 經(jīng)過大量的實驗后，與BugLocator、BLUiR 兩個工具進行比較的實驗結果如表3。

與BugLocator、BLUiR 兩個工具進行對比的MRR與MAP 的值如圖7、圖8。

圖6 缺陷報告與源代碼方法的相似閾值

表3 WBugLocator 與BUGLOCATOR、BLUIR 工具對比

圖7 WBugLocator的MRR值

實驗結果表明使用BugLocator、BLUiR 方法和本文的WBugLocator 相比，如對于AspectJ 項目，使用WBugLocator 方法返回的與缺陷相關源代碼文件位于Top1 的MAP 值為40%，而使用BugLocator、BLUiR 方法定位到的缺陷只有22%左右。并且對于返回的Top5 和Top10的文件，WBugLocator 方法計算得到的MAP 和MRR 數(shù)值也都高于BugLocator、BLUiR 方法的MAP 和MRR。因此整體來說，WBugLocator 方法在四個項目中的MAP、MRR 均高于BugLocator、BLUiR 兩個工具，可見本文提出的基于Word2Vec 方法提高了缺陷定位準確性。

4 結語

本文提出了基于Word2Vec 模型的缺陷定位方法，該方法解決了缺陷報告與源代碼文件之間詞匯不匹配的問題，實驗結果證明，本文提出的缺陷定位方法提高了定位準確率，對之后的研究具有一定的實際意義。下一步工作將研究該方法與動態(tài)缺陷定位方法相結合是否能進一步提高缺陷定位的準確度。