基于模板的軟件缺陷修復(fù)推薦方法

薄莉莉，朱軒銳，孫小兵

1(揚州大學(xué) 信息工程學(xué)院，江蘇 揚州 225127)

2(江蘇省知識管理與智能服務(wù)工程研究中心，江蘇 揚州 225127)

3(計算機軟件新技術(shù)國家重點實驗室(南京大學(xué))，南京 210023)

1 引 言

軟件缺陷種類繁多，產(chǎn)生原因多樣，造成結(jié)果復(fù)雜多變.往往缺陷的修復(fù)歷經(jīng)不止一次的操作.通常，針對缺陷修復(fù)的問題，使用bug修復(fù)模板可以更快速地輔助開發(fā)人員解決缺陷問題.

早期的研究提出基于軟件缺陷模式產(chǎn)生有效的模板補丁來更準(zhǔn)確、更快速地修復(fù)bug.例如：Kim等人[1]首先提出了基于模板的自動程序修復(fù)(APR)，從超過6萬個人工補丁中學(xué)習(xí)并發(fā)現(xiàn)了一些常用的修復(fù)模板，這些模板能夠被補丁所接受，并修復(fù)bug.Osman等人[2]提出了一種從代碼更改歷史中提取bug修復(fù)模式的方法，統(tǒng)計修復(fù)模式，討論最常見的模式出現(xiàn)的原因.根據(jù)修復(fù)模式，可以更好地理解bug修復(fù)，提出更有效的bug解決方法.Negara等人[3]第一次提出從細(xì)粒度的代碼修改序列中識別未知的頻繁代碼修改模式，并分析修改模式，歸納了10種高級程序轉(zhuǎn)換模式.Zhao等人[4]開發(fā)了一種代碼更改自動分類工具CTforC，它依據(jù)代碼更改將其分成5種更改類型和9種更改子類型.雖然這些方法在修復(fù)bug方面有一定的幫助，剖析了較常用的修復(fù)模式，但是修復(fù)模板涉及人工手動分析，模板較單一，能提供的修復(fù)信息適合有針對性的代碼修復(fù).

目前，深度學(xué)習(xí)技術(shù)廣泛應(yīng)用于缺陷定位、缺陷預(yù)測和缺陷修復(fù)等方面[5-7].Tufano等人[8]提出使用深度學(xué)習(xí)的方法從真實程序的錯誤代碼和修復(fù)代碼中自動學(xué)習(xí)并生成突變體.他們利用RNN Encoder-Decoder構(gòu)造一個神經(jīng)機器轉(zhuǎn)換(NMT)模型，能夠確定在哪以及怎樣突變源代碼，創(chuàng)造了第一個用于自動化的從現(xiàn)有bug修復(fù)中學(xué)習(xí)變體的方法.在文獻(xiàn)[9]中，他們還對NMT模型進行了經(jīng)驗性的研究，通過定性分析表明，該模型能夠?qū)W習(xí)和復(fù)制各種有意義的代碼更改，尤其是重構(gòu)和bug修復(fù)操作.

為了提供細(xì)粒度的代碼更改，更好地幫助開發(fā)人員理解bug、解決bug問題.本文構(gòu)建了一種自動識別細(xì)粒度更改操作的方法，通過分析常用的細(xì)粒度代碼更改操作并形成修復(fù)模板以運用到缺陷修復(fù)中.通過研究軟件bug模式，開發(fā)人員可以在測試過程中更快地對bug進行修復(fù)；也可以在開發(fā)過程中考慮采用什么樣的開發(fā)技術(shù)預(yù)防這些bug模式的再次出現(xiàn)，從而提高軟件開發(fā)和測試團隊的整體水平.

2 技術(shù)基礎(chǔ)

2.1 細(xì)粒度代碼更改

