本發(fā)明屬于軟件bug定位領域，特別提出了一種基于Stack Overflow和commit庫的bug定位方法。

背景技術：

隨著開源項目的逐漸流行，越來越多的軟件開發(fā)者參與到開源項目之中，開源項目主持人與其他項目開發(fā)者常常將項目的更新代碼上傳到commit庫中，修復一些在原來項目中存在問題。隨著項目的不斷擴大，開發(fā)者在對開源項目進行開發(fā)時，常常會遇到新的bug問題，為了解決遇到的bug問題，則需要對bug進行精確的定位。

對此，在之前的研究中，很多技術使用了LDA(Latent Dirichlet Ailocation)，LSI(Latent Semantic Indexing)，VSM(Vector Space Model)等模型對項目代碼進行文本檢索，Laura Moreno等人對上面的模型應用靜態(tài)分析技術，即利用由軟件系統的源代碼中提取出的各種各樣結構信息，如語法屬性、數據流從屬關系等，來加強相關代碼元素與查詢語句的關系。此外，還利用bug報告中的stack trace來進行Bug定位的方法。對bug定位的準確性做出了一些改善。

但該方法只是對單一的commit庫或者項目代碼，忽視了如今越來越多人參與其中的眾包知識庫，bug定位的準確率依舊不高。

技術實現要素：

本發(fā)明的目的就在于克服上述缺陷，研制一種基于Stack Overflow和commit庫的bug定位方法。

本發(fā)明的技術方案是：

一種基于stackoverflow和commit庫的bug定位方法，其特征在于包括如下步驟：

(1)將用戶提交的問題分解成問題段、代碼段、stack trace段三個子段；

(2)根據步驟(1)所得到的問題段，先進行預處理，然后使用RAKE算法提取出關鍵字，將關鍵字對Stack Overflow問題庫中的問題標簽進行匹配，將每個問題答案對的標簽與問題段的關鍵字進行比較，計算相同標簽所占比重，導出比重最高的問題答案對；

(3)根據步驟(2)得出的答案，提取出其中的代碼段，若步驟(1)分解后也 有代碼段，則整合為問題代碼段+答案代碼段形式；

(4)對步驟(3)整合的結果，使用RAKE提取出關鍵字，設定為標簽tag，再使用tag-LDA對commit庫進行處理，建立主題模型，并結合標簽進行匹配，篩選出匹配度大于等于0.3的commit相應代碼段；

(5)對步驟(3)得出的結果的代碼部分與步驟(4)得到的commit代碼進行文本相似度匹配和利用由節(jié)點即類、class，有向線段即方法、method組成的程序依賴圖對由步驟(1)分解得到的堆棧追蹤stack trace進行結構相似度匹配；

(6)根據前面計算得到的文本相似度和結構相似度進行綜合計算，計算30％×文本相似度+70％×結構相似度的結果，按計算結果大小進行結果推薦。

所述步驟(1)預處理過程包括以下步驟：

a)移除數字；

b)對一些按照駝峰規(guī)則和有下劃短線相連的組合詞進行分詞；

c)去除英語停用詞；

d)將詞語的不同形式進行歸一化；

所述步驟(2)RAKE算法的計算公式如下：

wordScore＝wordDegree(w)/wordFrequency(w)

即單詞w的得分是該單詞的度(是一個網絡中的概念，每與一個單詞共現在一個短語中，度就加1，考慮該單詞本身)除以該單詞的詞頻(該單詞在該文檔中出現的總次數)。

然后對于每個候選的關鍵短語，將其中每個單詞的得分累加，并進行排序，RAKE將候選短語總數的前三分之一的認為是抽取出的關鍵詞。

所述步驟(2)標簽匹配的計算公式如下：

匹配度＝相同標簽個數/所有不重復標簽個數

所述步驟(5)文本相似度的計算公式如下：

其中A，B是表示文檔一和文檔二的量化表示。文檔一和文檔二經過分詞，去停用詞，移除數字，詞根化等預處理過程，將剩余的單詞按一定順序數值化后形成向量A，B。在信息檢索中，每個詞條擁有不同的度，一個文檔是由一個由有權值的特征向量表示的，權值的計算取決于詞條在該文檔中出現的頻率。余弦相似度因此可以給出兩篇文檔其主題方面的相似度。

所述步驟(5)程序依賴圖(Program Dependence Graph，PDG)的建立方法如下：程序中以類(class)作為節(jié)點，由一個節(jié)點到另一個節(jié)點的有向線段為前一個類的方法(method)調用后一個類的方法(method)

