即時軟件缺陷預測研究進展?

蔡 亮,范元瑞,鄢 萌,夏 鑫

1(浙江大學 計算機科學與技術學院,浙江 杭州 310007)

2(Faculty of Information Technology,Monash University,Melbourne,VIC 3800,Australia)

研究表明,由于軟件系統的復雜性,軟件缺陷常常不可避免.根據 IEEE標準定義,軟件缺陷是指軟件產品中存在的,導致產品無法滿足軟件需求和其規格要求,需要進行修復的瑕疵、問題[1].軟件缺陷的存在,極大制約了軟件的應用與發展,帶來了大量的經濟損失.根據美國國家標準與技術研究院(National Institute of Standards and Technology,簡稱NIST)估算,由于軟件缺陷給美國帶來的一年經濟損失高達600億美金,NIST通過進一步研究發現,識別和修復這些軟件缺陷,能幫助美國節省220億美金[2].因此,修復缺陷成為軟件維護中的關鍵活動,但它同時需要消耗大量的時間和資源[3].數據表明,修復缺陷所需要的成本占軟件開發總成本的 50%～75%[4].及時地發現缺陷,有助于減少修復缺陷的成本,提高軟件質量.

鑒于此,軟件工程領域的研究者提出了軟件缺陷預測技術,其目的在于提前預測可能存在缺陷的軟件實體(如文件和變更)[5].其基本思路在于從軟件項目的歷史數據中提取特征用來表征被預測的軟件實體,然后將這些特征輸入到分類(或回歸)器進行訓練獲得預測模型,從而對新產生的軟件實體預測其存在缺陷的可能性[6].其研究意義在于:

(1) 優化資源分配,節省維護成本.缺陷預測技術可以對軟件的文件、模塊等計算其存在缺陷的可能性,從而實現對有限開發資源的合理調度,例如,對更有可能出現缺陷的文件和模塊進行更多的審查和測試工作[7].

(2) 及時發現缺陷,提高代碼質量.使用缺陷預測技術,能幫助開發人員及時發現潛在缺陷,及時采取缺陷修復措施,有助于更好的保證軟件質量[8].

軟件缺陷預測研究有超過40年的歷史[9].傳統的缺陷預測技術主要針對粗粒度的軟件實體,例如文件、模塊或包進行預測[8,10-15].這些針對粗粒度軟件實體的技術在實際應用中遇到了挑戰.例如,軟件缺陷預測模型可能會預測一個巨大的文件存在缺陷,但是對于開發者來說,查看整個文件來尋找缺陷非常耗費精力和時間[16].同時,這樣一個巨大的文件可能被很多開發者修改過,因此,尋找一個合適的開發者來對這個文件檢查也是一個非常困難的任務[17].

為了應對上述挑戰,軟件工程領域的研究者提出了即時缺陷預測(just-in-time defect prediction)技術[17-28].即時缺陷預測技術是指預測開發者每次提交的代碼變更(code change)是否存在缺陷的技術[19].在即時缺陷預測技術中,被預測的軟件實體是一次代碼變更.即時缺陷預測技術具有即時性,具體體現在這種預測技術可以在開發者提交一次代碼變更后即對變更代碼進行缺陷分析,預測其存在缺陷的可能性.這種技術可以有效地應對傳統缺陷預測技術面臨的挑戰,主要體現在以下3個方面.

(1) 細粒度.與模塊或文件級缺陷預測相比,變更級預測關注更加細粒度的軟件實體.開發者可以花費更少的時間和精力去審查被預測為有缺陷的代碼變更.

(2) 即時性.即時缺陷預測技術可以在代碼變更提交時進行預測,此時,開發者仍然對變更代碼具有鮮活的記憶,不必花費時間來重新理解自己提交的代碼變更,有助于更及時的修復缺陷.

(3) 易追溯.開發者提交的代碼變更中保存了開發者的信息,因此,項目管理人員可以更便捷地找到引入缺陷的開發者,有助于及時分析缺陷引入原因,幫助完成缺陷分派[19].

上述優勢也吸引了軟件工程領域研究者的廣泛關注,產生了一批即時缺陷預測研究成果.其中,Mockus和Weiss首次提出了在代碼變更層次上進行缺陷預測[29],他們提出的預測技術中,被預測軟件實體是由多次代碼變更提交組成的代碼變更組合.Kim等人在 2008年的 TSE中首次提出了對每次代碼變更進行缺陷預測[17].Kamei等人在2013年的TSE中首次將這種缺陷預測技術稱為即時缺陷預測技術[19].近年來,即時缺陷預測技術由于其細粒度、即時性和可追溯的優勢,成為了缺陷預測領域的研究熱點.在大量工作中,研究者們針對數據標注、特征提取、模型構建、模型評估等方面提出了大量有價值的理論和技術,同時也產生了一些分歧和討論,例如,Yang等人提出了使用簡單無監督的即時缺陷預測技術,取得了比有監督缺陷預測相當或更好的效果[25].針對該成果,有研究者針對其建模技術和模型評估等方面展開了討論,并指出,在模型評估中,需要綜合考慮不同類型的性能指標[26,27].

此外,即時缺陷預測也吸引了來自工業界的關注.例如,Shihab等人針對一家大型軟件公司60個團隊展開了實證研究[18],Kamei等人在 5個公司項目上展開了實證研究[19],展示了即時缺陷預測技術的實用性.由此可見:即時缺陷預測技術己經引起了軟件工程學術界和工業界的關注,產生了一批優秀研究成果,同時也面臨著缺乏統一建模技術和評估指標的挑戰.然而,目前尚沒有研究工作對當前該領域的研究進展進行梳理和歸納,鑒于此,本文擬針對當前即時缺陷技術的研究進展,從數據標注、特征提取、模型構建和模型評估等方面進行梳理、歸納和總結,并總結了當前該領域存在的主要問題和未來的發展方向.

· 文獻選取方式.

本文采用以下流程完成對文獻的索引與選取.

· 首先定義文獻選取標準:該文獻針對即時缺陷預測技術中的數據標注、特征提取、模型構建、模型評估提出新理論、新技術,或者該文獻對即時缺陷預測相關理論和技術提供實證研究支持.

· 此外,該文獻應公開發表在期刊、會議、技術報告或書籍中.

依據以上標準,本文通過以下3個步驟對文獻進行檢索和篩選.

1)本文文獻搜索主要通過ACM Digital Library、IEEE Xplore Digital Library、Springer Link Online Library以及 Google Scholar等.論文檢索的關鍵字包括 just-in-time defect prediction、change level defect prediction、buggy change prediction等,同時在標題、摘要、關鍵詞和索引中進行檢索.

2)本文對軟件工程領域的主要期刊與會議進行在線搜索,具體包括TOSEM、TSE、EMSE、IST、ICSE、FSE、ASE、ICSME、MSR、SANER等,搜索時間從 2008年(即針對每次代碼變更預測缺陷的首次提出時間)開始.