為了提高軟件的質(zhì)量，必須盡早的理解bug.了解bug修復(fù)的更改操作，可以更好地理解bug的本質(zhì).在bug修復(fù)的類型中，有很多基于細(xì)粒度更改操作的擴展研究，可以使開發(fā)人員更好地了解代碼更改的性質(zhì).Negara等人[3]首先提出從細(xì)粒度的代碼更改序列中識別先前未知的頻繁更改操作模式，并分析修改模式，歸納了10種高級程序轉(zhuǎn)換模式，并利用23位開發(fā)人員收集的真實代碼進行評估，結(jié)果表明10種高級程序轉(zhuǎn)換模式是有效的，并適用于大部分?jǐn)?shù)據(jù).Osman等人[2]發(fā)現(xiàn)缺少null的檢查和初始化都是反復(fù)出現(xiàn)的錯誤，提出了一種自動提取錯誤修復(fù)模式的新方法.Campos等人[10]從提交修復(fù)操作的歷史庫中找到最常使用的更改操作模式，能夠有效地用于bug修復(fù).

2.2 GumTree

GumTree[11]是一個可以生成源代碼編輯腳本的工具，編輯腳本表示兩個版本的源代碼之間的差異.傳統(tǒng)上，使用diff命令生成編輯腳本[12].而GumTree將兩個版本的源代碼作為輸入，并生成一個編輯腳本，該編輯腳本包含抽象語法樹(Abstract Syntax Tree，AST)的插入、刪除、更新和移動的節(jié)點，因此被用于許多更高級別的應(yīng)用程序或進一步的研究中[13-16].GumTree的匹配算法包含兩個階段.第1個階段，GumTree匹配兩個AST的子樹.第2個階段，如果節(jié)點具有相同的類型并且節(jié)點的兩個子樹之間的Jaccard相似度超過閾值，則匹配子樹中的節(jié)點.通過經(jīng)驗研究評估，GumTree可以有效地計算AST上的細(xì)粒度編輯腳本，并且比傳統(tǒng)的diff命令更易于理解.

由于GumTree比diff命令的解析粒度更細(xì)，考慮了語法信息，因此運用GumTree剖析bug修復(fù)中使用到的細(xì)粒度更改操作.通過對細(xì)粒度更改操作進行經(jīng)驗性的研究，提取修復(fù)模板.

3 方 法

為了提高軟件缺陷修復(fù)效率，本文提出一種軟件缺陷修復(fù)推薦技術(shù).方法流程如圖1所示.根據(jù)bug源代碼，首先定義適用于軟件缺陷的修復(fù)模板，然后利用基于樹的卷積神經(jīng)網(wǎng)絡(luò)(Tree Based Convolutional Neural Networks，TBCNN)對bug源代碼進行分類，并根據(jù)每一類別推薦軟件缺陷修復(fù)模板.

圖1 方法流程圖

3.1 軟件bug修復(fù)模板構(gòu)建

bug與其對應(yīng)的源代碼之間有很強的關(guān)聯(lián)[17].源代碼是半結(jié)構(gòu)化的文本，可以確定性地解析成抽象語法樹(AST)，AST中的每個節(jié)點都是程序源代碼中的抽象組件.利用Java的AST可以從源碼中提取語義信息.