所述步驟(5)結構相似度的計算方法如下：

stackTrace和程序依賴圖(PDG)中某一節(jié)點(類class)的距離

dist(stackTrace，e)為stackTrace上的類與該節(jié)點之間距離的最小值

其中，e為程序依賴圖中的節(jié)點(類，class)，λ為二者最遠距離所述步驟(6)綜合文本相似度和結構相似度方法如下：

Bug定位精準度下＝文本相似度*30％+結構相似度*70％

本發(fā)明的優(yōu)點和效果在于：

(1)目前bug定位技術主要針對單一庫進行檢索，功能不夠完善。而本發(fā)明利用基于眾包的知識庫(Stack Overflow)，來增加bug定位的準確率。

(2)本發(fā)明從文本相似度，結構相似度兩個角度綜合匹配commit相關代碼庫，給出較為準確的定位。

因此，本發(fā)明主要結合了Stack Overflow問題庫和軟件Commit庫中的信息，來對bug做出更好更精確的定位，且使用了Tag-LDA模型來對commit庫進行匹配，使用了RAKE算法來提取問題的關鍵字。Tag-LDA模型是對Latent Dirichlet Ailocation模型的一種拓展應用，本發(fā)明通過Tag-LDA主題模型，推薦和文檔內容相關的多個標簽，并且對每個標簽和文章相關程度的概率進行估算，如圖2是Tag-LDA主題模型的示意圖。

RAKE(Rapid Automatic Keywords Extraction)算法對提出的問題、以及問題代碼進行關鍵字提取。RAKE算法于被2010年提出，本發(fā)明應用RAKE算法來提取關鍵詞(keyword)。

附圖說明

圖1——本發(fā)明整體流程圖。

圖2——本發(fā)明Tag-LDA模型的示意圖。

圖3——本發(fā)明Stack Overflow上用戶提交的用戶問題示例示意圖。

圖4——本發(fā)明Stack Overflow上的一個答案示例示意圖。

圖5——本發(fā)明Stack Overflow上的另一個答案示例示意圖。

圖6——本發(fā)明commit庫中一個示例示意圖。

圖7——本發(fā)明中在文件JSONPath.java中修改代碼的部分示意圖。

圖8——本發(fā)明中在文件JSONPath_4.java中修改代碼的部分示意圖。

具體實施方式

本發(fā)明提供一種基于Stack Overflow和commit庫的bug定位方法，下面結合附圖對本發(fā)明的技術方案進行詳細說明：

(1)將用戶提交的bug問題分解成問題段、代碼段、stack trace段三個子段。如圖3為Stack Overflow上用戶提交的一個問題示例，為一個用戶提交的問題，問題文檔如下：

經過問題分解后，結果為

效果：將問題分解，利于對不同性質的文本進行查詢，得到更準確的查詢結果。

(2)根據分解得到的問題段Json’s key’s value is string type，when only contain numbers and‘.’There are some questions#735，先進行預處理，移除數字、停用詞，進行分詞等操作。

得到的文本為：Json key value string type number contain question然后使用RAKE算法進行關鍵字提取，RAKE算法計算過程為：

對Json，單詞的度wordDegree(Json)＝3，詞頻wordFrequency(Json)＝1

得單詞Json的得分wordScore＝wordDegree(Json)/wordFrequency(Json)＝3

同理，其他單詞的得分分別為

wordScore(key)＝wordDegree(type)/wordFrequency(type)＝4/1＝4，

wordScore(value)＝wordDegree(value)/wordFrequency(value)＝3/1＝3，

wordScore(string)＝wordDegree(string)/wordFrequency(string)＝2/1，

wordScore(type)＝wordDegree(type)/wordFrequency(type)＝2/1＝2，

wordScore(contain)＝wordDegree(type)/wordFrequency(type)＝2/1＝2，

wordScore(number)＝wordDegree(type)/wordFrequency(type)＝2/1＝2，

wordScore(question)＝wordDegree(type)/wordFrequency(type)＝1/1＝1

排序后選取得分大于等于2的單詞作為關鍵字，得到的關鍵字為key Json value string type contain number，共7個

將所得到的關鍵字對Stack Overflow歷史問題庫中的每個問題的標簽進行匹配，將每個歷史問題答案對的標簽與第二步得到的關鍵字進行比較，計算相同標簽所占比重。如下是問題庫中的幾個問題：

問題一：

NumberFormatException when parseing in Android and JSON.String-->

