高子欣 趙逢禹 劉亞

摘 ?要： 在軟件開發(fā)過程中，軟件缺陷是不可避免的。在缺陷跟蹤系統(tǒng)中，一個(gè)重要的問題是如何根據(jù)用戶所提交的缺陷報(bào)告，進(jìn)行缺陷的自動(dòng)定位。本文在綜合考慮缺陷報(bào)告與源代碼文件結(jié)構(gòu)相似性的基礎(chǔ)上，進(jìn)一步分析已修復(fù)缺陷報(bào)告、缺陷報(bào)告中的異常堆棧（Stack Trace）信息對(duì)軟件缺陷定位的作用，從而提高定位的精度。在Eclipse、AspectJ和SWT開源項(xiàng)目數(shù)據(jù)程序集上進(jìn)行相關(guān)實(shí)驗(yàn)，并與Buglocator、BRTracer和BLUiR缺陷定位方法進(jìn)行了比較分析，實(shí)驗(yàn)結(jié)果表明，本文方法能顯著提高軟件缺陷定位的精度。

關(guān)鍵詞： 缺陷定位;缺陷報(bào)告;結(jié)構(gòu)相似;異常堆棧信息

中圖分類號(hào)： TP311.5 ? ?文獻(xiàn)標(biāo)識(shí)碼： A ? ?DOI：10.3969/j.issn.1003-6970.2019.05.002

本文著錄格式：高子欣，趙逢禹，劉亞，等. 基于缺陷報(bào)告分析的軟件缺陷定位方法[J]. 軟件，2019，40（5）：0815

【Abstract】： Software defects are inevitable during the software development process. In the defect tracking system， an important issue is how to automatically locate defects based on the bug report submitted by the user. Based on the comprehensive consideration of the structural similarity between the defect report and the source code file， this paper further analyzes the effect of the abnormal stack information in the fixed defect report and defect report on the software defect location， thus improving the positioning accuracy. Related experiments are carried out on the Eclipse， AspectJ and SWT open source project data assemblies， and compared with Buglocator， BRTracer and BLUiR defect location methods. The experimental results show that the proposed method can significantly improve the accuracy of software defect location.

【Key words】： Bug localization; Bug report; Similar structure; Stack information

0 ?引言

在整個(gè)軟件的生命周期中，軟件維護(hù)約占整個(gè)軟件開發(fā)項(xiàng)目工作量的40%左右[1-3]。在進(jìn)行軟件維護(hù)時(shí)，如何定位軟件缺陷，是極具挑戰(zhàn)性的。當(dāng)用戶在使用軟件過程中發(fā)現(xiàn)問題時(shí)，通常向軟件缺陷跟蹤系統(tǒng)中提交缺陷報(bào)告，開發(fā)人員再根據(jù)用戶填寫的缺陷報(bào)告進(jìn)行缺陷定位，修改相應(yīng)的代碼。但是隨著軟件規(guī)模以及復(fù)雜度的不斷加大，缺陷也越來越多，缺陷跟蹤系統(tǒng)上每天會(huì)收到大量的缺陷報(bào)告，只是通過人工完成缺陷定位會(huì)嚴(yán)重影響工作效率，所以如何通過缺陷報(bào)告自動(dòng)定位到有缺陷的代碼一直是研究人員關(guān)注的熱點(diǎn)問題。

基于缺陷報(bào)告進(jìn)行軟件缺陷定位目前已經(jīng)有許多研究成果。Zhou等人[4]提出了BugLocator方法，原理是基于信息檢索，優(yōu)化向量空間模型，根據(jù)源代碼文件和缺陷報(bào)告之間的文本相似度并結(jié)合歷史缺陷報(bào)告進(jìn)行缺陷定位。Wong等人[5]提出了BRTracer方法，通過使用代碼分段和Stack Trace信息分析來提高缺陷定位的性能。他們將每個(gè)源代碼文件分成一系列的代碼片段，對(duì)于給定的一個(gè)缺陷報(bào)告，他們使用與該缺陷報(bào)告最相似的代碼片段來表示該源代碼文件，并利用了缺陷報(bào)告中的Stack Trace信息與源代碼文件之間的相似性。Saha等人[6]提出了BLUiR方法，通過修改tf-idf的計(jì)算方式，并利用源代碼結(jié)構(gòu)化信息來檢索計(jì)算與缺陷報(bào)告中Summary和Description中的內(nèi)容相似度，從而進(jìn)行缺陷定位。

表1為從Eclipse官網(wǎng)中提取的一條Bug ID為80720缺陷報(bào)告以及這條缺陷對(duì)應(yīng)的源代碼文件，這條缺陷報(bào)告主要是根據(jù)Description內(nèi)容進(jìn)行缺陷定位。