本文利用GumTree工具，獲取代碼的buggy版本及其對應(yīng)的fixed版本的兩棵AST樹之間的差異，從而識別修復(fù)過程中已定義的17種細(xì)粒度的更改操作.該方法主要依賴GumTree解析代碼，節(jié)點識別來判斷具體的修復(fù)更改操作.首先從Github上爬取bug的源代碼文件，由于本文的細(xì)粒度的更改操作針對Java語言結(jié)構(gòu)，所以僅挖掘源文件中后綴名為.Java的文件并且將其作為GumTree的輸入.然后通過GumTree解析buggy版本和fixed版本的差異語句，通過節(jié)點ID對應(yīng)，找到具體的修改節(jié)點.差異語句中表示了從buggy版本到fixed版本所修復(fù)語句的操作，利用差異語句中的節(jié)點ID對應(yīng)AST樹上的節(jié)點，很容易找到具體的修復(fù)節(jié)點.最后對該節(jié)點進行祖先遍歷判斷其細(xì)粒度更改操作的類型.通過對祖先節(jié)點的搜索，可以清楚地了解到修改的節(jié)點具體所屬的代碼位置，從而可以準(zhǔn)確判斷出該節(jié)點的細(xì)粒度更改操作類型.其中刪除語句對應(yīng)buggy版本的AST，插入語句對應(yīng)fixed版本的AST，而移動語句則需要對應(yīng)buggy版本和fixed版本的兩個AST.例如：某一GumTree解析后的差異語句是“Insert MethodInvocation(358) into InfixExpression：+(359) at 1”，即根據(jù)ID對應(yīng)到fixed版本的AST樹，追蹤其父節(jié)點并判斷類型，意為“添加一個方法調(diào)用”.在判斷每一個差異語句之后，對于每一個bug修復(fù)，產(chǎn)生一個對應(yīng)的修復(fù)節(jié)點序列.即，解析每一個GumTree輸出的差異語句，并轉(zhuǎn)換成我們之前研究[18]中預(yù)先定義的17種細(xì)粒度更改操作，形成更改操作序列.根據(jù)該序列，可以清晰地知道每一次修復(fù)基于代碼所做的更改操作.

由于在軟件開發(fā)和維護過程中通常進行軟件重用，軟件項目中的源代碼包含具有一定相似程度的代碼片段，會導(dǎo)致在源代碼上進行重復(fù)/相似的更改以及bug修復(fù)，這一點在先前的研究中[19-21]也得到了證實.本文首先提取方法級的更改操作序列，然后利用序列分析每一個序列中使用的細(xì)粒度更改操作.提取方法級的更改操作序列主要有4個方面的原因：1)方法很有可能執(zhí)行一個單獨的任務(wù)；2)方法級提供了足夠有意義的上下文，例如變量、參數(shù)和方法調(diào)用.較小的代碼切片缺少必要的上下文.3)文件或類級別的粒度可能太大.4)任意長度的代碼切片(例如diff中的塊)可能會使模板更加復(fù)雜.此外，現(xiàn)有研究表明[10]，缺陷主要發(fā)生在if相關(guān)語句、方法調(diào)用相關(guān)語句和賦值語句.因此，基于以上考慮，通過對代碼的理解并分析其他常見的軟件缺陷補丁中使用的修復(fù)模板，本文總結(jié)了8個修復(fù)模板.利用每個語句級別上重復(fù)使用的細(xì)粒度更改操作，構(gòu)建修復(fù)模板，使得開發(fā)人員更有效地進行bug修復(fù).

在Github上，每個項目都經(jīng)過多次缺陷修復(fù)的提交.將本文的模板和每次提交中的代碼進行類型匹配，確認(rèn)模板是在缺陷代碼中進行修復(fù)的，最終得出有效的細(xì)粒度修復(fù)模板.最后對該模板進行統(tǒng)計學(xué)分析，確保該模板是有效的，并且可以提高修復(fù)效率.下面將對每一種模板進行介紹.

模板1.IC-AS(if條件語句下賦值語句的修改)if條件的改動往往也會牽引該程序結(jié)構(gòu)中其他語句的改動，if條件語句下的賦值語句也隨之修改.示例如表1第2行所示.

表1 軟件缺陷修復(fù)模板示例

模板2.WS-FC(while語句中方法調(diào)用的修改)while語句是常用的程序結(jié)構(gòu)，方法調(diào)用亦是經(jīng)常容易修改的細(xì)粒度更改操作，因此將其作為一個常用的修復(fù)模板.示例如表1第3行所示.