3)本文基于上述步驟所獲取的文獻集合,對文獻逐一查看,從文獻的參考文獻中進一步篩選出與即時缺陷預測理論相關的文獻.

通過以上文獻索引與選取,共計 34篇文獻納入本文后續文獻總結中.其中,19篇文獻與即時缺陷預測技術直接相關,這些文獻為該技術中的數據標注、特征提取、模型構建和評估等方面提出了新理論和新技術;另外15篇文獻對即時缺陷預測相關理論和技術(如特征提取)提供實證研究支持.圖1展示了本文所總結的文獻分布情況,其中包含TSE論文9篇、MSR論文5篇、FSE論文4篇、ICSE論文3篇、ASE論文2篇、ICSM/ICSME論文2篇、其他期刊和會議論文各1篇.

Fig.1 Distribution of surveyed literatures圖1 文獻分布

· 本文整體結構.

本文第1節介紹即時缺陷預測技術的整體技術框架,并從數據標注、特征提取和模型構建等3個方面進行歸納和梳理.第 2節介紹即時缺陷預測模型評估方法,主要從實驗驗證方法和技術評價指標兩方面進行總結和歸納.第 3節總結了即時缺陷預測領域面臨的關鍵問題,包括科學問題、技術難點和工程實現等3個方面.第4節介紹即時缺陷預測技術未來發展趨勢.第5節是對本文的總結.

1 即時缺陷預測技術

圖2展示了即時缺陷預測技術的一般過程,主要包括3個階段:數據標注、特征提取和模型構建.其中,數據標注階段主要依賴于版本控制系統(例如git)和缺陷追蹤系統(例如bugzlla或jira),將代碼變更標注為缺陷變更(buggy)或非缺陷變更(clean);特征提取階段主要通過提取不同維度的特征來表示代碼變更;模型構建階段主要依賴于機器學習技術構建預測模型,當新的代碼變更提交時,模型將預測其缺陷可能性.本節將對上這 3個階段進行詳細描述.

Fig.2 General framework of just-in-time defect prediction圖2 即時缺陷預測技術一般框架

1.1 數據標注

即時缺陷預測技術中的數據標注是指將代碼變更標注為缺陷引入變更和非缺陷引入變更.準確的數據標注,是完成模型訓練和模型評估的前提.

為了實現數據標注,需要利用軟件項目的歷史變更數據,識別缺陷引入變更.識別缺陷引入變更是一個復雜問題,需要考慮代碼的動態演進和代碼變更之間的關聯關系.Sliwerski等人在2005年首次提出了用于自動識別引入缺陷的代碼變更方法,并以它們名字的首字母命名該算法,即SZZ算法[30].

隨后,SZZ算法成為用于從軟件項目代碼倉庫和缺陷倉庫中識別缺陷引入變更的通用框架[30].為即時缺陷預測技術命名的研究者Kamei等人評價SZZ算法是修改了缺陷預測研究領域的游戲規則(game changer),促進了即時缺陷預測技術誕生和發展[31].

SZZ算法的一般框架包含了4個步驟,圖3使用Apache項目ActiveMQ中的一個缺陷(AMQ-1381)作為一個具體的例子來詳細描述這個算法框架的4個步驟.

(1) 識別缺陷修復變更.掃描存儲在版本控制系統的所有歷史數據,即所有代碼變更,識別日志中包含缺陷ID的代碼變更.這些代碼變更被識別為缺陷修復變更.如圖2所示,識別修復AMQ-1381的代碼變更ID為645599.

(2) 識別被修復的缺陷代碼.利用版本控制系統實現的 diff算法來識別上述修復缺陷的代碼變更修改的代碼行.這些被修改的代碼行被識別為缺陷代碼.如圖2所示,被代碼變更#645599修改的代碼中包含一個函數聲明,其中,Command參數類型是錯誤的,它的正確類型是Object而不是Command.

(3) 識別可能的缺陷引入變更.使用代碼版本控制系統中的annotate命令回溯代碼變更提交歷史,第1次引入缺陷代碼的變更被識別為可能的缺陷引入變更.如圖2所示,代碼變更#447068引入了在第2步中發現的錯誤函數聲明.

(4) 噪音數據消除.從可能的缺陷引入變更中去除可能存在的噪音數據.噪音數據是指被誤標記為引入缺陷而實際未引入缺陷的變更(false positive).Sliwerski等人提出,缺陷引入變更應當在該缺陷被報告之前被提交[30].因此,提交時間晚于缺陷報告時間的代碼變更在SZZ實現中會被當作噪音去除.圖2中所示代碼變更#447608的提交時間在缺陷報告創建時間之前,因此,這個代碼變更最終被確認是引入缺陷AMQ-1381的代碼變更.

Fig.3 General framework of the SZZ algorithm圖3 SZZ算法一般框架

由于SZZ算法在眾多軟件工程研究工作中的基礎性地位,研究者開始關注SZZ產生數據的質量[32-34].在這些工作中,研究者們發現原始 SZZ產生的數據存在噪音,進一步地,他們對 SZZ的噪音數據進行處理,提出了不同類型的改進版SZZ實現.為描述方便,本文將Sliwerski等人提出的基礎SZZ實現稱作Basic SZZ,簡稱B-SZZ.

本節對研究者們在B-SZZ基礎上做出不同版本的改進SZZ進行簡要概述.主要包括以下3種.

· Annotation Graph SZZ (AG-SZZ)

Kim等人注意到,B-SZZ在第2步和第3步中都引入了噪音數據.他們發現,B-SZZ在執行第2步時會錯誤地把空行、注釋行以及代碼風格的修改識別為用于缺陷修復代碼;并且,B-SZZ在執行第 3步時錯誤地把對代碼風格的修改識別為引入缺陷的代碼修改.而事實上,這些代碼修改不會對軟件行為造成任何影響.為了避免這些噪音,Kim等人提出 SZZ算法在第 2步中忽略對空行、注釋行以及代碼風格的修改,并且在第 3步中使用Annotation Graph來對代碼變更提交歷史進行追蹤,識別可能的缺陷引入變更[32].其中,Annotation Graph是一種對軟件代碼演進過程的追蹤工具[35],其基本思路在于利用版本控制系統的 diff算法,追蹤每次代碼變更中對代碼的增加、刪除以及修改.因此,Annotation Graph可以幫助SZZ在第3步中發現對代碼風格的修改,忽略這種修改繼續追蹤代碼提交歷史,識別真正引入缺陷的代碼變更.

· Meta-changeAware SZZ (MA-SZZ)