double

標簽：json string android parsing double

問題二：

How to handle a NumberFormatException with Gson in deserialization a JSON

response

I′m reading a JSON response with Gson，which returns somtimes a NumberFormatException because an expected int value is set to an empty string.Now I′m wondering what′s the best way to handle this kind of exception.If the value is an empty string，the deserialization should be 0.

標簽：java json deserialization gson

問題三：

NumberFormatException in GSON when converting String to double

I am working with a JSON response that is improperly formatted.All fields are being returned as Strings.Unfortunately，l have no control over the return data.

根據公式：

匹配度＝相同標簽個數/所有不重復的標簽個數

問題一的匹配度為2/10＝0.2，問題二的匹配度為1/10＝0.1，問題三的匹配度為1/10＝0.1。

根據計算結果，提取出匹配度最高的問題一的問題答案對。

效果：Stack Overflow作為基于眾包的軟件工程領域最受歡迎的問答網站，其問題庫中包含大量與開發(fā)相關的問題，利用Stack Overflow問題庫，查找bug錯誤解答結果，給出更準確的定位。

(3)將步驟2得出的最優(yōu)結果答案一中的代碼提取，與問題的代碼段結合，整合為問題代碼段+答案代碼段形式。

(4)對步驟3整合的結果，使用RAKE，即Rapid Automatic Keywords Extraction算法提取出關鍵字，同步驟2，推薦出關鍵字為String，JSON，java，NumberFormatException，exception，Double，將這些關鍵字設置為標簽tag，使用tag-LDA對commit庫主題進行處理，結合tag進行匹配，篩選出匹配度0.3以上的commit代碼段。篩選出到如圖6的兩個commit代碼段。

效果：準確快速匹配篩選出commit庫中的結果

(5)對步驟3得出的結果的代碼部分與步驟4得到的commit代碼進行文本相似度匹配。

根據步驟4，對文件JSONPath.java和JSONPath_4.java中修改代碼的部分預處理，包括分詞，去停用詞，移除數字，詞根化等，過后：

文件JSONPath.java中修改部分的向量表示為D1

(<String，3>，<JSON，2>，<Segment，4>，<return，2>)

文件SONPath_4.java中修改部分的向量表示為D2

(<String，1>，<JSON，4>，<java，1>，<object，2>)

對步驟4所得代碼+StackTrace向量表示為D

(<String，6>，<JSON，5>，<java，1>，<NumberFormatException，3>，<exception，2>，<Double，5>)。

根據余弦公式計算文件JSONPath.java中修改部分與問題的內容相似度：首先量化D1和D，由于D和D1中共出現String，JSON，NumberFormatException，Double，Segment，return，java，exception 8個單詞，按這種順序進行量化如下，

D1(3，2，0，0，4，2，0，0)，

D(6，5，3，5，0，0，1，2)

根據余弦公式計算得cos<D，D1>＝0.0921

同上處理D和D2，D和D2中共出現String，JSON，java，object，NumberFormatException，exception，Double 7個單詞，按順序量化如下：

D2(1，4，1，2，0，0，0)

D(6，5，1，0，3，2，5)

計算得cos<D，D2>＝0.1108。

利用由節(jié)點，即類、class，和有向線段，即方法，組成的程序依賴圖對由步驟1分解得到的堆棧追蹤，即stack trace，進行結構相似度匹配。

如圖7，為程序依賴圖中在文件JSONPath.java中修改代碼的部分，得結構匹配度為0。

如圖8，為程序依賴圖中在文件JSONPath_4.java中修改代碼的部分，得結構匹配度為1。

效果：從文本和結構兩方面進行匹配，分別得出相應結果，便于下一步綜合計算。(6)根據前面計算得到的文本相似度和結構相似度進行綜合計算，計算30％×文本相似度+70％*結構相似度的結果。

如步驟3，對文件JSONPath.java中修改的部分代碼

根據余弦公式計算的文本余弦匹配度cos<D，D1>＝0.0921

結構匹配度為0

綜合結果＝0.02763

對文件JSONPath_4.java中修改的部分代碼

根據余弦公式計算的文本余弦匹配度cos<D，D2>＝0.1108

結構匹配度為1

綜合結果＝0.73324

根據以上計算，推薦JSONPath_4.java commit部分

盡管本發(fā)明就優(yōu)選實施方式進行了示意和描述，但本領域的技術人員應當理解，只要不超出本發(fā)明的權利要求所限定的范圍，可以對本發(fā)明進行各種變化和修改。