模板3.IC-FC(if條件下的方法調(diào)用的修改)if語句是java語言中最常用的程序結(jié)構(gòu)，方法調(diào)用修改的頻率較高，因此將其作為一個常用的修復(fù)模板.示例如表1第4行所示.

模板4.FS-FC(for條件下的方法調(diào)用的修改)for語句是java語言中常用的程序結(jié)構(gòu)之一，方法調(diào)用是最常見的修改，因此將其作為一個常用的修復(fù)模板.示例如表1第5行所示.

模板5.IF(if語句塊的添加)在處理異常的情況下，通常會在邊界值處理中添加一個if語句塊.示例如表1第6行所示.

模板6.RC(重復(fù)的操作)在不同的方法中添加相同的塊.在bug修復(fù)過程中，通常會在不同的地方，添加上相同的代碼塊，特別是處理異常的情況下.示例如表1第7行所示.

模板7.IF-P(添加if預(yù)測指針)這個類別的bug都是修復(fù)條件更改，涉及對某個對象添加空指針.這種類型的bug頻繁發(fā)生.示例如表1第8行所示.

模板8.AS-FC(賦值語句中方法調(diào)用的修改)賦值語句中的更改，往往會伴隨著方法調(diào)用語句的更改.示例如表1第9行所示.

3.2 軟件bug修復(fù)推薦方法

軟件缺陷修復(fù)推薦方法利用bug源代碼進行代碼分類，并為每一分類結(jié)果推薦修復(fù)模板.首先將得到的bug的buggy版本AST和fixed版本AST進行預(yù)處理，將兩個AST轉(zhuǎn)換成一個diff-AST.最終得到的diff-AST是在buggy版本的AST中改進的，使其具有更多的修復(fù)特征，從而提高基于樹的卷積神經(jīng)網(wǎng)絡(luò)的分類特征獲取的準(zhǔn)確性.

然后，運用基于樹的卷積神經(jīng)網(wǎng)絡(luò)對代碼根據(jù)修復(fù)過程中所包含的細(xì)粒度更改操作進行分類.在修復(fù)方案推薦的方法構(gòu)建中，需要對用于分類的bug數(shù)據(jù)先進行人工標(biāo)記，依據(jù)修復(fù)缺陷過程中使用的細(xì)粒度更改操作的分類標(biāo)準(zhǔn)在人工干預(yù)的情況下將數(shù)據(jù)標(biāo)記類別.在我們之前的經(jīng)驗研究[18]中，對大量的bug進行了細(xì)粒度更改操作的分析，并將bug根據(jù)細(xì)粒度更改操作分為不同的類別.本文將8種修復(fù)模板作為修復(fù)方案推薦類別，通過分析修復(fù)代碼中的細(xì)粒度更改操作將bug數(shù)據(jù)標(biāo)記為不同的修復(fù)方案類別.

數(shù)據(jù)標(biāo)記完成之后，通過該卷積神經(jīng)網(wǎng)絡(luò)學(xué)習(xí)不同修復(fù)方案類別的特征，并進行數(shù)據(jù)的分類.首先，將diff-AST樹作為輸入，并將AST節(jié)點表示為分布式實值向量，用來捕獲特征.其向量表示通過編碼標(biāo)準(zhǔn)來學(xué)習(xí).接著，設(shè)計一組子樹特征檢測器，在整個AST上滑動以提取程序的結(jié)構(gòu)信息，稱為基于樹的卷積核.然后，應(yīng)用動態(tài)池化來收集樹的不同部分上的信息.最后，添加隱藏層和輸出層.對于監(jiān)督分類任務(wù)，輸出層的激活函數(shù)為softmax，結(jié)果為每種分類的可能性.最終將可能性值最大的類別作為推薦類別以達(dá)到修復(fù)模板的推薦.

4 實驗評估

4.1 實驗對象