Da Costa等人發現,AG-SZZ產生的數據中仍然存在噪音.他們發現,AG-SZZ會把創建分支、合并分支以及修改文件屬性的代碼變更識別為缺陷引入變更[33].Da Costa等人將創建分支、合并分支以及修改文件屬性的代碼變更稱為元變更(meta-change).事實上,元變更不會對軟件行為造成影響.這種噪音的產生是由于 AG-SZZ在第 3步追溯代碼提交歷史的過程中遇到元變更會被阻斷,從而將元變更識別為引入缺陷的代碼變更.為了去除這些噪音,Da Costa等人在 AG-SZZ的基礎上進行改進,提出元變更感知 SZZ(Meta-change Aware SZZ),簡稱MA-SZZ.MA-SZZ在第3步追蹤代碼變更提交歷史的過程中會忽略元變更,識別真正引入缺陷的代碼變更.

· Refactoring Aware SZZ (RA-SZZ).

Kim等人指出,SZZ可能會將重構代碼變更識別為引入缺陷的代碼變更[32].重構代碼是一種既不會更改軟件的外部行為也不會提升軟件內部結構的代碼修改過程[36].Neto等人對重構代碼對SZZ算法的影響進行了分析[34].他們指出,SZZ在第2步時會錯誤地把代碼重構識別為用于修復缺陷的代碼修改,并且在第3步中會錯誤地把代碼重構識別為引入缺陷的代碼修改.為了處理這些噪音,Neto等人在MA-SZZ的基礎上提出了重構感知SZZ(refactoring aware SZZ),簡稱RA-SZZ.在RA-SZZ中,Neto等人通過將RefDiff工具集成到SZZ中,實現對重構代碼進行檢測.RefDiff是一種用于檢測Java代碼中代碼重構修改的工具[37].RA-SZZ在執行第2步時會忽略由RefDiff檢測出的代碼重構修改,并且在第3步追蹤代碼變更提交歷史過程中,忽略由RefDiff檢測出的代碼重構修改,識別真正引入缺陷的代碼變更.然而,RefDiff在實際使用中存在局限性,因此限制了RA-SZZ的實際應用.比如,RefDiff只能用于檢測Java代碼中的代碼重構,因此對RA-SZZ造成了程序語言的限制.

表1展示了現有工作中研究者們提出的不同數據標注方法及其消除的噪音類型.表中False Positive、False Negative分別指被誤標記而實際未引入缺陷的變更、未被識別出的真正引入缺陷的變更.

Table 1 Summary of different SZZ implementations表1 不同SZZ實現算法概要

1.2 特征提取

在即時缺陷預測技術中,特征提取是指利用代碼變更原始數據計算特征來表征變更的過程.該步驟是即時缺陷預測技術的關鍵步驟.我們分兩小節對特征提取進行描述:第1.2.1節按照時間順序概括即時缺陷預測研究中特征提取技術的研究進展;第 1.2.2節對現有工作提出的特征歸納總結,并將所有特征劃分為 9個維度進行介紹.

1.2.1 特征提取研究進展

即時缺陷預測研究者先后提出了不同類型的變更特征,包括基于變更元數據的特征、基于變更代碼內容的特征、基于軟件演進過程的特征和基于多源軟件制品的特征.本節按照時間的先后順序分別對這4種特征進行概述.

· 基于變更元數據的特征

變更元數據是指描述變更屬性(例如開發者、提交時間、變更日志、修改文件、每個文件增加和減少的代碼行數等)的數據,這些元數據可以直接通過軟件項目變更提交記錄獲取.基于變更元數據,Mockus等人提出了變更增加減少行數、修改文件數量、開發者經驗、變更類型等特征[29].這些特征具有堅實的實證研究基礎[38-41],它們容易理解且計算簡單.由于代碼變更提交記錄可以直接通過軟件項目的版本控制系統獲取,這些特征可以應用到大量軟件項目中,具有普遍性.在后續工作中,這些特征得到了廣泛的使用[17-28].

· 基于變更代碼內容的特征

基于變更元數據的特征對于表征變更是不完整的,這些特征并沒有考慮變更具體修改的代碼內容.因此,研究者們提出了基于變更代碼內容的特征.Kim等人基于實證研究成果,提出了使用代碼復雜度特征來表征變更[17,42,43];同時,他們還使用代碼變更代碼、日志和文件名的詞頻率特征來量化代碼變更內容.Jiang等人提出使用變更提交前后相關代碼文件的抽象語法樹相同類型節點數量的差值表征變更[20],這些特征依賴變更具體的代碼內容.研究者們將這些基于變更代碼內容的特征與基于變更元數據的特征結合,構建預測模型[17,20].

與基于變更元數據的特征相比,基于變更代碼內容的特征數量明顯增加.比如,變更詞頻率特征有成千上萬個[21].特征過多容易造成著名的維度災難問題[44].Shivaji等人指出,特征過多對即時缺陷預測模型產生負面影響,使用特征選擇減少特征數量可以顯著提升預測模型的性能[21].因此,在使用基于變更代碼內容的特征時,需要進行特征選擇.

在計算基于變更代碼內容的特征時,需要先提取變更相關文件在變更提交前后的代碼內容,然后對變更前后的文件內容分別計算復雜度特征和詞頻率特征及構建抽象語法樹[17,20].與基于變更元數據的特征相比,這些特征計算難度較大而且比較費時.對于不同編程語言,代碼復雜度計算以及抽象語法樹構建存在差異,使這些特征的實用性受到影響.

· 基于軟件演進過程的特征

在后續的即時缺陷預測工作中,研究者們受傳統缺陷預測研究的啟發,提出了基于軟件演進過程的變更特征,即基于項目代碼修改歷史量化變更.

傳統的缺陷預測研究表明,基于軟件演進過程的特征(例如文件修改次數)比基于代碼內容的靜態特征對于預測缺陷更加有效[45].Kamei等人提出從文件修改歷史角度提取變更特征,例如變更相關文件被修改的次數、修改變更相關文件的開發者人數等[19].相對于基于變更代碼內容的特征,這些特征數量顯著減少,避免了維度災難問題和模型構建的大量開銷.同時,Kamei等人提出的基于文件修改歷史的特征可以直接通過變更提交歷史記錄計算.因此,這些特征具備普遍性.在后續的即時缺陷預測工作中,這些特征被廣泛應用[22,24-28].

· 基于多源軟件制品的特征

上述 3種變更特征的提取都是基于軟件項目的代碼版本控制系統.近年來,軟件工程研究者發現,即時缺陷預測與多源軟件制品相關.例如變更提交過程中,除版本控制系統外,開發者會在軟件項目多個管理系統對變更進行審查、測試等操作[46].因此,有研究者提出結合多源軟件制品提取多維代碼變更特征來增強即時缺陷預測性能.例如,McIntosh等人首次從項目的代碼審查系統提取特征來表征代碼變更[28].由于現代軟件項目中對代碼審查的廣泛使用,這些基于代碼審查系統的特征具備普遍性.在后續的工作中,它們可能會得到更多的應用.

1.2.2 特征類型