目前大部分研究人員都是將軟件缺陷報(bào)告和源代碼文件當(dāng)作普通的文本來處理，分析它們之間的相似度，該方法主要是通過使用文本信息檢索技術(shù)[7-8]來比較缺陷報(bào)告與源代碼文件的相似性，對(duì)缺陷所在的源代碼文件進(jìn)行定位。而實(shí)際上，軟件缺陷報(bào)告中通常包含Stack Trace信息、函數(shù)間調(diào)用的關(guān)系等，如果直接將它們視為純文本，則會(huì)丟掉大量有價(jià)值的缺陷信息，也會(huì)導(dǎo)致缺陷定位不準(zhǔn)。

表2為另一條Bug ID為43709的缺陷報(bào)告以及這條缺陷對(duì)應(yīng)的源代碼，這條缺陷報(bào)告則是根據(jù)Stack trace內(nèi)容進(jìn)行缺陷定位。Schroter等人[9]的一項(xiàng)研究表明，缺陷可能存在Stack Trace中的前10個(gè)函數(shù)中。

本文在綜合考慮軟件缺陷報(bào)告與源代碼文件結(jié)構(gòu)相似性的基礎(chǔ)上，進(jìn)一步分析待修復(fù)缺陷報(bào)告與已修復(fù)缺陷報(bào)告相似性、缺陷報(bào)告中的Stack Trace信息與源代碼文件相似性，從而提高定位的精度。

本文其它部分內(nèi)容的組織說明如下：第二部分介紹了基于缺陷報(bào)告分析的軟件缺陷定位框架;第三部分詳細(xì)分析了本文用到的關(guān)鍵技術(shù)與方法;第四部分為實(shí)證分析該方法并與其他經(jīng)典方法進(jìn)行對(duì)比，確保其可行性;第五部分對(duì)本文方法做出總結(jié)并提出下一步改進(jìn)工作。

1 ?基于缺陷報(bào)告分析的軟件缺陷定位框架

圖1為基于缺陷報(bào)告分析的軟件缺陷定位框架（Bug Report Defect location， 簡記為BRDL）。首先提取并預(yù)處理源代碼文件中的Class、Method、Variable、Comments等信息，并存儲(chǔ)為源代碼XML結(jié)構(gòu)化文檔。同理我們將缺陷報(bào)告的Summary、Description、Comment提取出來并進(jìn)行預(yù)處理操作，計(jì)算缺陷報(bào)告與源代碼文件的結(jié)構(gòu)相似度;由于缺陷往往是存在于源代碼文件中的某個(gè)方法或者代碼塊中，所以再計(jì)算源代碼中的方法與缺陷報(bào)告的相似度，提高單個(gè)方法的影響力度;由于經(jīng)常被修改的源代碼文件，含缺陷概率越高，待修復(fù)缺陷報(bào)告與已修復(fù)缺陷報(bào)告的相似度越高，則待修復(fù)缺陷報(bào)告關(guān)聯(lián)的缺陷文件很可能就是已修復(fù)缺陷報(bào)告修復(fù)的源代碼文件，用它們的相似度分?jǐn)?shù)來調(diào)整最終源代碼文件排序;由于一些缺陷報(bào)告中會(huì)存在Stack Trace等信息，這些信息記錄了錯(cuò)誤路徑上調(diào)用的方法以及所涉及到的類，它們參與了程序的錯(cuò)誤執(zhí)行過程，與程序錯(cuò)誤密切相關(guān)，所以要對(duì)缺陷報(bào)告中的Stack Trace信息進(jìn)行分析以輔助缺陷定位。

（1）構(gòu)建源代碼XML結(jié)構(gòu)化文檔

對(duì)源代碼使用Eclipse中的JDT技術(shù)來構(gòu)建抽象語法樹[10-11]，通過抽象語法樹來提取程序結(jié)構(gòu)：Class、Method、Variable、Comments，并對(duì)Comments的內(nèi)容進(jìn)行去除停用詞等預(yù)處理，最后將這些處理后的信息存儲(chǔ)為一個(gè)源代碼XML結(jié)構(gòu)化文檔。

（2）計(jì)算缺陷報(bào)告與源代碼文件的文本結(jié)構(gòu)相似度

提取缺陷報(bào)告中的Summary、Description、Com?ments等相關(guān)信息，并進(jìn)行分詞、去除停用詞等預(yù)處理操作，計(jì)算其與源代碼XML結(jié)構(gòu)化文檔以及源代碼中方法的相似度。

（3）計(jì)算已修復(fù)缺陷報(bào)告與待修復(fù)缺陷報(bào)告的相似度

由于同一問題可能被不同用戶多次提交，并且經(jīng)常被修改的源代碼文件含缺陷的概率更高，若一個(gè)待修復(fù)缺陷報(bào)告與已修復(fù)缺陷報(bào)告的相似度越高，則已修復(fù)缺陷報(bào)告所關(guān)聯(lián)的缺陷文件很可能就是這個(gè)待修復(fù)缺陷報(bào)告需要定位的源代碼文件。