實驗對象來自Github上爬取的Mozilla項目的源代碼文件，包含bug的buggy版本和fixed版本.實驗數(shù)據(jù)依據(jù)Bugzilla——一個開源的bug追蹤系統(tǒng)(1)https：//www.bugzilla.org，該系統(tǒng)關(guān)聯(lián)了Mozilla的bug數(shù)據(jù)，判斷bug是否完成了修復(fù)并且有最終的修復(fù)代碼，即在bug報告中是否包含“diff”.我們使用的是Bugzilla中包含“diff”的bug數(shù)據(jù)，截止到2018年10月，其數(shù)據(jù)量為1256.

4.2 實驗設(shè)置

問題1.本文提出的細(xì)粒度修復(fù)模板的使用頻率以及模板的覆蓋范圍如何？為了回答該問題，實驗中對細(xì)粒度的修復(fù)模板和真實項目中的commit提交的代碼進行匹配，以此判斷該修復(fù)模板使用的頻率.然后統(tǒng)計commit提交的代碼中所有的修復(fù)片段，計算8種模板使用情況的覆蓋范圍，以確定本文定義的修復(fù)模板的通用性.

問題2.本文推薦的修復(fù)模板的精確度如何？為了回答該問題，本實驗將通過基于樹的卷積神經(jīng)網(wǎng)絡(luò)對bug文件進行推薦的修復(fù)模板與開發(fā)人員生成的補丁中的修復(fù)模式進行比較，來評估其準(zhǔn)確性.為了衡量推薦方法的準(zhǔn)確性，實驗選擇Mozilla項目中已完成修復(fù)的30個bug.我們利用公式(1)作為精確度的度量標(biāo)準(zhǔn).其中P表示推薦的修復(fù)模板的準(zhǔn)確率，nco表示能使用推薦的模板正確修復(fù)的bug的個數(shù)，Nco表示bug片段的總個數(shù).這里的準(zhǔn)確率為使用推薦模板正確修復(fù)bug的個數(shù)與實驗中所有bug片段個數(shù)的比例，該值越高，表示修復(fù)性能越好.

(1)

問題3.本文提出的推薦修復(fù)模板是否能有效為開發(fā)人員提供bug修復(fù)信息？面對真實項目中的大量代碼，運用本文推薦的修復(fù)模板，能否為開發(fā)人員提供有用的修復(fù)建議，這是本實驗的目的.在實驗中，讓參評人員根據(jù)推薦的修復(fù)模板去修復(fù)軟件bug，篩選有多少建議是可用的，并計算推薦修復(fù)模板的有效性.

4.3 實驗結(jié)果

問題1.本文提出的細(xì)粒度修復(fù)模板的使用頻率以及模板的覆蓋范圍如何？

通過將這些模板分別和每次commit提交中的代碼進行匹配分析，確保這些模板是在真實的項目中經(jīng)常使用并且是有效的.細(xì)粒度模塊的使用頻率如圖2所示.在8種細(xì)粒度模板中，IC-AS模板的使用頻率最高，占總使用次數(shù)的21.83%.在bug修復(fù)中，if條件語句的修改，往往會伴隨著其他程序結(jié)構(gòu)的修改，例如賦值語句的修改或方法調(diào)用語句的修改.IC-FC模板的使用頻率為16.91%，如果出現(xiàn)在賦值語句中修改了調(diào)用方法或者調(diào)用方法的實參，則將其認(rèn)為是對賦值語句的修改，所以在本文的統(tǒng)計計算中，賦值語句的修改高于對方法調(diào)用語句的修改.其次，使用頻率較高的模板是AS-FC，占全部使用次數(shù)的19.73%.在賦值語句的修改中，簡單的賦值語句的修改在少數(shù)，即算術(shù)表達(dá)式和邏輯表達(dá)式，大部分還是對復(fù)雜的調(diào)用方法或者參數(shù)的修改.第3個使用頻率高的模板是IC-FC，所占比例為16.91%，即if語句中方法調(diào)用的修改.其他模板的使用頻率分別是，IF為11.64%，F(xiàn)S-FC為10.54%，WS-FC為10.2%，IF-P為5.64%，RC為3.51%.