現有的工作中,研究者提取了大量特征用于表征代碼變更.本節在第1.2.1節的基礎上對現有即時缺陷預測研究提出的變更特征進一步歸納總結,第1.2.1節的4種類型變更特征被進一步分為9個維度,包括規模(size)、代碼分布(diffusion)、目標(purpose)、開發者經驗(developer experience)、復雜度(complexity)、文本(text)、代碼結構(structure)、文件修改歷史(file history)和代碼審查(code review).

基于變更元數據的特征包括規模、代碼分布、目標和開發者經驗等特征維度.

· 規模維度:該維度用來表征變更修改代碼的規模.

Moser等人觀察到:變更修改代碼規模越大,越有可能引入缺陷[45].現有的工作中,研究者們都使用變更增加、減少代碼行數來量化變更規模[17-24,28,29].此外,研究者們使用其他粒度對變更代碼規模進行量化.Shihab等人提出使用變更增加和減少代碼段(chunk)數來量化變更規模[18].Kamei等人提出使用變更提交前變更相關文件代碼行數量化變更規模[19].同時,Kamei等人發現,變更增加行數和減少代碼行數是高度相關的.為了避免這種相關性對預測模型造成影響,Kamei等人提出使用相對增加行數和相對減少行數量化變更規模.相對增加行數、相對減少行數分別指變更實際增加、減少行數與變更提交前其相關文件代碼行數的比值[47].

· 代碼分布維度:該維度用來表征變更修改代碼在相關文件中的分布.

研究表明,對于修改代碼分布在多個文件的變更,其開發者需要理解更多代碼,因此,這種更加分散的代碼變更有可能引入缺陷[48].Kamei等人提出使用變更修改的文件數量、文件夾數量和子系統數量等特征來量化變更代碼分布[19].Hassan提出使用變更代碼分布的信息熵(entropy)預測缺陷,并且驗證了該特征的有效性[11].因此,Kamei等人提出使用該特征對有缺陷變更進行預測[19].

· 目標維度:該維度用來表征提交代碼變更的目標.

開發者提交變更的目標包括修復缺陷、實現新功能、重構、增加文檔等[49].研究表明,修改缺陷的變更比其他類型變更更復雜,更有可能引入缺陷[30].因此,在大量即時缺陷預測工作中,研究者利用變更是否修復缺陷作為特征[18,19,22,24,28].此外,Shihab等人還提出使用變更相關缺陷報告的數量來量化代碼變更目標[18].

· 開發者經驗維度:該維度用來量化代碼變更的開發者經驗.

研究表明,開發者經驗會影響軟件質量[50].在即時缺陷預測工作中,研究者都利用變更開發者己提交變更數量量化開發者經驗[17-24,28].此外,Kamei等人提出使用開發者近期提交變更的數量以及變更提交前,開發者己提交變更中影響該變更相關子系統的變更數量量化開發者經驗[19].McIntosh等人提出使用變更提交前,開發者己提交變更中影響該變更相關子系統的變更占版本控制系統中所有影響這些子系統變更的比例,來量化開發者對這些子系統的開發經驗[28].

表2中歸納了基于變更元數據的特征及其使用動機.

Table 2 Summary of features based on meta-data of changes表2 基于變更元數據的特征概要

基于變更代碼內容的特征包括復雜度、文本和代碼結構等特征維度.

· 復雜度維度:該維度用來表征變更修改代碼的復雜度.

在傳統的缺陷預測工作中,研究者們通常使用文件或者模塊代碼的復雜度來預測文件或者模塊中是否存在缺陷[43,51].研究者發現,越復雜的代碼越容易引入缺陷[52].Kim等人將描述文件代碼復雜度的特征引入到即時缺陷預測技術中[17].為了量化變更引起的代碼復雜度變化,他們對變更提交前后該變更相關文件的代碼內容分別計算了61個復雜度指標,計算對應復雜度指標的差值作為特征對有缺陷變更進行預測.

· 文本維度:該維度利用詞袋(bag of words)模型從變更修改代碼、日志和文件名中提取詞頻率特征.

詞袋模型是一種將文本表示為詞頻率向量的方法[53].Kim等人將變更文本特征引入到即時缺陷預測技術中[17].對于變更日志和相關目錄名、文件名,他們利用詞袋模型將它們轉換為詞頻率向量.為了量化變更引起的代碼內容變化,他們對變更前后該變更相關文件的代碼內容分別計算詞頻率特征,計算相應詞頻率的差值,并且使用這些差值作為變更特征.

· 代碼結構維度:該維度用于量化代碼變更前后代碼結構的差異.

即時缺陷預測研究者通過抽象語法樹(abstract syntax tree,簡稱AST)來量化代碼的結構,從而計算代碼變更前后的代碼結構差異[20,23].抽象語法樹是一種表示源代碼抽象結構的工具[54].在抽象語法樹中,源代碼中的條件語句、循環語句和函數等表示為不同類型的節點.Jiang等人提出使用在變更提交前后,該變更相關文件抽象語法樹中相同類型節點的數量差量化變更引起的代碼結構變化[20].

表3中歸納了基于變更代碼內容的特征及其使用動機.

Table 3 Summary of features based on changed code表3 基于變更代碼內容的特征概要

基于軟件演進過程的特征包括文本修改歷史維度.

· 文件修改歷史維度:該維度用來量化變更相關文件的修改歷史.

實證研究表明,文件修改歷史越復雜(例如被多次修改、被多個開發者修改等),其越有可能存在缺陷[45,55,56].鑒于此,即時缺陷預測研究者提出使用變更提交前變更相關文件的修改次數、修改這些文件的開發者人數作為特征量化文件修改歷史對有缺陷變更進行預測[18,19,22,24,28].此外,Shihab等人提出使用修改變更相關文件的歷史變更中缺陷修復變更的數量量化變更相關文件的修改歷史[18].Kamei等人提出使用變更提交前修改該變更相關文件的最近變更與該變更的時間差作為特征量化變更文件的修改歷史[19].

表4中歸納了基于軟件演進過程的特征及其使用動機.

Table 4 Summary of features based on software evolution process表4 基于軟件演進過程的特征概要

基于多源軟件制品的特征包括代碼審查維度.

· 代碼審查維度:該維度用來量化變更被合并到項目代碼倉庫前的代碼審查過程.

近年來,現代代碼審查被廣泛應用到開源與商業項目中.實證研究表明,代碼審查質量與軟件缺陷相關[57].因此,McIntosh等人將代碼審查過程的特征引入到即時缺陷預測研究中.他們提出,使用變更審查過程中變更被重復修正的次數、審查人數、審查意見數量以及審查時間等特征來量化對變更的代碼審查質量[28].

表5中歸納了基于多源軟件制品的特征及其使用動機.

Table 5 Summary of features based on different artifacts of multiple repositories表5 基于多源軟件制品的特征概要

1.3 模型構建

現有的即時缺陷預測技術模型構建方法主要包括兩種類型:有監督(supervised)建模技術和無監督(unsupervised)建模技術[27].本節將分別對有監督和無監督即時缺陷預測兩種建模技術進行介紹.