（4）分析缺陷報(bào)告中的Stack Trace信息并計(jì)算其與源代碼文件的相似度

由于缺陷報(bào)告中的Stack Trace信息記錄了錯(cuò)誤路徑上的調(diào)用的方法以及所涉及到的類，它們參與了程序的錯(cuò)誤執(zhí)行過程，所以該信息與程序錯(cuò)誤密切相關(guān)，這里我們根據(jù)程序依賴圖找到源代碼中相關(guān)元素與Stack Trace中的結(jié)構(gòu)化元素間的最小路徑，并計(jì)算其相似度。

2 ?基于缺陷報(bào)告分析的軟件缺陷定位的關(guān)鍵技術(shù)與方法

基于缺陷報(bào)告分析的軟件缺陷定位框架如圖1所示，其關(guān)鍵方法主要包含文本預(yù)處理、源代碼結(jié)構(gòu)信息與缺陷報(bào)告相似度計(jì)算、待修復(fù)缺陷報(bào)告與已修復(fù)缺陷報(bào)告相似度計(jì)算和源代碼的結(jié)構(gòu)信息與缺陷報(bào)告中的Stack Trace信息相似度計(jì)算。

2.1 ?文本預(yù)處理

預(yù)處理的目的是將缺陷報(bào)告或源代碼文件文本分解成可以被信息檢索技術(shù)分析的詞，即統(tǒng)一了詞空間。在對(duì)源代碼文件進(jìn)行處理時(shí)，我們先將其轉(zhuǎn)換成抽象語法樹（Abstract Syntax Tree），則Class、Method、Variable、Comments等文本信息可被直接提取出來;提取缺陷報(bào)告中的Summary、Descri?ption、Comment內(nèi)容;對(duì)提取的缺陷報(bào)告的內(nèi)容以及源代碼文件中的Comments的內(nèi)容進(jìn)行分詞、去除停用詞、提取詞干等預(yù)處理操作。

在進(jìn)行標(biāo)識(shí)符分割時(shí)，那些標(biāo)志符通常是根據(jù)Camel Case splitting[12]分割原則分割成它的構(gòu)成詞，但這樣會(huì)增加單個(gè)詞命名的權(quán)重。所以我們將所有非字母符號(hào)轉(zhuǎn)為空格，用空格將文本分割成一連串的詞。

由于缺陷報(bào)告和源代碼文件有不同的停止詞。對(duì)缺陷報(bào)告而言，“is”、“the”、“on”等都是英文停止詞。對(duì)源代碼文件而言，除了英文停止詞，還要移除關(guān)鍵字，如“private”、“public”、“return”等。所以我們定義了兩個(gè)去停用詞列表，一個(gè)是英文停用詞，還有一個(gè)就是關(guān)鍵字。選擇去英文停用詞對(duì)自然語言文本進(jìn)行去停用詞操作;選擇去關(guān)鍵字對(duì)源代碼進(jìn)行去停用詞操作。

最后，使用標(biāo)準(zhǔn)的Porter Stemmer[11]來執(zhí)行詞干提取，將衍生詞還原為詞根形式。例如，詞“removing”和“removes”將還原成詞“remove”。經(jīng)過此處理后，相似的詞就能以相同形式出現(xiàn)。

2.2 ?源代碼結(jié)構(gòu)信息與缺陷報(bào)告相似度計(jì)算

缺陷報(bào)告與源代碼文件進(jìn)行預(yù)處理之后，我們計(jì)算源代碼的結(jié)構(gòu)信息：Class、Method、Variable、Comments與缺陷報(bào)告的相似度，將源代碼XML文檔中的Class、Method、Variable、Comments中的內(nèi)容分別與預(yù)處理后的缺陷報(bào)告內(nèi)容進(jìn)行詞語匹配，如表3所示。

由于缺陷通常是存在于源代碼文件中的某個(gè)方法或某個(gè)代碼塊中，所以這里增加方法的權(quán)重，單獨(dú)計(jì)算源代碼的方法中的信息與缺陷報(bào)告的匹配程度，以提高單個(gè)方法的影響力度。表4為源代碼方法信息與缺陷報(bào)告詞語匹配。

3 ?實(shí)驗(yàn)分析

為了驗(yàn)證本文方法的實(shí)用性，選取了被其他研究人員經(jīng)常使用的數(shù)據(jù)集Eclipse3.1，AspectJ1.5，SWT3.1進(jìn)行實(shí)驗(yàn)分析，并與Buglocator、BRTracer、BLUiR三個(gè)缺陷定位方法進(jìn)行比較，從而驗(yàn)證本方法對(duì)提高軟件缺陷定位的精確度可行性。