圖2 細(xì)粒度模板的使用頻率

可以發(fā)現(xiàn)，在真實的項目中，大部分的模板修改的程序主要是對于if語句的修改，以及方法調(diào)用方法的修改.隨著軟件維護過程中，代碼量的不斷擴大，修復(fù)的程序類型也不止這8種，因此還另外計算了本文的模板在所有的代碼修復(fù)中所覆蓋的范圍.在隨機選取的項目中的1028個commit提交中，這8種基于細(xì)粒度的模板在修復(fù)代碼中覆蓋的范圍為67.11%.

綜上所述，本文所提出的8種細(xì)粒度的修復(fù)模板在真實的項目中使用是有效的，并且可以解決一半以上的bug問題，可以幫助開發(fā)人員快速地修復(fù)bug.

問題2.本文基于樹的卷積神經(jīng)網(wǎng)絡(luò)推薦的修復(fù)方案的精確度如何？

實驗中選取的bug數(shù)據(jù)過濾掉了包含添加大量修復(fù)代碼、刪除大量源代碼以及大量修改代碼，修復(fù)包含明確的細(xì)粒度更改操作以至于可以更清晰地了解所推薦的修復(fù)方案是否正確.并且這些數(shù)據(jù)中的修復(fù)文件較少，且修復(fù)的代碼行中結(jié)構(gòu)較為清晰.同時，30個數(shù)據(jù)不同于基于樹的卷積神經(jīng)網(wǎng)絡(luò)的訓(xùn)練集和測試集數(shù)據(jù).首先30個bug報告將通過bug定位技術(shù)確定可疑的代碼行，然后將包含可疑代碼行的文件利用TBCNN將文件分類，最終選擇類別可能性值最高的類別作為可推薦的修復(fù)方案，并給出修復(fù)意見.該實驗針對最終推薦的30個修復(fù)方案，做統(tǒng)計分析.即通過推薦的修復(fù)方案和正確修復(fù)方案的比較，計算本文修復(fù)方案推薦方法的準(zhǔn)確率.圖3表明了在30個bug中，推薦的修復(fù)模板在每個bug修復(fù)中使用的準(zhǔn)確率.

圖3 推薦的修復(fù)模板使用的精確度

從圖3中可以看出，在分析的30個bug中，推薦的修復(fù)模板應(yīng)用于具體的代碼修復(fù)中，準(zhǔn)確率高于50%的達(dá)到了一半.這表明本文的細(xì)粒度修復(fù)模板是有效的，可以用于真實的代碼修復(fù)中.由于在真實的情況下，一些bug需要修復(fù)的代碼片段只有一個，或者太多(例如多于20個).這會造成修復(fù)模板的推薦受到限制，比如在bug #185165中，只修改了一處，即對if語句中的if條件進行了修改，而在本文的修復(fù)模板中不包含這類的修改，因此這會限制模板的使用.為了保證實驗驗證的有效性，選取的30個bug是隨機選取，只過濾掉了因為添加文件而造成的大范圍增加代碼的情況.而大范圍增加代碼進行修復(fù)的過程并不適合用模板修復(fù)，會造成模板的無效性.

在30個bug中，僅有16.67%的推薦的修復(fù)模板可以達(dá)到準(zhǔn)確率100%的效果.造成這個結(jié)果的原因主要是，目前本文的修復(fù)模板雖然取自真實的項目中，但是在提取的過程中，由于一些技術(shù)因素導(dǎo)致模板并不全面，此模板的覆蓋范圍為67.11%.其次是在真實的項目中，程序結(jié)構(gòu)多種多樣，并不絕對的限制在if條件中，而本文提取的修復(fù)模板大部分都是針對于if條件的修改，這會影響模板在驗證過程中的效果.