1.3.1 有監督建模

有監督即時缺陷預測是指利用有監督機器學習方法,從己知標簽(標簽即是否存在缺陷)的代碼變更數據中學習,從而構建預測模型的建模技術.現有工作中,大多數即時缺陷預測工作使用了有監督建模技術[17-20,22-24,28].其一般過程包括:

(1) 數據標注.利用數據標注技術,將歷史代碼變更標記為有缺陷或無缺陷.

(2) 特征提取.從代碼變更的不同角度提取特征,并用特征向量來表示每個代碼變更.

(3) 模型訓練.利用有監督機器學習技術,從標注后的代碼變更數據中學習,構建分類或回歸模型.

(4) 模型應用.當有新的代碼變更提交時,應用預測模型預測該代碼變更存在缺陷的可能性.

此外,根據訓練數據的來源不同,有監督即時缺陷預測又可以分為同項目(within-project)即時缺陷預測和跨項目(cross-project)即時缺陷預測兩種建模技術.

· 同項目即時缺陷預測.

同項目即時缺陷預測是指訓練數據與測試數據來自同一個項目,即:使用同項目的歷史代碼變更數據進行訓練,利用有監督學習技術構建預測模型[17-21,23,26-28].要使預測模型取得良好的性能,其前提條件是預測目標項目中擁有足夠多的歷史數據.現代大型軟件項目中都存在大量變更數據,為同項目即時缺陷預測建模技術提供了數據基礎.而同一個項目中引入缺陷的代碼修改具備相似性,使用預測目標項目的歷史數據來構建預測模型可以取得較高的性能.因此,大量即時缺陷技術的應用研究都采用了同項目即時缺陷預測技術[18-21,23,28].

然而,同項目即時缺陷預測技術的缺點在于:如果預測目標項目是新項目,這樣的項目無法為同項目即時缺陷預測技術提供足量已知標簽的歷史數據用于訓練模型[22,24].

· 跨項目即時缺陷預測.

為應對項目內的即時缺陷預測技術在對新項目預測時缺乏訓練數據的問題,軟件工程領域的研究者提出了跨項目即時缺陷預測建模技術[22,24].跨項目即時缺陷預測建模技術是指訓練數據與測試數據來自不同項目,即:使用其他項目的歷史變更數據訓練預測模型,利用該模型在目標項目上完成預測[22,24].

Fukushima等人首次提出并研究了跨項目即時缺陷預測技術[22],他們在后續工作中對這一技術進行了進一步分析[24].這些分析研究表明,與同項目即時缺陷預測技術相比,跨項目即時缺陷預測技術在大多數情況下存在著性能劣勢.為了應對跨項目即時缺陷預測技術的性能劣勢,他們提出了 3種方法可以有效提高跨項目即時缺陷預測技術的性能:1) 使用相似的軟件項目變更數據作為訓練集;2) 使用多個項目融合后的變更數據作為訓練集;3) 使用多個項目的變更數據分別作為訓練集訓練模型,在預測時以投票方式獲得預測結果.這些研究成果為實踐中跨項目即時缺陷預測的應用提供了指導.

1.3.2 無監督建模

有監督即時缺陷預測技術的缺點在于需要消耗大量的資源,因為有監督建模技術需要利用大量已知標簽的訓練數據來訓練預測模型[25].為應對這一挑戰,研究者提出了無監督即時缺陷預測技術[25].

無監督即時缺陷預測是指利用未知標簽變更數據構建預測模型的技術.與有監督即時缺陷預測建模技術相比,無監督即時缺陷預測建模技術的優點在于更符合實際使用過程的需要.無監督的預測模型在構建時不需要使用有標簽的數據,因此節省了數據標注的開銷.其一般過程包括:

(1) 特征提取.從代碼變更的不同角度提取特征,并用特征向量來表示每個代碼變更.

(2) 模型構建.基于代碼變更特征構建無監督模型.目前,在即時缺陷預測領域,主要是基于變更特征排序的方法,這種方法通過對新提交的變更排序,對開發者審查任務進行調度,使開發者在審查一定量代碼情況下找到更多缺陷,即工作量感知的即時缺陷預測.

Yang等人首次提出了無監督即時缺陷預測建模技術[25].實證研究表明,代碼存在缺陷數量與代碼規模具有對數關系[16].因此,與規模巨大的代碼變更相比,審查小變更時發現缺陷所需工作量更少.Yang等人基于該發現,提出了基于變更特征排序的方法,使開發者按照該排序審查變更代碼時,在一定審查工作量下找到更多缺陷.比如,使用變更修改文件數量作為排序的特征,將文件數量少的變更排在更高的優先級.Yang等人對 12個變更特征分別建立類似的無監督模型,然后在 6個項目數據上進行驗證后發現,部分無監督模型相對于有監督即時缺陷預測模型能夠對開發者代碼審查工作進行更合理的調度.同樣檢查占總共修改代碼行數 20%的代碼,與有監督即時缺陷預測模型相比,無監督即時缺陷預測模型能夠使開發者檢查到更多缺陷引入變更.

Yang等人提出的無監督即時缺陷預測技術引起了相關研究者的關注,Huang等人和 Fu等人分別對 Yang等人的無監督即時缺陷預測建模技術做了進一步的分析[26,27].這些研究通過將無監督和有監督建模技術的分析,揭示了無監督即時缺陷預測建模技術的缺點,主要體現在以下幾個方面:首先,同樣檢查 20%的代碼,無監督缺陷預測模型向開發者推薦的可能引入缺陷的變更數量遠遠超過有監督即時缺陷預測模型,而檢查更多代碼變更需要消耗更多人力、物力[26];其次,無監督缺陷預測模型誤報率比有監督缺陷預測模型高很多[26].Fu等人指出先使用有標簽的訓練數據選擇合適的特征,然后實施Yang等人的無監督方法,能夠達到更好的效果[27].

盡管Yang等人提出的無監督即時缺陷預測建模技術有上述缺陷,他們提出的對于有監督即時缺陷預測建模技術所面臨的挑戰是需要研究者重視的,并且他們提出無監督即時缺陷預測建模技術可以作為可選解決方案在實際中運用.

2 即時缺陷預測評估方法

在即時缺陷預測工作中,為了驗證和對比模型效果,研究者需要對提出的缺陷預測模型進行實驗驗證,并通過不同的評價指標對模型性能進行評估.本節將詳細介紹在即時缺陷預測研究中使用的實驗驗證方法和性能指標.

2.1 實驗驗證方法

實驗驗證方法是指在模型評估中如何將數據集劃分為訓練集和測試集.本節詳細描述當前即時缺陷預測研究中的常用的兩種實驗驗證方法:交叉驗證(cross validation)和對時間感知(time-wise)的驗證方法.

2.1.1 交叉驗證

