張 洋,王 濤,吳逸文,尹 剛,王懷民

1(國防科技大學 并行與分布處理國防科技重點實驗室,湖南 長沙 410073)

2(國防科技大學 計算機學院,湖南 長沙 410073)

社交化編程(social coding)最早由開源社區(qū)GitHub提出,旨在提供一個對開發(fā)者友好的軟件開發(fā)環(huán)境,幫助開發(fā)者進行高效的互聯(lián)、協(xié)同、開發(fā)[1].社交化編程的出現(xiàn),極大地增強了代碼復用[2]以及缺陷解決效率[3];開發(fā)者可以自主地參與報告和討論缺陷,這樣一來,缺陷報告作為一類重要的軟件開發(fā)知識,經常會被不同開發(fā)者在不同的時間報告出來;實踐中經常會出現(xiàn)兩個缺陷報告含有相關的信息,開發(fā)者可以在缺陷討論過程中,通過URL鏈接將相關的缺陷報告關聯(lián)起來[4].

鏈接相關缺陷的過程,對于開發(fā)者快速、有效地修復缺陷是十分重要的.當一個開發(fā)者提交一個新缺陷報告后,其他開發(fā)者會參與討論并對這個缺陷的價值進行評價.在他們的討論過程中,參與者可能會鏈接相關的其他缺陷報告來尋找可能有用的資源和信息.最終,受助于這些鏈接和討論,缺陷被解決和關閉.然而,現(xiàn)實世界的鏈接過程需要耗費大量的時間和人力.尤其對于那些規(guī)模龐大的軟件項目,開發(fā)者可能需要查找大量的歷史缺陷數(shù)據,才能通過它們的文本描述信息定位到相關的缺陷,并且這樣的基于人工的關聯(lián)方法主要依賴于個體開發(fā)者的經驗和知識.因此,設計并實現(xiàn)自動化的缺陷關聯(lián)方法能夠幫助開發(fā)者更加聚焦他們的缺陷解決,也能夠幫助項目管理者獲取缺陷間的關聯(lián)關系,從而提高軟件的開發(fā)、維護效率.

本文以開源社區(qū) GitHub中的軟件項目為研究對象,主要聚焦 GitHub中缺陷之間的自動化關聯(lián)問題.因為GitHub是目前全球最大、最著名的開源社區(qū),截止2018年3月,它已經托管了超過8千萬的軟件版本庫.近年來,學術界也產生了大量基于GitHub數(shù)據開展的研究工作[2-6].一方面,在傳統(tǒng)的缺陷跟蹤系統(tǒng)中,例如BugZilla,目前學術界和工業(yè)界已經出現(xiàn)了很多輔助開發(fā)者進行重復缺陷檢測[7]、缺陷定位[8]、相似缺陷推薦[9]的方法,然而針對GitHub缺陷跟蹤系統(tǒng)的缺陷關聯(lián)研究目前尚未出現(xiàn);另一方面,現(xiàn)有相關工作提出的方法主要基于傳統(tǒng)的信息檢索(IR)技術,通過自動化地抽取給定缺陷報告的文本信息(由單詞、句子組成)來搜索相關缺陷報告或文件,例如余弦相似度(cosine similarity)和TF-IDF.但傳統(tǒng)的IR技術主要關注語料庫中單詞與單詞之間的關系,忽略了單詞的上下文語義信息.最近,一些自然語言處理(NLP)領域的研究工作開始利用深度學習技術[10-12],例如詞嵌入模型,對單詞的上下文信息進行刻畫.并且,一些研究者也開始嘗試利用深度學習技術來解決軟件工程問題并取得了不錯的結果[13-15].

在本文中,我們將關聯(lián)相關缺陷的問題抽象為推薦(recommendation)任務,為了解決該任務,我們提出了一種基于嵌入模型的混合式相關缺陷關聯(lián)方法.該方法將傳統(tǒng)的IR技術(TF-IDF)與深度學習技術(詞嵌入模型和文檔嵌入模型)結合起來,能夠自動化地為新缺陷推薦相關的缺陷報告.對于我們數(shù)據庫中的每個缺陷報告,我們將其文本信息(標題和描述)抽取出來并保存到文檔里.接下來,我們利用3種子方法(TF-IDF、WE和DE)分別表征每個缺陷文檔的向量,并計算他們之間的相似度得分.其中,TF-IDF主要從詞頻的角度提取不同單詞間的關聯(lián)關系,WE和DE則分別從單詞和文檔出現(xiàn)的上下文角度提取單詞間以及文檔間的關聯(lián)關系.最后,我們將3個子方法得到的相似度得分相加得到最終得分,進而基于該得分對相關缺陷進行推薦.

