薄莉莉，朱軒銳，孫小兵

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

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

3(計(jì)算機(jī)軟件新技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室(南京大學(xué))，南京 210023)

1 引 言

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

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

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

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

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

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

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

2.2 GumTree

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

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

3 方 法

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

圖1 方法流程圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 實(shí)驗(yàn)評(píng)估

4.1 實(shí)驗(yàn)對(duì)象

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

4.2 實(shí)驗(yàn)設(shè)置

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

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

(1)

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

4.3 實(shí)驗(yàn)結(jié)果

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

通過(guò)將這些模板分別和每次commit提交中的代碼進(jìn)行匹配分析，確保這些模板是在真實(shí)的項(xiàng)目中經(jīng)常使用并且是有效的.細(xì)粒度模塊的使用頻率如圖2所示.在8種細(xì)粒度模板中，IC-AS模板的使用頻率最高，占總使用次數(shù)的21.83%.在bug修復(fù)中，if條件語(yǔ)句的修改，往往會(huì)伴隨著其他程序結(jié)構(gòu)的修改，例如賦值語(yǔ)句的修改或方法調(diào)用語(yǔ)句的修改.IC-FC模板的使用頻率為16.91%，如果出現(xiàn)在賦值語(yǔ)句中修改了調(diào)用方法或者調(diào)用方法的實(shí)參，則將其認(rèn)為是對(duì)賦值語(yǔ)句的修改，所以在本文的統(tǒng)計(jì)計(jì)算中，賦值語(yǔ)句的修改高于對(duì)方法調(diào)用語(yǔ)句的修改.其次，使用頻率較高的模板是AS-FC，占全部使用次數(shù)的19.73%.在賦值語(yǔ)句的修改中，簡(jiǎn)單的賦值語(yǔ)句的修改在少數(shù)，即算術(shù)表達(dá)式和邏輯表達(dá)式，大部分還是對(duì)復(fù)雜的調(diào)用方法或者參數(shù)的修改.第3個(gè)使用頻率高的模板是IC-FC，所占比例為16.91%，即if語(yǔ)句中方法調(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)，在真實(shí)的項(xiàng)目中，大部分的模板修改的程序主要是對(duì)于if語(yǔ)句的修改，以及方法調(diào)用方法的修改.隨著軟件維護(hù)過(guò)程中，代碼量的不斷擴(kuò)大，修復(fù)的程序類型也不止這8種，因此還另外計(jì)算了本文的模板在所有的代碼修復(fù)中所覆蓋的范圍.在隨機(jī)選取的項(xiàng)目中的1028個(gè)commit提交中，這8種基于細(xì)粒度的模板在修復(fù)代碼中覆蓋的范圍為67.11%.

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

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

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

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

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

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

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

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

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

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

5 有效性威脅

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

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

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

6 總 結(jié)

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