交叉驗證是機器學習領域常用的模型驗證方法[58].大部分的即時缺陷預測的工作都采用了10折交叉驗證的方法[17-22,24].此外,Yang等人使用了10次10折交叉驗證方法驗證缺陷預測模型的性能[25].在10折交叉驗證中,首先需要隨機打亂數據集,然后將數據集分為10等份,即10折,之后,對每1折都作為測試集,另外9折作為訓練集,訓練預測模型并進行驗證計算性能指標,一共運行 10次實驗,最后將每次得到的性能指標求平均值作為10折交叉驗證的評估結果.而在10次10折交叉驗證中,則是將上述10折交叉驗證運行10次,一共運行10×10次實驗,將每次得到的性能指標求平均值作為10次10折交叉驗證的評估結果.

2.1.2 時間感知驗證

近年來,研究者對即時缺陷預測的驗證方法有了更多的關注與爭論[23,28].Tan等人指出,交叉驗證方法對于即時缺陷預測技術是不適合的,因為變更數據產生具有時間順序,在交叉驗證中隨機打亂數據集進行數據劃分,會導致預測模型使用未來代碼變更信息來預測過去代碼變更的標簽,從而高估預測模型的性能[23].McInstosh等人發現,引入缺陷代碼變更的性質會隨著時間改變[28].這種改變會影響即時缺陷預測模型的性能,比如,使用一年前的變更數據構建預測模型會顯著降低模型的性能.McIntosh等人強調,應當使用近期產生的數據來對新變更進行預測.

Yang等人針對即時缺陷預測提出了一種時間感知的驗證方法[25],這種驗證方法首先對數據集按照創建的順序來排序,然后對數據集分組,在1個月內創建的數據被分為1組.在這種驗證方法中,訓練模型所用的數據集和測試所用的數據都是連續兩個月內創建的變更數據,但是訓練集和測試集之間則間隔了 2個月.比如,使用 1月和2月創建的代碼變更來預測5月和6月創建的代碼變更.這樣驗證有以下4點考慮:1) 大多數項目的開發周期是6星期～8星期;2) 每個訓練集和測試集之間都會有兩個月的時間差,這樣訓練集中的缺陷在這2個月中會被更多地被開發者發現;3) 使用連續兩個月創建的數據,保證訓練集中有足夠多的數據用于訓練模型;4) 允許在一個項目中運行多次實驗保證計算出的結果的可靠性.Huang等人和Fu等人也都采用了上述這種對時間感知的驗證方法[26,27].

2.2 評價指標

針對模型預測結果,研究者提出了不同的指標來量化模型預測效果.本節詳細闡述在即時缺陷預測研究中常用的性能指標,包括機器學習領域常用的查準率(precision)、查全率(recall)、F1-measure、正確率(accuracy)、AUC以及軟件工程領域的研究者提出的工作量感知(effort-aware)指標.

2.2.1 查準率、查全率、正確率和F1-measure

查準率、查全率、F1-measure和正確率是機器學習領域常用的評估預測模型的性能指標[58],大量的即時缺陷預測研究都使用了這些性能指標[17-21,23],其具體計算方法如下.

預測模型對于一個代碼變更的預測結果有 4種可能性:1) 將一個有缺陷的代碼變更預測為有缺陷(true positive,簡稱TP);2) 將一個有缺陷的代碼變更預測為沒有缺陷(false positive,簡稱FP);3) 將一個沒有缺陷的代碼變更預測為沒有缺陷(true negative,簡稱TN);4) 將一個沒有缺陷的代碼變更預測為有缺陷(false negative,簡稱FN).根據預測模型在測試集中這4種預測結果的數量,即可對精確率、召回率、正確率和F1-measure進行計算.由于即時缺陷預測研究更加關注有缺陷變更的預測效果,因此本文所描述的查準率、查全率和F1-measure都是針對有缺陷的代碼變更.

· 查準率(precision)是指所有被正確分類的有缺陷變更占所有被分類為有缺陷變更的比例.

· 查全率(recall)是指所有被正確分類的有缺陷變更占所有真正有缺陷變更的比例.

·F1-measure是結合了精確率和召回率的綜合性性能指標,它是精確率和召回率的調和平均.

· 正確率(accuracy)是指被正確分類的代碼變更占所有代碼變更的比例.

由于在即時缺陷預測的數據中沒有缺陷的代碼變更數量遠大于有缺陷的代碼變更的數量,預測模型的正確率可能非常高,但這并不意味著預測模型性能好.在評估缺陷預測模型時,即時缺陷預測技術的研究者都會綜合考慮查準率、查全率、F1-measure和正確率的結果.

2.2.2 AUC

在即時缺陷預測研究中,AUC也是常用的性能指標[19,21,22,24,28].AUC即Area Under the Curve of receiver operating characteristic,指受試者工作曲線(receiver operating characteristic curve,簡稱ROC)下的面積.ROC曲線是TP的比率(true positive rate,簡稱TPR)在所有的閾值(threshold)上以FP的比率(false positive rate,簡稱FPR)為變量的函數曲線.預測模型需要使用一個閾值來對代碼變更的標簽進行判斷.閾值的取值范圍是 0到 1.在預測模型對一個代碼變更進行預測時,該模型會對代碼變更包含缺陷計算概率值.為了得到預測結果(代碼變更有缺陷或者沒有缺陷),該模型對概率值與該閾值進行比較:如果概率值大于閾值,則模型將代碼變更預測為有缺陷;反之,則將代碼變更預測為沒有缺陷.這樣,就可以算出 TP、FP、TN和 FN的數量.因此,查準率、查全率、F1-measure以及正確率的計算都依賴于預測模型的閾值[18,22].

由于ROC是TPR在所有閾值上以FPR為變量的函數曲線,因此ROC不依賴于閾值.而AUC是ROC曲線下的面積,因此AUC值也不依賴于閾值[18,22].Lessmann等人指出,AUC對于不平衡的數據是魯棒的[10].AUC的計算中自動考慮了數據中存在的不平衡.AUC有一個統計上的解釋[10].在即時缺陷預測上下文中,AUC可以評估預測模型對一個隨機抽取有缺陷變更計算有缺陷概率比對一個隨機抽取沒有缺陷的代碼變更計算有缺陷概率高的可能性.而在實際應用中,開發者會利用預測模型的輸出結果來對工作進行調度,AUC適合于對這種調度進行評估.

2.2.3 工作量感知(effort-aware)指標

軟件工程領域的研究者發現,機器學習領域提出的性能指標不能完全滿足他們對于模型實際應用時的性能評估需求.由于缺陷預測是為了輔助代碼審查,在實際開發中,開發者只有有限的時間和資源用來審查代碼.在有限資源下,如何使開發者檢查到更多的缺陷是即時缺陷預測的關鍵問題.因此,研究者提出使用工作量感知(effort-aware or cost-effectiveness)指標對即時缺陷預測技術進行性能評估.