為了評價本文方法的有效性,我們選取了兩個著名的 GitHub項目作為研究對象:Request項目和 Moment項目.在實驗驗證過程中,我們將本文方法和4種基準方法(baseline approach)進行比較,包括NextBug[9]以及我們的3種子方法.具體來說,我們設計了以下4個具體研究問題.

· RQ1:與基準方法相比,本文方法在性能上可以有多少提升?

· RQ2:本文方法對于缺陷語料庫是否有很強的依賴性?

· RQ3:本文方法對于訓練集規(guī)模的依賴如何?

· RQ4:本文方法的訓練時間開銷如何?

實驗結果表明,基于嵌入模型的混合式相關缺陷關聯(lián)方法充分地考慮了軟件缺陷的詞頻和上下文信息,可以明顯地提高基準方法的性能;并且對于不同的缺陷語料庫,本文方法的性能仍然具有一定的可靠性;且本文方法的訓練時間開銷較小,具有很高的應用擴展性.

本文第 1節(jié)對相關研究背景進行介紹,結合相關工作引出本文研究問題及方法.第 2節(jié)詳細介紹本文提出的方法框架和技術細節(jié).第 3節(jié)對實驗驗證的方法和評價指標進行介紹.第 4節(jié)介紹具體研究問題下的實驗結果.第5節(jié)介紹案例分析.最后總結全文.

1 研究背景

為了更好地闡述本文工作,我們首先對相關背景知識和相關工作進行介紹.

1.1 語義相似度與嵌入模型

測量兩個文本的語義相似度是一類經典的研究問題,現(xiàn)有的解決模型也從向量空間模型(例如 TF-IDF)、n-gram語言模型、主題建模(例如LDA[16])向更多的基于人工神經網絡的語言模型[11,12,17]發(fā)展.2013年,Mikolov等人[11,12]提出了兩個基于人工神經網絡的語言模型,分別是continuous bag-of-words和continuous skip-gram,并針對大規(guī)模文本數(shù)據提出了有效的負采樣(negative sampling)方法.

詞嵌入模型(word embedding,簡稱WE)[11,12]是自然語言處理領域非常著名的深度學習模型,它主要將每個單詞映射到n維的向量空間.詞嵌入模型主要基于這樣的假設,即出現(xiàn)在相似上下文的單詞間通常會有相似的語義.因為表征單詞的每個維度都代表著單詞的語義或語法特征,因此越相似的兩個單詞會在向量空間中具有越近的向量距離.

文檔嵌入模型(document embedding,簡稱 DE)[10]旨在對詞嵌入模型進行擴展,以實現(xiàn)更高級別(文檔級)的向量表示.在其訓練過程中,每個文檔都映射到一個唯一的向量,由矩陣中的列表示,每個單詞也映射到一個唯一的向量.然后對文檔向量和單詞向量進行平均或連接處理,以預測上下文中的下一個單詞.

由于詞嵌入模型和文檔嵌入模型都是從未標記的數(shù)據中學習的,因此可以適用于沒有足夠標簽數(shù)據的任務.此外,嵌入模型更側重于單詞和文檔的上下文,所以可以很好地補充傳統(tǒng)的 IR技術,例如,TF-IDF.最近,一些研究表明,嵌入模型在軟件工程任務中也表現(xiàn)良好[13,14].例如,Xu等人[13]將預測語義可鏈接的知識單元問題(即stack overflow中的帖子及其回答)抽象為多類別分類問題,并使用詞嵌入模型和CNN解決該問題.Ye等人[14]提出,可以通過將自然語言語句和代碼片段作為共享表示空間中的含義向量進行投影,來擬合詞匯差距.他們在API文檔、教程和參考文檔上訓練了詞嵌入模型,然后將它們聚合在一起,來計算文檔之間的語義相似性.這些研究的提出,促使了我們將嵌入模型整合到我們的方法中.

1.2 缺陷修復和重復缺陷檢測

在缺陷跟蹤系統(tǒng)中,缺陷修復一直是一個復雜、需要不斷迭代且耗時的過程,它涉及整個開發(fā)人員社區(qū),從而引發(fā)特定的協(xié)同問題[18].已有的對于缺陷解決過程的研究主要關注缺陷分類[19]和推薦相關開發(fā)者[20].其中,Guo等人[21]分析了缺陷修復過程如何受人們的聲譽、缺陷報告編輯活動以及地理和組織關系的影響.Zimmermann等人[22]使用混合式方法來表征缺陷re-open的過程,并定量評估了各種因素的影響.最近,對缺陷修復過程的研究擴展到去鏈接其他相關資源,例如相關代碼提交[23]、相關文件[24]和來自問答網站的相關帖子[25].具體來看,Bachmann等人[23]提出了一個名為Linkster的工具,以便于識別缺陷與代碼提交之間缺失的鏈接信息.Ye等人[24]引入了一種自適應排序方法來關聯(lián)相關的領域知識,它主要通過功能性地分解源代碼文件、代碼中使用的庫組件的 API方法描述、缺陷修復歷史等.我們之前的研究[25]也探討了缺陷嚴重性與鏈接 Stack Overflow問答網站帖子的大眾屬性之間的相關性.