問題3.本文提出的推薦修復(fù)模板是否能有效為開發(fā)人員提供bug修復(fù)信息？

在這個研究問題中，旨在驗證修復(fù)模板是否符合開發(fā)人員想要的修復(fù)效果，能否為解決bug問題提供一些有效的信息.因此，為了驗證這個問題，實驗組織者邀請了5位參評者(對bug數(shù)據(jù)的研究超過兩年)，根據(jù)推薦的修復(fù)模板，對推薦的信息有用性從3個等級進行評價：有用、一般有用、無用.其中，“有用”是指能夠幫助參評者實現(xiàn)bug問題的修復(fù)，“一般有用”是指僅能提供一部分的信息，“無用”是指推薦的信息對參評者起不到指導(dǎo)的作用.

圖4給出修復(fù)模板有效性評價結(jié)果.根據(jù)結(jié)果可知，通過推薦的修復(fù)模板提供的相關(guān)修復(fù)信息，對30個bug進行評估，其中對于參評者C，有46.67%的模板信息是有用的，43.33%的模板信息是一般有用的，僅有10%的模板信息是無用的.因此，可以認(rèn)為90%的模板信息是有效的，能夠提供一些用于修復(fù)的指導(dǎo)意見.在其他參評者的反饋中，可以看出，大部分的修復(fù)模板方案是有效的，只有較少一部分提供的模板方案無效.造成這個結(jié)果的原因，可能是模板覆蓋不全面，小部分的bug僅修復(fù)一段代碼而這個修復(fù)操作不屬于本文的模板的覆蓋范圍.但是，從評價結(jié)果可知，本文提出的推薦修復(fù)模板方案能有效的提供一些bug修復(fù)相關(guān)的信息，可以幫助開發(fā)人員解決bug問題.

圖4 修復(fù)模板有效性評價結(jié)果

5 有效性威脅

首先，在本實驗中，利用基于樹的卷積神經(jīng)網(wǎng)絡(luò)完成修復(fù)模板的推薦，在人工對訓(xùn)練數(shù)據(jù)進行分類的過程中，可能存在一些人為的誤差，沒有經(jīng)過專家認(rèn)證，從而影響訓(xùn)練數(shù)據(jù)集的準(zhǔn)確性.

其次，在驗證過程中，選取的bug數(shù)據(jù)是隨機的，可能會導(dǎo)致模板的適用效果存在誤差.另一個有效性威脅是問題2中的參評者的評估存在偏差.為了緩解該問題，實驗中涉及的參評者都是具有開發(fā)經(jīng)驗并且對bug數(shù)據(jù)有兩年以上的研究.

最后，本實驗中的實驗對象主要來源于Mozilla項目.雖然本文修復(fù)模板的提出是基于現(xiàn)有的大量大規(guī)模的經(jīng)驗研究結(jié)果，但仍不能保證推薦的模板適用于所有的項目.在接下來的工作中，我們將收集更多開源項目中的缺陷數(shù)據(jù)，以保障實驗數(shù)據(jù)的充分性，從而進一步提升本文缺陷修復(fù)推薦方法的實用性.

6 總 結(jié)

本文主要針對bug修復(fù)耗時耗力的問題，利用bug報告，提出了一種基于樹的卷積神經(jīng)網(wǎng)絡(luò)進行缺陷修復(fù)方案建議推薦的方法.從bug修復(fù)相關(guān)的源代碼中挖掘修復(fù)模板，并利用修復(fù)模板為開發(fā)人員推薦修復(fù)方案.為了驗證推薦的修復(fù)模板的有效性，本文使用Mozilla的bug數(shù)據(jù)對修復(fù)模板的精確度進行驗證，并邀請5名參評者對推薦的修復(fù)模板進行評估，結(jié)果表明本方法推薦的修復(fù)模板能夠有效地為開發(fā)人員解決bug問題時提供一些修復(fù)和指導(dǎo)意見.