工作量感知指標是指當開發者根據預測模型的預測結果進行代碼審查時,審查一定數量的代碼(即工作量)所能檢查到的缺陷數量或者比例[59].在即時缺陷預測工作中,研究者通常將代碼審查工作量設置為所有變更修改代碼總行的 20%,并且提出使用在檢查 20%代碼的情況下來計算查準率(Precision@20%)、查全率(Recall@20%)、F1-measure(F1@20%)[19,20,25-27].這些工作量感知的性能指標具體定義如下.

·Precision@20%是指檢查20%代碼中找到的有缺陷變更占這20%所包含全部代碼變更的比例.

·Recall@20%是指檢查20%代碼中找到的有缺陷變更占整個數據集中所有有缺陷變更的比例.

·F1@20%與第3.2.1節中F1-measure的定義類似,是Precision20%和Recall20%的調和平均,即

這 3個性能指標對有監督和無監督即時缺陷預測模型都適用.在這 3個指標中,即時缺陷預測研究中最常用的是Recall@20%[19,20,25-27].Yang等人在其研究中發現,無監督即時缺陷預測技術在Recall@20%比有監督即時缺陷預測技術更加出色[25].Huang等人和 Fu等人復現了 Yang等人的實驗,并且使用了Precision@20%,Recall@20%和F1@20%對有監督和無監督即時缺陷預測技術進行評估.他們發現,無監督即時缺陷預測技術在Precision@20%和F1@20%兩個指標上效果比有監督即時缺陷預測技術效果差.這些研究表明,評估即時缺陷預測技術應當綜合考慮Precision@20%,Recall@20%和F1@20%.

除了上述3個性能指標外,即時缺陷預測技術研究還提出了其他性能指標.Jiang等人提出使用檢查20%代碼中找到的有缺陷變更數量來對即時缺陷預測技術進行評估[20].Huang等人發現,僅僅使用查看代碼的行數并不能完整地描述開發者的工作量[26].他們指出,評估開發者工作量還需要考慮到開發者在查看 20%的代碼行數時所查看代碼變更的數量.開發者在查看大量的代碼變更時,可能需要頻繁地在不同代碼變更中切換,并且不同的代碼變更可能會對不同文件和模塊進行修改,因此,審查大量變更要求開發者之間進行更多合作與交流.這種上下文切換和合作交流也會占用開發資源.同時,Huang等人還指出,如果預測模型將不存在缺陷的代碼變更預測為有缺陷,開發者可能就會放棄這個預測模型[26].因此,他們提出兩個新指標來對即時缺陷預測進行評估:PCI@20%和IFA.PCI@20%是指檢查20%代碼中包含的代碼變更占項目中所有代碼變更的比例;IFA是指在找到第1個有缺陷變更之前,缺陷預測模型為開發者推薦錯誤代碼變更(預測為有缺陷而實際沒有缺陷)的數量.

3 即時缺陷預測技術的關鍵問題

雖然即時缺陷預測技術近年來獲得了大量研究者的關注,取得了較大進展,但仍然存在一些亟待解決的關鍵問題.本節將從科學問題、技術難點和工程實踐這3個方面闡述目前即時缺陷預測技術中存在的問題.

3.1 科學問題

3.1.1 缺陷的可解釋性

現有的即時缺陷預測技術只對變更存在缺陷的可能性進行預測,而針對所預測缺陷具體是什么,如缺陷類型和位置,目前尚沒有相關研究.缺陷類型刻畫了缺陷產生的原因和特點[60],缺陷位置指缺陷所在的模塊、文件、函數甚至代碼行,掌握缺陷類型和位置有助于輔助開發人員快速修復缺陷.盡管目前研究者己提出大量缺陷分類[60-64]和缺陷定位[65-71]技術,針對即時缺陷預測的缺陷分類和缺陷定位,目前尚沒有相關研究.其原因在于:現有的缺陷分類和缺陷定位技術均依賴于缺陷具體信息,如缺陷報告或程序執行記錄,而即時缺陷預測所預測出的缺陷由于其即時性,缺陷尚未暴露且沒有相關缺陷報告或執行記錄,因此需要深入分析缺陷引入變更,研究缺陷的可解釋性,并進一步研究即時缺陷定位.

3.1.2 缺陷預測結果的實用性

現有的即時缺陷預測技術主要有兩種類型的結果:一種是面向分類的預測結果,即每當有新的代碼變更提交時,模型預測其為有缺陷或沒有預測兩個類別[17];另一種是面向優先級排序的結果,即模型對新提交的軟件變更集合進行排序,排在列表前面的表示缺陷可能性更高[19,25].面向分類的預測技術常常采用分類器指標進行評估,面向排序的預測技術常常采用工作量感知的指標進行評估.然而,針對軟件開發或維護過程中如何有效利用即時缺陷預測結果尚沒有統一的觀點,因此需要展開深入的實證研究,以調研開發者實際需要哪種類型的預測結果,如何能更有效地利用即時缺陷預測結果等問題.

3.2 技術難點

3.2.1 數據標注

如何準確地標注引入缺陷的軟件變更是即時缺陷預測中的技術難點之一.近年來,研究者指出傳統 SZZ算法實現存在噪音.傳統 SZZ實現會將修改空行和注釋行以及代碼風格的變更、重構類變更誤標記為引入缺陷變更[32,34].針對這些噪音,研究者提出了多種改進的SZZ實現,然而這些SZZ實現并不能完全消除噪音[32-34].例如,Neto等人提出重構感知 SZZ避免重構類變更被誤標記為引入缺陷,但他們仍然指出,該 SZZ實現對部分重構類變更仍然無法識別[34].同時,這些工作是基于Java代碼對SZZ實現進行改進.不同編程語言在注釋、代碼風格和重構等方面存在差異.因此,研究者提出的改進SZZ實現在非Java項目上面臨實際應用上的挑戰.

3.2.2 特征提取

特征提取的準確性和多樣性對模型的建立有著至關重要的影響.

特征提取準確性的難點在于代碼變更的復雜性,主要體現在兩個方面:一是代碼變更具有時間戳,在計算變更特征時需要考慮軟件的動態演化,包括代碼演化和開發者演化;二是代碼變更提交的復雜性,軟件開發和維護常采用代碼版本控制系統(例如 git),在項目采用多個分支進行同時開發時,提取特征時對代碼變更合并、關聯和追溯分析進行綜合考慮是一大技術難點.

特征提取多樣性的難點在于軟件制品的多源異構特性.研究表明,軟件缺陷與多種軟件制品相關,包括源代碼、缺陷報告、測試報告、代碼審查、代碼靜態掃描等,提取多源特征有助于更準確地刻畫缺陷,從而建立更準確的預測模型.然而上述軟件制品以多源異構的形式存儲在不同的軟件倉庫中,考慮它們之間異構性、關聯性是一大技術難點.

3.2.3 模型構建