為了幫助修復缺陷,許多研究開始分析重復缺陷檢測問題[7,26].例如,Wang等人[26]通過分析缺陷報告和執(zhí)行信息中的文本信息,來檢測兩個缺陷報告是否相互重復.Sun等人[7]提出了一種信息檢索方法 REP來識別重復的缺陷報告.REP考慮了缺陷報告中提供的更多信息,并擴展了BM25F方法以更準確地測量文本相似性.最近,一些研究人員開始研究相似缺陷報告推薦的問題,例如Rocha等人[9]提出了一種名為NextBug的推薦方法,依靠傳統(tǒng)的信息檢索技術來計算缺陷報告之間的余弦相似度.他們的結果顯示,用于相似缺陷推薦的 NextBug在性能上優(yōu)于之前的重復缺陷報告檢測技術REP.在本文的后續(xù)實驗中,我們也將NextBug作為基準方法之一,用以參照比較本文方法的性能.

1.3 GitHub中的缺陷關聯(lián)問題

在 GitHub中,每個托管的項目都與一個缺陷跟蹤系統(tǒng)相關聯(lián),該系統(tǒng)提供缺陷跟蹤過程中的常用功能,例如提交缺陷報告、根據缺陷的性質進行標記、標記缺陷不同時間點的解決狀態(tài)等[27].GitHub中的缺陷解決過程是一個協(xié)同且復雜的過程:在開發(fā)者提交新的缺陷報告后,其他開發(fā)者會參與討論并對該缺陷進行評估,以確定是否值得解決,如果是,則優(yōu)先考慮該缺陷的解決過程.關聯(lián)的鏈接可以視為缺陷解決過程中的重要一步,因為在討論過程中,利益相關者可能會在評論中鏈接其他相關缺陷報告來提供他們認為有用的資源和信息.因為使用了Flavored Markdown技術,在GitHub平臺上,開發(fā)者可以輕松鏈接到相同項目的另一個缺陷報告(如圖1所示,在缺陷request/request#2397中,開發(fā)者tzachshabtay進行了評論并給了一個鏈接,指向編號234的缺陷報告).最終,在這些鏈接和討論的幫助下,該缺陷將被解決和關閉.

Fig.1 An example of issue linking in the GitHub project圖1 GitHub項目中缺陷鏈接的示例

為了及時起到作用,關聯(lián)相關缺陷報告的鏈接應該被迅速地發(fā)現(xiàn)和提出.但實際上,這些鏈接出現(xiàn)的時機主要取決于各個開發(fā)者的經驗和知識,所以會產生很多不同.而現(xiàn)實世界查找相關缺陷報告并進行鏈接的過程是非常耗時的,很大程度上依賴開發(fā)者人工的搜索和定位.例如,圖2顯示了Moment項目中實際鏈接相關缺陷報告的時間延遲分布(在我們統(tǒng)計中,時間延遲表示從缺陷創(chuàng)建到第 1個鏈接出現(xiàn)的時間,以天為單位).我們發(fā)現(xiàn),Moment項目的開發(fā)者平均需要37.9天(中位數(shù):2.8天)才能鏈接到相關缺陷報告,并且箱圖中有許多異常值,這表示在很多缺陷報告中,開發(fā)者需要更長的時間才能發(fā)現(xiàn)相關的缺陷報告.

Fig.2 Distribution of link latency (day) in Moment project圖2 Moment項目中鏈接延遲(天)的分布

因此,我們需要能夠用于鏈接GitHub項目中相關缺陷的自動化工具.盡管在傳統(tǒng)的缺陷跟蹤系統(tǒng)中已經提出了許多用于鏈接相關缺陷資源的自動化方法[7-9],但據我們所知,目前還沒有研究對 GitHub項目中的缺陷自動鏈接問題進行過分析.通過本文,我們試圖對這一類問題進行研究,并提出缺陷自動關聯(lián)的初步方法.

2 方法概述

本文將相關缺陷自動關聯(lián)問題抽象為推薦問題,即對于開發(fā)者給出的查詢缺陷,我們的任務是自動化地推薦與該缺陷相關的其他缺陷.下面我們將詳細地介紹我們的方法框架和技術細節(jié).

2.1 總體框架

圖3顯示了本文方法的整體框架.首先,我們從所有缺陷數(shù)據中提取它們的文本信息.然后,對于每個缺陷報告,我們將其標題和描述組合到一個文檔中.接下來,我們使用以下步驟預處理這些缺陷文檔.

· 步驟1:從每個缺陷文檔中提取所有單詞.

· 步驟2:刪除停用詞、數(shù)字、標點符號和其他非字母字符.

· 步驟 3:使用 Lancaster stemmer技術(https://www.scientificpsychic.com/paice/paice.html)將剩余的單詞轉換為它們的根形式,以減少特征維度并將相似的單詞統(tǒng)一為一個共同的表示.例如,像“interests”這樣的復數(shù)名詞將被替換為單數(shù)形式的“interest”,諸如“ate”、“eaten”和“eating”等表示不同時態(tài)的形式將被替換為不定形式“eat”.

Fig.3 Framework of our approach圖3 本文方法的總體框架

基于預處理過的缺陷文檔數(shù)據,我們分別使用 3種子方法(TF-IDF,WE和 DE)來計算查詢缺陷和每個候選缺陷之間的相似性得分(FScore:詞頻相似度;WScore:單詞相似度;DScore:文檔相似度).雖然這3個得分都可以代表缺陷間的相似性,但它們之間是互相補充的,因為:

·FScore是基于TF-IDF子方法生成的,它更關注缺陷之間的詞頻關系,主要考慮整個缺陷語料庫中的出現(xiàn)的單詞頻率信息.

·WScore是基于WE子方法生成的,它更側重于單詞的上下文信息.

·DScore是基于DE子方法生成的,它更側重于缺陷文檔之間的相關性.

最后,我們將這 3個分數(shù)相加,得到每個缺陷對之間的最終相似度得分,并根據這一得分推薦相關缺陷.其中,得分越高說明兩個缺陷報告之間的語義相似度越高.

接下來,我們詳細介紹3種子方法的技術細節(jié).

2.2 TF-IDF子方法

TF-IDF(term frequency-inverse document frequency)是目前最流行的信息檢索技術之一,圖4表示了TF-IDF的簡要工作流程,其主要思想是:如果一個單詞在一個文檔中出現(xiàn)多次而在其他文檔中只出現(xiàn)很少次數(shù),則該單詞具有區(qū)分文檔的良好能力,因此該單詞具有高TF-IDF值.

Fig.4 Brief process of TF-IDF sub-method圖4 TF-IDF子方法的簡要流程

特別地,給定一個單詞t和一個文檔集合D={d1,d2,…,dN},我們可以利用如下所示的公式計算文檔di中單詞t的TF-IDF值.

其中,f(t,di)表示單詞t出現(xiàn)在文檔di中的頻率,而n(di)表示文檔di中的單詞總數(shù).之后,我們通過使用余弦相似度來計算兩個文檔的相似性,因為它是目前一種流行的計算相似度的方法,并且已經被證明非常適用于TF-IDF向量.因此,給定兩個TF-IDF向量Vf1和Vf2,它們的詞頻相似度得分FScore計算方法如下.

2.3 WE子方法

Mikolov等人[11,12]提出了一種流行的詞嵌入模型,稱為continuous skip-gram,它可以有效地訓練并支持各種語言任務的處理.因此在本文方法中,我們使用該continuous skip-gram模型來獲取詞嵌入向量.為了學習目標詞的向量表示,該模型將上下文信息定義為圍繞目標詞的固定數(shù)量的詞(如圖5所示).

Fig.5 Brief process of WE sub-method圖5 WE子方法的簡要流程

因此,給定一個單詞集合T={t1,t2,…,tn}和目標單詞ti以及上下文窗口大小k.Continuous skip-gram模型的目標是最大化以下閾值Lt.

其中,ti-k,…,ti+k是目標單詞ti的上下文.概率Pr(ti-k,…,ti+k|ti)的計算公式如下.

其中,我們假設上下文單詞和目標單詞是相互獨立的.此時,Pr(ti+j|ti)定義如下.

其中,It和Ot是單詞t的輸入和輸出向量,T是所有單詞的詞匯集合.通過訓練整個語料庫,語料庫詞匯表中的所有單詞可以表示為δ維向量,其中,δ是可變參數(shù)并且通常被設置為諸如200的整數(shù).

之后,我們將每個單詞轉換為固定長度的向量.這樣,每個文檔可以表示為一個矩陣,其中每行代表一個單詞.考慮到不同的文檔具有不同數(shù)量的單詞,我們通過平均文檔包含的所有單詞向量將文檔矩陣轉換為一個向量.特別地,給定具有n行的文檔矩陣,我們將矩陣的第i行表示為ri,并且利用如下公式生成變換的文檔向量Vt.

最后,對于給定的兩個文檔向量Vw1和Vw2,我們同樣使用余弦相似度來測量它們的單詞相似度得分WScore,計算公式如下.

2.4 DE子方法

為構建文檔嵌入模型,我們使用向量分布的bag of words(PV-DBOW)方法[10].它作為skip-gram的實例,能夠學習任意長度單詞序列的向量表示,例如句子、段落,甚至整個大文件.圖6顯示了文檔嵌入模型的簡要流程.

Fig.6 Brief process of DE sub-method圖6 DE子方法的簡要流程

具體地,給定一組文檔D={d1,d2,…,dN}和從文檔di中采樣的單詞集合T(di)={t1,t2,…,tk},模型可以學習出一個文檔di(每個單詞tj來自T(di)采樣)的δ維嵌入向量(V∈Rδ,t∈Rδ).該模型通過分析在文檔di中出現(xiàn)單詞tj

dij的頻率并試圖使下面的閾值Ld最大化.

其中,概率Pr(tj|di)的計算公式如下.

其中,T是D中所有文檔中所有單詞的詞匯集合.最后,給定兩個文檔向量Vd1和Vd2,我們計算其文檔相似度得分DScore如下.

3 實驗驗證

為了評估本文方法的有效性,我們對GitHub項目進行了實證研究.下面我們分別從實驗數(shù)據、Ground truth構建、評價指標和實驗設置這4個方面進行闡述.

3.1 實驗數(shù)據

我們選擇了兩個著名的 GitHub項目作為我們的研究對象:Moment(一個輕量級的 JavaScript日期庫)和Request(一個簡化的HTTP請求客戶端).我們選擇它們主要有兩個原因.

(1) 它們非常著名,并且在GitHub上有很多stars和forks.

(2) 它們都是具有較長生命周期的活躍項目,擁有眾多經驗豐富的開發(fā)者以及大量歷史數(shù)據.

表1總結了它們的基本統(tǒng)計數(shù)據(截至2018年4月).我們可以發(fā)現(xiàn),它們都很早就在GitHub上托管并且有很多的缺陷報告數(shù)據(超過千個).

Table 1 Basic descriptive statistics of studied two projects表1 兩個研究項目的基本數(shù)據統(tǒng)計

使用GitHub API,我們收集了2018年4月之前兩個項目的所有缺陷報告數(shù)據,包括缺陷ID、缺陷狀態(tài)(開放、關閉)、缺陷標題和描述等.

3.2 Ground truth構建

我們的Ground truth構建主要基于實際出現(xiàn)的缺陷URL鏈接,即如果兩個缺陷報告之間存在URL鏈接,我們認為它們是相互關聯(lián)的.具體來說,我們定義缺陷A和缺陷B是一對鏈接對,(A,B)或A→B,當且僅當在缺陷A的討論中包含鏈接到缺陷B的URL鏈接.在實際解析過程中,我們使用GitHub的“cross-referenced”API來查找項目所有缺陷的鏈接信息.

請注意:在本文工作中,我們只考慮項目內部鏈接,暫不考慮跨項目的缺陷鏈接.最后,我們在Request項目中總共發(fā)現(xiàn)了1 110個缺陷鏈接對,在Moment項目中發(fā)現(xiàn)了2 406個缺陷鏈接對.

3.3 評價指標

為了評估我們方法的有效性,我們使用了 3個評價指標:Top-k召回率(R@k)、平均精度(MAP)、平均排序等級(MRR),它們通常被用于評估軟件工程任務中的推薦系統(tǒng)性能[8,9,15].特別地,給定一個待查詢缺陷i,我們將其實際的缺陷鏈接集合定義為Lk(i),并將推薦系統(tǒng)產生的top-k推薦集合定義為R(i).下面我們介紹R@k、MAP和MRR的具體計算過程.

·R@k:其目的是檢查top-k推薦結果是否正確.對于待查詢缺陷i,其R@k可以計算如下.

· MAP:它被定義為所有評估查詢結果獲得的平均精度值(AvgPrec)的平均值.單個待查詢缺陷i的AvgPrec計算方法如下.

其中,Prec@k是排名列表中top-k問題的檢索精度,即top-k推薦中存在待查詢缺陷i的實際缺陷鏈接數(shù)目的百分比.

· MRR:它被定義為所有推薦結果對應的倒數(shù)排序(reciprocal rank,簡稱 RR)值的平均值,其中,單個查詢缺陷i的RR值是第1個正確答案的排序firsti的倒數(shù).

3.4 實驗設置

在我們的實驗中,我們將數(shù)據集內擁有實際鏈接的、所有已關閉的缺陷都視為待查詢缺陷.給定一個待查詢缺陷i,我們按照與i的相似性得分大小將所有待判斷缺陷進行排序,從而推薦top-k個最相似的缺陷.需要注意的是,我們只推薦在待查詢缺陷i產生之前出現(xiàn)的缺陷,即它們的缺陷ID必須小于i的ID.在具體代碼中,我們主要使用Python的Gensim包來實現(xiàn)我們的嵌入模型方法.特別地,對于WE和DE子方法,我們將上下文窗口大小s設置為5,將初始學習速率α設置為0.025,并且將表征向量d的維度設置為200.

4 實驗結果

在本節(jié),我們介紹具體的實驗結果.根據設計的 4個研究問題,我們分別對每個研究問題的研究動機、分析方法、分析結果進行詳細闡述.

4.1 RQ1:與基準方法相比,本文方法在性能上可以有多少提升?

4.1.1 研究動機

在第 1個研究問題中,我們試圖調查本文方法在缺陷自動化關聯(lián)任務中的有效性.此外,由于本文方法結合了TF-IDF和深度學習技術來計算兩個GitHub缺陷文本之間的語義相似性,我們希望分析這種混合式方法是否以及在多大程度上可以改善現(xiàn)有的方法和我們的3種子方法的性能.

4.1.2 分析方法

因為目前并沒有專門針對 GitHub缺陷自動關聯(lián)問題提出的方法,所以我們將本文方法與傳統(tǒng)缺陷跟蹤系統(tǒng)中最先進的方法(NextBug[9])進行比較.NextBug主要基于傳統(tǒng)的IR技術,依靠余弦相似度得分來推薦相似的缺陷報告.此外,為了驗證我們的混合式方法的優(yōu)越性,我們將本文方法與我們的3種子方法(TF-IDF、WE和DE)進行比較.因此,我們在實驗中設置了4種作為參考比照的基準方法:NextBug、TF-IDF、WE和DE.通過分別使用本文方法和基準方法對Request項目和Moment項目缺陷數(shù)據進行訓練、測試,我們比較了不同方法在R@1、R@5、R@10、MAP和MRR評價指標值上的差異.

4.1.3 分析結果

(1) Request項目:圖7給出了在Request項目缺陷數(shù)據中,進行相關缺陷推薦的性能比較結果.

Fig.7 Performance comparison results in Request project圖7 Request項目內各方法性能比較結果

我們發(fā)現(xiàn),本文方法可以實現(xiàn)較高的推薦性能.其中,R@1值為 27.7%;R@5值為 51.2%;R@10值更是達到60.6%,即當推薦10個候選缺陷時,有60.6%的概率候選缺陷即為真正的實際關聯(lián)缺陷.

其次,我們發(fā)現(xiàn)本文方法在所有評價指標上都優(yōu)于NextBug.相對于NextBug的性能值,本文方法在R@1、R@5、R@10、MAP和MRR上分別提升了51.4%、56.1%、42.9%、53.0%和52.0%.

此外我們發(fā)現(xiàn),與我們的3種子方法相比,本文方法在所有指標方面也實現(xiàn)了更好的性能.相對于3種子方法性能值,本文方法分別在R@1、R@5、R@10、MAP和MRR上提升了9.1%～28.8%、15.6%～40.3%、9.4%～19.0%、10.9%～34.2%和10.8%～33.5%.

(2) Moment項目:圖8給出了在Moment項目缺陷數(shù)據中,進行相關缺陷推薦的性能比較結果.

我們同樣發(fā)現(xiàn),本文方法可以實現(xiàn)較高的推薦性能.其中,R@1值為22.2%;R@5值為40.0%;而R@10值達到49.5%,即當推薦10個候選缺陷時,有49.5%的概率候選缺陷即為真正的實際關聯(lián)缺陷.

Fig.8 Performance comparison results in Moment project圖8 Moment項目內各方法性能比較結果

我們同樣發(fā)現(xiàn),本文方法在所有評價指標上都優(yōu)于 NextBug.相對于 NextBug的性能值,本文方法分別在R@1、R@5、R@10、MAP和MRR上提升了41.4%、35.1%、36.0%、40.7%和40.4%.

此外,我們同樣發(fā)現(xiàn),與我們的3種子方法相比,本文方法在所有指標方面也實現(xiàn)了更好的性能.相對于3種子方法性能值,本文方法分別在R@1、R@5、R@10、MAP和MRR上提升了12.7%～47.0%、2.0%～42.3%、2.9%～42.7%、9.0%～45.8%、10.9%～34.2%和9.3%～45.7%.

小結:總的來看,本文方法可以很好地抽取缺陷文檔內單詞和文檔的上下文信息,在推薦性能上要優(yōu)于現(xiàn)有的NextBug方法.此外,混合式的推薦方法在性能上也優(yōu)于單獨的3種子方法.

4.2 RQ2:本文方法對于缺陷語料庫是否有很強的依賴性?

4.2.1 研究動機

在本文方法中,我們從每個項目的缺陷文本中學習語料庫和嵌入模型,這些缺陷語料庫反映了開發(fā)者報告缺陷的方式以及它們使用的詞匯特點.因此,在第 2個研究問題中,我們想要研究從不同項目的缺陷語料庫中學習嵌入模型是否以及在何種程度上會影響本文方法的性能.對該問題的研究將有助于我們理解合適的語料庫對于特定項目相關缺陷推薦任務的重要性.

4.2.2 分析方法

我們通過交叉使用Request項目和Moment項目的缺陷語料庫來驗證本文方法的推薦性能,即對于Request項目和Moment項目,我們分別使用它們自身的缺陷語料庫和另外一個項目的缺陷語料庫來進行測試.

4.2.3 分析結果

(1) Request項目:圖9給出了在Request項目中使用不同項目缺陷語料庫時的性能比較結果.

我們發(fā)現(xiàn),對于 Request項目,與從它自己的缺陷語料庫學習相比,從其他項目的缺陷語料庫中學習會降低本文方法的性能.具體而言,在R@1、R@5、R@10、MAP和MRR上,本文方法的性能分別下降了6.6%、12.6%、14.3%、4.3%和8.2%.

Fig.9 Performance comparison results when using different issue corpus in Request project圖9 Request項目內使用不同缺陷語料庫的性能比較結果

(2) Moment項目:圖10給出了在Moment項目中使用不同項目缺陷語料庫時的性能比較結果.

我們發(fā)現(xiàn),對于 Moment項目,與從它自己的缺陷語料庫學習相比,從其他項目的缺陷語料庫中學習同樣會降低本文方法的性能.具體而言,在R@1、R@5、R@10、MAP和MRR上,本文方法的性能分別下降了5.7%、7.1%、8.7%、2.8%和6.1%.

然而我們發(fā)現(xiàn),雖然使用其他項目的缺陷語料庫時本文方法的性能會下降,但本文方法仍然要優(yōu)于基準方法NextBug.在Request項目中,本文方法在各個評價指標上比NextBug有至少9.2%的提升;在Moment項目中,本文方法在各個評價指標上比NextBug有至少5.1%的提升.

Fig.10 Performance comparison results when using different issue corpus in Moment project圖10 Moment項目內使用不同缺陷語料庫的性能比較結果

小結:實驗結果顯示,特定、合適的項目缺陷語料庫可以給本文方法帶來更好的性能.但是,即便利用其他項目的缺陷語料庫來學習嵌入模型,本文方法的推薦結果仍然具有一定的可靠性.

4.3 RQ3:本文方法對于訓練集規(guī)模的依賴如何?

4.3.1 研究動機

因為本文方法所有的子方法(IF-IDF、WE和DE)都需要在一定規(guī)模的數(shù)據集上進行訓練,所以我們需要考慮訓練集規(guī)模對于本文方法性能的影響.因此,在第 3個研究問題中,我們希望分析本文方法在不同規(guī)模訓練集下性能的變化.

4.3.2 分析方法

我們分別根據Request項目和Moment項目的訓練集規(guī)模,按照10%,20%,…,100%的比例各分為10組訓練集,并對基于不同規(guī)模訓練集訓練得到的模型進行性能測試和比較.

4.3.3 分析結果

圖11和圖12分別顯示了在Request項目和Moment項目中,使用不同規(guī)模的訓練集,本文方法在R@1、R@5、R@10、MAP和MRR上的指標值變化情況.我們發(fā)現(xiàn),與其他機器學習算法相似,本文方法在不同規(guī)模訓練集下的性能存在差異.例如在Request項目中,使用10%缺陷數(shù)據用于訓練,本文方法的R@10值僅為0.25;而當使用90%缺陷數(shù)據用于訓練時,R@10值可達到0.57,非常接近我們前面的測試結果0.61(100%訓練集).同樣,在Moment項目中,使用10%缺陷數(shù)據用于訓練時,本文方法的R@10值僅為0.25;而使用90%缺陷數(shù)據用于訓練時,R@10值可達到0.46,接近我們前面測試結果0.50(100%訓練集).

另外,我們發(fā)現(xiàn),隨著訓練集規(guī)模的增加,在Request項目和Moment項目中,各個指標值均有增長趨勢.這表示大量的模型訓練樣本將有助于進一步提高本文方法的性能.

Fig.11 Performance comparison results when using different scale of training dataset in Request project圖11 Request項目內使用不同規(guī)模訓練數(shù)據集時的性能比較結果

Fig.12 Performance comparison results when using different scale oftraining dataset in Moment project圖12 Moment項目內使用不同規(guī)模訓練數(shù)據集時的性能比較結果

小結:本文方法的性能隨著訓練集規(guī)模不同會產生差異,訓練集規(guī)模越大,本文方法的性能越好.下一步可以設計實現(xiàn)增量式的模型訓練方法,即每次只針對新加入的缺陷數(shù)據進行訓練,從而降低模型的訓練成本.

4.4 RQ4:本文方法的時間開銷如何?

4.4.1 研究動機

因為本文方法所有的子方法(IF-IDF、WE和DE)都需要進行預處理和訓練才能用于實際的推薦任務,因此我們需要考慮模型訓練的時間開銷問題.因此,在第4個研究問題中,我們希望分析本文方法的訓練時間開銷,以了解本文方法的實用性.

4.4.2 分析方法

我們通過記錄程序執(zhí)行的開始時間和結束時間,來獲得本文方法的訓練時間開銷.實驗運行在 Windows 8 OS(64位),8GB RAM,Intel(R)Core(TM)i5 2.6GHz的PC上.

4.4.3 分析結果

在我們的訓練過程中,Request項目包含了2 896個缺陷報告和223 595個單詞(預處理后),其詞匯量(單個單詞數(shù))大小為129 750.而Moment項目包含了4 509個缺陷報告和287 757個單詞,其詞匯量為153 673.圖13給出了本文方法的訓練時間開銷統(tǒng)計結果.

Fig.13 Training time cost in minutes圖13 訓練時間開銷(min)

我們發(fā)現(xiàn),在兩個項目中,TF-IDF子方法比其他兩個子方法都需要更少的訓練時間,因為它只訓練所有缺陷文本的單詞語料庫;而WE和DE子方法都需要訓練單詞和文檔的神經網絡,所以訓練時間較長.從總體結果來看,對于Request項目缺陷的訓練時間開銷僅為4min左右,而對于Moment項目缺陷的訓練時間開銷只需要大約5min.

小結:訓練時間開銷結果表明,本文方法可以被很快地離線訓練,且只需完成一次模型訓練,即可用于相關缺陷的關聯(lián)推薦.較少的訓練時間開銷也說明本文方法具有很強的應用擴展性,我們可以進一步基于本文方法研發(fā)相關工具和插件.

5 案例分析

為了進一步分析本文方法,我們對實際的缺陷鏈接對進行了案例分析.案例1(如圖14所示)給出了request/request#880和 request/request#1005這一缺陷鏈接對.我們發(fā)現(xiàn),這兩個缺陷之間存在許多相同單詞,例如“optional”、“dependencies”和“cookie”.推薦結果表明,NextBug、TF-IDF 和 DE 方法都無法捕獲這兩個缺陷之間的關聯(lián)關系,而WE和本文方法都正確判斷了它們之間的關聯(lián)關系.所以當兩個相關缺陷存在許多相同單詞時,詞嵌入模型可以很好地通過分析單詞之間的上下文語義信息來幫助本文方法捕獲缺陷之間的關聯(lián)關系.

Fig.14 Case study of request/request#880 and request/request#1005圖14 request/request#880和request/request#1005的案例分析

案例2(如圖15所示)給出了缺陷鏈接對request/request#699和request/request#803,我們發(fā)現(xiàn),這兩個缺陷并沒有很多共同的單詞,只有“Error”、“getaddrinfo”和“ENOTFOUND”這幾個單詞相同.

Fig.15 Case study of request/request#699 and request/request#803圖15 request/request#699和request/request#803的案例分析

推薦結果顯示,NextBug、TF-IDF和WE方法都無法捕獲它們的鏈接關系,而DE和本文方法都正確判斷了它們之間的關聯(lián)關系.這表明,當兩個相關缺陷沒有太多文本信息或沒有多個共同單詞時,文檔嵌入模型可以很好地通過分析缺陷文檔之間的上下文語義信息來幫助本文方法捕獲缺陷之間的關聯(lián)關系.

因此,通過案例分析,我們發(fā)現(xiàn)融合詞嵌入模型和文檔嵌入模型后,本文方法可以更好地捕獲兩個相關缺陷之間的關聯(lián)關系.

6 結束語

本文提出了一種基于嵌入模型的混合式相關缺陷關聯(lián)方法,用于在GitHub項目中自動鏈接相關缺陷.本文方法結合了傳統(tǒng)的信息檢索技術(TF-IDF)和深度學習技術(詞嵌入模型和文檔嵌入模型).在我們的實證驗證中,我們將本文方法與NextBug方法(傳統(tǒng)缺陷跟蹤系統(tǒng)中的最先進方法)以及其他3種基準方法(即我們的3種子方法)進行比較.實驗結果表明,本文提出的方法可以很好地融合缺陷語料庫的上下文信息,在性能上要優(yōu)于基準方法.此外,我們發(fā)現(xiàn)本文方法在項目特定的訓練語料庫下有助于提高嵌入模型的性能,即使對于不同項目的缺陷語料庫,本文方法的推薦結果仍能表現(xiàn)一定的可靠性.并且,較短的時間開銷表明本文方法可以有效地進行離線訓練,具有很強的應用擴展性.