現有的即時缺陷預測技術在模型構建上存在著不同的策略.研究者使用復雜的有監督機器學習模型,包括集成學習[72]和深度學習[73],有研究者主張使用簡單的無監督模型[25].在有監督學習模型中,有研究者使用分類模型[17],有研究者使用回歸模型[19].不同的建模技術在模型應用場景、模型輸出結果上存在差異,而關于哪種建模技術是更好的即時缺陷預測模型構建技術尚沒有統一的結論,因此,在模型構建技術上如何選擇合適的建模技術,如何設計更先進的建模技術仍然需要進一步研究.

3.3 工程實踐

盡管目前存在的相關工作將即時缺陷預測引入至工業界[18,19],然而將即時缺陷預測在工程實踐中進行大規模推廣仍然存在以下挑戰.

(1) 缺乏準確的數據環境.在即時缺陷預測的數據標注中,識別引入缺陷的軟件變更時,依賴于開發人員撰寫的變更提交日志(commit log)和缺陷報告.倘若在工程實踐過程中這些數據不夠準確,將對模型的訓練帶來巨大挑戰.

(2) 缺乏多維的數據特征.由于軟件缺陷的復雜性,其產生機制與多源異構的軟件制品相關,如源代碼、缺陷報告、測試報告、代碼審查報告、代碼靜態掃描等,在工程實踐中,軟件制品的多樣性和準確性將直接影響模型效果.

(3) 缺乏統一的評估方法.由于目前針對即時缺陷預測技術模型評估存在著指標多樣化問題,在工程實踐中也將面臨如何更客觀地評估模型這一問題.因此,需要更多工作關注即時缺陷預測的工程實踐,將工程實踐與理論研究相結合,將實證研究和方法研究相結合,進一步完善即時缺陷預測技術.

4 即時缺陷預測的未來展望

針對上一節所總結的關鍵問題,本節圍繞數據標注、特征提取、模型構建和工程實踐等4個方面展望即時缺陷預測研究的未來趨勢.

4.1 加強噪音數據的處理,提出更準確的數據標注方法

實證研究表明,即時缺陷預測研究中所使用的標注數據是存在噪音的.Bachmann等人的研究表明,開發者可能不會為修復缺陷的代碼變更記錄其對應的缺陷報告 ID,從而導致部分修復缺陷的代碼變更無法被識別出來[74].這將導致這些修復缺陷的代碼變更所對應的引入缺陷的代碼變更也無法識別出來.Da Costa等人在他們的工作中提出了一種框架用于評估SZZ算法產生數據的質量,他們使用該框架發現,使用SZZ算法所標注的數據中存在大量噪音[33].另外,實證研究還表明,有些缺陷在引入數年后才會被發現[75].這意味著在對即時缺陷預測技術進行實際應用時,對于近期產生的代碼變更,其中某些缺陷引入變更可能還沒有被修復,因此無法被 SZZ算法識別,這也會造成噪音數據.處理這些噪音數據,并且減小噪音數據對即時缺陷預測模型的影響,將進一步提升即時缺陷預測技術的實用性.

4.2 綜合考慮多源軟件制品,提取多維特征

現代大型軟件項目都會使用多個系統對軟件開發和維護中產生的數據進行存儲和管理,例如代碼版本控制系統(如 git)、缺陷跟蹤系統(如 bugzilla)、代碼審查系統(如 gerrit)等.這些不同的系統中存儲著不同的軟件制品,現有的大部分即時缺陷預測研究都只考慮了從代碼版本控制系統中提取特征.而研究表明,軟件缺陷的產生是一個復雜過程,并與多種軟件制品相關,包括源代碼、缺陷報告、測試報告、代碼審查、代碼靜態掃描等,綜合考慮多源異構的軟件制品,有助于更立體地刻畫缺陷產生機制,建立更準確的缺陷預測模型.例如,有研究人員己經發現,結合代碼審查系統,從代碼審查的角度提取新的特征,有助于增強現有即時缺陷預測模型的預測效果[28].因此,綜合考慮多源軟件制品,提取多維特征來增強特征表征能力,將是即時缺陷預測技術的一個發展方向.

4.3 研究更先進的建模技術,取得建模技術上的突破

近年來,深度學習成為機器學習的熱點研究領域,被大量應用到如圖像處理、語音識別等研究中[76-78].與傳統的機器學習技術相比,研究者發現深度學習在這些領域的應用可以取得更好的性能.Yang等人首次在即時缺陷預測中應用深度學習技術[73],他們使用深度學習方法對初始的變更特征進行整合,從而生成更加復雜的特征,然后基于這些生成的特征構建分類器對有缺陷變更進行預測.他們發現,使用深度學習技術顯著提升了即時缺陷預測模型的性能.但是他們僅使用了深度學習中的深度信念網絡[79]技術用于整合特征.而將目前機器學習領域大量研究與應用的技術,如卷積神經網絡(convolutional neural network,簡稱CNN)[80]應用到即時缺陷預測技術中,將有可能進一步提升即時缺陷預測技術的性能.如何有效地將這些技術應用到即時缺陷預測技術中,需要未來工作進一步分析與研究.

4.4 解決實踐中的工程問題,推動即時缺陷預測的廣泛應用

在工程實踐中,實現自動化、大規模的即時缺陷預測,在數據環境準備、特征提取和模型構建等方面仍然面臨許多技術難點.克服現有難點主要從以下幾方面展開:(1) 積極研究大規模代碼變更數據自動化標注方法,盡快構建面向即時缺陷預測的大數據環境及其演進方法;(2) 解決在工程實踐中多源異構軟件制品的關聯問題,提出代碼變更的多維特征提取方法;(3) 結合更先進的機器學習技術,提出適應于工程實踐中面向大規模代碼變更數據的建模方法;(4) 建立即時缺陷預測的標準評估體系,推動即時缺陷預測向更統一更準確的方向發展;(5) 為了適應云計算、移動互聯網及人工智能的快速發展,有針對性地研究面向不同軟件類型的即時缺陷預測技術.

5 總 結

近年來,即時缺陷預測技術由于其即時性、細粒度和可追溯的優勢,成為了軟件缺陷預測領域的研究熱點.本文圍繞即時缺陷預測的數據標注、特征提取、模型構建及模型評估等方面,梳理并總結了當前研究進展.基于當前進展分析,本文總結了當前即時缺陷預測面臨的關鍵問題及未來發展趨勢.主要工作總結如下.

(1) 針對數據標注,本文詳細歸納了不同數據標注方法的提出背景及其優缺點;針對特征提取,本文分類并詳細介紹了不同維度的變更特征;針對模型構建,本文歸類了現有模型構建技術,包括有監督和無監督建模技術,其中,有監督建模技術又分為同項目建模和跨項目建模;針對模型評估,本文總結了現有不同類型的驗證方法和評估指標.

(2) 本文從科學問題、技術難點和工程實踐這3個角度總結了當前即時缺陷預測面臨的關鍵問題.

(3) 本文圍繞數據標注、特征提取、模型構建和工程實踐這4個方面展望了未來即時缺陷預測技術的發展趨勢.