OSDR：一種開源軟件的缺陷修復人推薦方法

張 文 李自強 杜宇航 趙博揚

(北京化工大學大數據科學研究中心 北京 100029)

?

OSDR：一種開源軟件的缺陷修復人推薦方法

張 文 李自強 杜宇航 趙博揚

(北京化工大學大數據科學研究中心 北京 100029)

對于大型開源軟件項目來說，用戶提交了海量缺陷報告，人工分發缺陷時會出現大量的錯誤分配。提出OSDR(Open Software Developer Recommendation)方法通過計算新缺陷報告和歷史缺陷報告之間的文本相似度，基于K最近鄰算法得到相似度最高的K個歷史缺陷報告及其對應的修復人列表，再基于頻率和社交網絡圖的各項指標對開發者專業能力進行評價。從Mozilla Firefox 缺陷庫中采集真實實驗數據，比較不同社交網絡指標在推薦修復人時的準確率與召回率。結果表明,推薦性能最高的指標是頻率和出度，其準確率大約在0.6左右；Betweenness和Closeness的推薦效果最差；度、入度以及PageRank推薦效果良好。

開源軟件 缺陷報告 修復人推薦 社交網絡分析

0 引 言

開源軟件是源碼向公眾開放的一類軟件，其源碼的修改不受許可證的限制。隨著開源軟件的規模和復雜程度不斷增加，不可避免會有眾多的缺陷存在。缺陷會給用戶帶來使用上的不便，對軟件的可靠性和可用性都帶來顯著影響，其數量也是評價軟件質量的重要因素。

大型開源軟件項目如Apache、Eclipse和Mozilla等均采用開放缺陷跟蹤系統來管理軟件缺陷，為用戶提交缺陷報告和開發者解決軟件缺陷提供了方便。在傳統的方式中，軟件缺陷報告在缺陷追蹤系統中被人工分配給開發者進行修復。在各個大型的開源項目開發的早期階段，簡單的修復人推薦機制依然能夠滿足需求，但是隨著分配任務量的大幅度增加，任務對于一個人來說過于繁重。例如，對于開源項目Mozilla Firefox來說，每天大約有300多個需要分配的新缺陷報告被提交，這大大超過了Mozilla項目中的缺陷分配人員所能承受的任務量，平均需要40天才能把一個bug分配給它的第一個修復人。正是因為手工缺陷分配過程的復雜性，很多缺陷報告會被誤分配給不適合修復它的開發者，還要重新進行缺陷分配，這反過來又增加了缺陷修復的整體時間。巨大的工作量和易錯性成為了整個系統的瓶頸，嚴重影響了軟件開發的效率，增大了軟件項目的成本[1]。不僅如此，缺陷分配人員需要充分了解開發任務、項目方向、團隊結構、開發者的經歷和等級，以及其他與該缺陷報告相關的信息才能做出準確的缺陷分配。除此之外，傳統缺陷跟蹤系統的運行機制會導致大量的缺陷報告分配給不具備相應修復能力的開發者，進而導致大量缺陷報告的再分配。一個開發者的專業知識有限，而一個缺陷可能不止涉及一個專業。這些都會大大的降低缺陷修復的效率。

本文提出一種名為OSDR的開源軟件缺陷的修復人推薦方法。該方法采用自動化的方式，基于開源項目的開放缺陷庫中的已經被解決的缺陷報告，以及開源社區中眾多的開發者提交的修復評論，對新被提交的缺陷進行修復人推薦。當一個新的缺陷報告被提交到缺陷庫中后，該方法計算新缺陷報告和歷史缺陷報告之間的文本相似度，得到K個與新缺陷報告相似度最高的歷史缺陷報告。進而提取出這些歷史缺陷報告對應的開發者，并據此建立社交網絡圖，最后使用7種指標對開發者的專業能力評級，從而推薦出合適的缺陷修復人。

1 相關研究

現有的缺陷報告分配方法可以分為兩類：第一類是將缺陷修復人推薦問題看作為一種分類問題，這類方法首先對開發者的興趣或專業領域進行分類，然后將新提交的缺陷報告按照類別匹配給開發者作為缺陷修復人。第二類方法是通過計算模型得到新提交的缺陷報告與歷史缺陷報告之間的相似度，然后對相似的歷史缺陷報告中的開發人員進行能力評級，最后將能力較高的開發人員推薦為該新缺陷報告的修復人。

在上述第一類方法的研究中，Jifeng Xuan等[2]使用了社交網絡圖的方法建立一種缺陷修復人的分析機制。通過修復人在論壇中的評論，此方法對修復人的專業能力進行分類，并且為其設置能力標簽。CosTRIAGE[3]使用LDA(文檔主題生成模型)來驗證缺陷報告的主題并且對修復人畫像進行建模，以此計算修復人對相關缺陷的平均修復水平。Olga Baysal等[4]提出了一種缺陷報告自動分配的框架，該框架能夠根據開發者的開發歷史推斷出其專家級別和專業方向。Matter等[5]提出了一種基于源代碼的經驗模型以比較修復人的貢獻經歷和缺陷報告的處理，之后該模型推薦新缺陷報告與歷史缺陷報告之間貢獻經歷語義相似度最高的修復人作為最終推薦人。John Anvik等[6-7]提出了一種自動推薦程序軟件，該軟件能夠提供一種包含之前已修復的缺陷報告信息的模型，進而形成一種能夠推薦項目修復人專業程度的算法。

在上述第二類方法的研究中，Tao Zhang等[8]首先抽取出與新缺陷報告相似的歷史報告，接下來建立社交網絡圖代表修復人之間的關系，所涉及的因素包括修復時間和來自相似歷史文件的修復人。最后在候選者中，通過DRA修復人排行算法來推薦修復人。Zhang等[9]提出的混合式缺陷分類策略可以優化修復人推薦進程。在判斷新舊缺陷報告相似性階段，該策略選擇了一元平滑模型，同時結合了機率模型和經驗模型。DRETOM[10]使用歷史修復記錄來建立模型。對于每一個缺陷報告，其自然語言內容被提取和預處理來進行建模，相應的修復人也被提取出，兩者的雙邊聯系模型得到建立。DevRec[11]由缺陷分析和修復人分析組成。在缺陷分析中，根據新的缺陷報告與舊的缺陷報告的相似性，將其分類。之后，根據每個修復人已修復的缺陷報告的特征計算修復人與該新被提交的缺陷報告的親和度。Kanwal等[12]提出了一種基于支持向量機和樸素貝葉斯算法的缺陷報告優先級預測分類算法，同時探尋了不同的缺陷屬性對缺陷優先級分類的重要性。Servant等[13]提出了一種新的基于錯誤定位技術和軟件源碼歷史的缺陷修復人智能推薦技術。該技術拋棄了原始的缺陷報告的文本匹配，能夠定位缺陷，根據歷史記錄來確定修復人。

在上述兩種方法中，缺陷報告中的文本描述的質量和缺陷修復人專業領域對于缺陷推薦的結果是決定性的因素。缺陷報告質量高的缺陷會很容易的推薦，而缺陷報告質量低的缺陷則難以及時推薦。由于不同的缺陷提交者對缺陷有不同的理解，且書寫風格也不盡相同，有些缺陷描述會含糊不清。往往一個缺陷的出現涉及多個專業領域，一個缺陷修復人的專業知識有限，這些都導致很難較快較好地完成缺陷修復。

2 OSDR缺陷修復人推薦方法

2.1 問題描述

為了方便描述，OSDR方法涉及的主要概念包括文檔，以及缺陷修復相關的開發者有序集合。下面分別給出它們在本文中的定義。

定義1歷史缺陷報告文檔：歷史缺陷報告文檔是指在缺陷庫中已經被完成缺陷修復任務的缺陷報告，用bughis表示。

定義2新缺陷報告文檔：新缺陷報告文檔bugnew是指新增的被提交、被確認為軟件缺陷的報告。

定義3相似的歷史報告：相似的歷史報告bugsim是指利用新提交的缺陷報告和歷史缺陷庫，選用KNN算法，找出相似的缺陷報告，以便找到其對應的開發者。

定義4歷史缺陷修復人：對于每個歷史缺陷報告bughis, 它的缺陷修復相關的開發者集合為devi(i=1，2，3，…)。

假定在一個開源項目中有n個開發人員，并且在該項目的開放數據庫中具有m個歷史缺陷報告，每個缺陷報告都擁有一系列關于解決該缺陷報告的評論。這些評論是對該缺陷感興趣的開發者提出的。我們難以確定每個評論對缺陷修復的貢獻，同時由于這些缺陷修復討論發生在這群開發者之間。因此，啟發式地我們認為其中的所有開發者都為該缺陷修復做出了貢獻，但是貢獻大小主要從發表評論的次數以及討論過程中形成的開發者交流網絡拓撲結構來反應。

因此，我們可以將推薦缺陷修復相關問題描述為：針對一個新缺陷報告, 需要通過模型M來推薦一定數量的開發者，這些個開發者具備修復新缺陷報告的相關經驗知識并可能對該缺陷報告的解決作出貢獻。本文認為在一個大型軟件項目中，缺陷修復是一種開發者群體協作行為，專注相同軟件模塊或相近模塊的開發者常常會形成群體。為了初步確定這一開發者群體，本文利用新提交的缺陷報告和歷史缺陷庫，選用KNN算法，找出與k個相似的缺陷報告，進而找出背后的開發者們。

2.2OSDR方法原理

OSDR采用的總體結構如圖1所示。當一個新缺陷報告被提交到開放缺陷庫，OSDR首先計算新缺陷報告的描述和歷史缺陷報告的描述之間的文本相似性，基于KNN算法提取出一系列相似度高的歷史報告得到相似缺陷庫，從而找出其對應的修復人。然后構建修復人溝通網絡，OSDR方法使用頻率和社交網絡圖各指標對這些開發者們的專業能力進行評級。最后相似歷史缺陷報告對應的開發者中的具有較高專業度的開發者們將被推薦給這個新的缺陷，作為解決問題的修復人。

圖1 OSDR方法的整體結構

1) 提取相似報告集：每個缺陷報告都含有預定義的屬性和自有格式的文本描述。在本文的方法里面，只有自由格式的文本描述被使用，文本描述包含了缺陷的關鍵字和對該缺陷報告的簡介。當一個新的缺陷報告被提交的時候，首先利用文本向量空間模型將其轉換為成文本向量；然后OSDR方法在新的缺陷報告和眾多歷史缺陷之間計算它們之間的相似性；最后，對于給定的最為相似的歷史缺陷報告數目K，將具有最高相似性的K個歷史缺陷報告被從開放缺陷庫中提取出來，作為新缺陷的相似缺陷集。

2) 排行開發者專業度：得到了新的缺陷報告的相似報告集之后，就要進而得到其對應的開發者列表。同時這些開發者在相似報告集中的參與記錄可以被用來評價開發者在解決該缺陷方面的專業程度。本文的研究采用七種評價指標來排行修復人的專業程度，第一個指標是每個開發者在參與記錄中的出現頻率，另外六個是社交網路圖分析中的評價指標。

當使用頻率的時候，對于每個缺陷開發者，OSDR方法計算出他在相似的缺陷報告中的出現頻率，使用社交網絡圖的指標時候，首先OSDR方法根據開發者的參與記錄生成一個社交網絡圖。在該方法中，生成社交網絡圖的規則如圖2所示。通過式(1)計算相似度，Sim(bugnew,bughis1)和Sim(bugnew,bughis2)是計算新的缺陷和各個歷史缺陷的相似性(這里舉兩個bughis1和bughis2的例子)。dev1等代表的是各個歷史缺陷報告中的所有開發者集合。箭頭的意義在于本文認為評論靠后的開發者參考了評論在前的開發者的解決辦法。之后該方法采用度(degree)，出度(out-degree)，入度(in-degree)，中心性(betweenness centrality)，接近性(closeness centrality)，佩奇排行(PageRank)來對網絡圖進行分析。開發者出現的頻率是另外一個參考指標。

(1)

圖2 社交網絡圖生成示例

本文利用JUNG(Java開源社交網絡圖框架)軟件生成的社交網絡圖如圖3所示，各個節點代表的是修復人的編號，其權重指的是缺陷報告之間的相似性。由圖可以直觀地從這個社交網絡圖中看到缺陷修復人之間的關系，同時也可以高效地使用degree等六種指標進行社交網絡圖節點重要性的評判節點重要性的評判。

圖3 OSDR方法生成的社交網絡圖

2.3 OSDR相關技術

本文介紹的OSDR方法，首先對數據做自然語言預處理。然后采用TF-IDF技術對自然語言文本進行處理，來方便計算缺陷之間的相似度。之后運用KNN算法找出k個相似的歷史缺陷。再確定其修復人。最后利用社交網絡圖分析來排序，得到結果。

(1) 自然語言預處理

文本預處理能夠完善數據的完整性，是數據挖掘過程中的重要階段。在該軟件中，正則表達式的應用可以去除無意義的符號等數據，也可以幫助研究人員提取符合一定格式的數據，OSDR方法去除了對缺陷描述中的無意義的符號、噪聲數字和亂碼。

詞干提取是對文本進行處理的重要環節，在該軟件中，OSDR使用Porter英文詞干提取算法，該算法可以用來高效準確還原英語時態、單復數和否定等變換詞的詞干，增加文檔間相似度計算的精確性。在停詞處理是去除文本中的無用的詞匯，本文采用常用的英文的停詞表 作為OSDR方法的去除停詞模板。

(2) 空間向量模型轉換

(3)K最近鄰算法

KNN(K最近鄰)算法是應用最廣泛的分類算法之一，其原理是每個樣本都可以用它最接近的k個鄰居來代表。本文應用KNN算法的核心思想來，即計算新產生的缺陷與缺陷庫中不同的缺陷報告的相似性，通過對比計算相似性，得到K個相似度最高的原有缺陷報告作為基礎[15]，進而提取其對應的多個缺陷的開發者作為備選的修復人：{dev1,dev2,dev3,…}。OSDR方法使用夾角余弦來進行文本相似性的計算，同時根據用戶對K的設定，來得出相似性最高的K個報告。同時從開放缺陷庫中提取出相應的缺陷修復人列表。

(4) 社交網絡圖分析

社交網絡圖分析被用來分析社會學，并且通常會用來分析一個社交系統成員之間的復雜的關系，目的通常都是解釋社交現象。社交網絡圖能夠展示出各個節點之間的聯系，可以用來評價修復人的專業度。社交網絡很早就被表示成圖的形式，其節點表示這社交角色，邊代表著角色之間的關系[16-17]。

社交網絡圖的功能就是通過修復人在網絡圖中的位置，排行它們的重要性。本文使用中心性這個概念，具有較高中心性的節點意味著在網絡圖中更高的重要性。在本研究中，度、出度、入度、PageRank，Betweenness，Closeness被用來評價節點重要性。

3 實 驗

3.1 實驗設定

本文使用精度(precision)和查全率(recall)來進行評判指標，本文使用{dev1,dev2,…}來表示推薦結果，使用{realresult}表示實際人工分配結果，精度是指推薦結果和實際人工分配結果的交集占推薦結果的比率，查全率是指推薦結果和實際人工分配結果的交集占實際人工分配結果的比率，如式(2)和式(3)所示。

(2)

(3)

實驗的數據來源是Mozilla的缺陷報告庫，共有數據418 372條，全部是經過整理后的格式規范的缺陷報告數據。實驗數據只使用最終結果為“fixed”的數據，為124 667條數據，數據詳情如圖4所示。

圖4 實驗數據描述

本文設計的實驗需要去除低頻率的修復人，以提高實驗的精度和查全率。本文設置frequency作為數據代替值。經過參數的調整，將該值設置成為80。實驗需要設定與新缺陷報告相似性最高的K個歷史缺陷報告，經過反復實驗和參數調整，將K設定為20。實驗從原始數據中隨機提取出5組數據，每組分為訓練集和測試集。其中訓練集和測試集保證優先級和產品類別、組別相同。每組訓練集數據為5 000條，測試數據100條。

3.2 實驗結果

由于已經將開發者的出現頻率和相似報告數量進行預設，實驗的變量為要推薦的修復人的數量。通過修改推薦的數量(1～10個)，各個指標的顯示結果如圖5和圖6所示(圖中指標為：frequency、closeness、betweenness、out-degree、in-degree、degree、pagerank)。

圖5 不同指標的查準率

圖6 不同指標查全率

通過實驗可以看到，最大的精度是frequency在只推薦一個修復人時達到，約為0.69。最大的查全率是frequency在推薦10個修復人時達到的，約為0.62。Closeness和Betweenness兩個指標都不能得到良好的推薦效果，其查準率都在0.3之下，查全率一直在0.4之下，推薦結果不能滿足實際需求。

總體來看，out-degree與frequency相比略遜一籌，但是訓練集中的數據大概平均有5個修復人。由于Mozilla Firefox項目中有上千的修復人，所以out-degree也能夠作為推薦指標之一。其他幾個指標，除了closeness和betweenness之外，都具有較好的缺陷修復人推薦性能，即保證推薦查準率在65%以上。在實際應用中，即使是人工分配，也會因為個人、環境和知識因素等而出現分配錯誤，所以在允許誤差的范圍內，本文認為OSDR的推薦修復人所達到的性能能夠應用到實際項目中。

4 結 語

本文提出了OSDR方法來進行缺陷修復人的自動化推薦，該方法使用了缺陷報告的描述和開發者在開發缺陷庫中的評論。當一個新的缺陷報告被提交的時候，該方法的運行原理是首先得到與之相似度高的歷史缺陷報告，進而采用多種指標評價這些歷史缺陷報告對應的開發者的專業能力，最后得到最匹配的缺陷修復人。實驗表明，在應用該方法來進行缺陷修復人推薦時，開發者在開放缺陷庫中出現的頻率和社交網絡圖中的出度是精度最高的評價指標。但是，有一些因素會影響到該方法的準確率，例如實驗的數據集來自于MozillaFirefox社區，這就需要該方法應用的領域的數據的格式應盡可能與之相同。然后就是評論中的一些言論可能并不能對問題的解決帶來幫助，這也將影響到社交網絡圖生成時候的精確度缺失。在未來的工作中，進一步的研究將完善數據質量和提升OSDR的泛化能力。

[1] Zhang W, Wang S, Wang Q. KSAP: An approach to bug report assignment using KNN search and heterogeneous proximity[J]. Information & Software Technology, 2015, 70:68-84.

[2] Park J W, Lee M W, Kim J, et al. CosTriage: A Cost-Aware Triage Algorithm for Bug Reporting Systems[C]// AAAI Conference on Artificial Intelligence, San Francisco, California, Usa, August. DBLP, 2011.

[3] Baysal O, Godfrey M W, Cohen R. A bug you like: A framework for automated assignment of bugs[C]// IEEE, International Conference on Program Comprehension. IEEE Xplore, 2009:297-298.

[4] Matter D, Kuhn A, Nierstrasz O. Assigning bug reports using a vocabulary-based expertise model of developers[C]// IEEE International Working Conference on Mining Software Repositories. IEEE, 2009:131-140.

[5] Anvik J. Automating bug report assignment[C]// International Conference on Software Engineering. DBLP, 2006:937-940.

[6] Tamrawi Ahmed, Tung Thanh Nguyen, Jafar Al-kofahi, et al. Fuzzy set and cache-based approach for bug triaging[J]. Dissertations & Theses Gradworks, 2011:365-375.

[7] Zhang T, Lee B. How to Recommend Appropriate Developers for Bug Fixing?[C]// Computer Software and Applications Conference (COMPSAC), 2012 36th Annual. IEEE, 2012:170-175.

[8] Zhang T, Lee B. A Hybrid Bug Triage Algorithm for Developer Recommendation[C]// The 28th ACM Symposium on Applied Computing. 2013:1088-1094.

[9] Xie X, Zhang W, Yang Y, et al. DRETOM: developer recommendation based on topic models for bug resolution[C]// ICPMSE 2012: International Conference on Predictive Models in Software Engineering 2012. ACM, 2012:19-28.

[10] Xia X, Loy D, Wang X, et al. Accurate developer recommendation for bug resolution[C]// Reverse Engineering (WCRE), 2013 20th Working Conference on. IEEE, 2013:72-81.

[11] Kanwal J, Maqbool O. Bug Prioritization to Facilitate Bug Report Triage[J]. Journal of Computer Science & Technology, 2012, 27(2):397-412.

[12] Xuan J, Jiang H, Ren Z, et al. Developer prioritization in bug repositories[C]// ICSE 2012: Software Engineering, 2012 34th International Conference on. IEEE, 2012.

[13] Servant F, Jones J. WhoseFault: automatic developer-to-fault assignment through fault localization[C]// ICSE 2012: Proceedings of the 34th International Conference on Software Engineering, 2012. IEEE Press, 2012:36-46.

[14] Zhang W, Tang X, Yoshida T. A comparative study of TF*IDF, LSI and multi-words for text classification[J]. Expert Systems with Applications, 2011, 38(3):2758-2765.

[15] 金弟, 劉杰, 賈正雪,等. 基于k最近鄰網絡的數據聚類算法[J]. 模式識別與人工智能, 2010, 23(4):546-551.

[16] Pohl M, Diehl S. What dynamic network metrics can tell us about developer roles[C]// International Workshop on Cooperative & Human Aspects of Software Engineering Acm. ACM, 2008:81-84.

[17] Ganev V, Guo Z, Serrano D, et al. Exploring and visualizing academic social networks[C]// CIKMP 2010: roceedings of the 19th ACM Conference on Information and Knowledge Management, October 26-30, 2010. Toronto, Ontario, Canada, 2010:1963-1964.

OSDR:ANOPENSOURCESOFTWAREDEFECTREPAIRDEVELOPERRECOMMENDEDMETHOD

Zhang Wen Li Ziqiang Du Yuhang Zhao Boyang
(CenterforBigDataSciences,BeijingUniversityofChemicalTechnology,Beijing100029,China)

For large open source software projects, users submit a large number of defect reports, manual distribution of defects will be a lot of misallocation. By calculating the similarity between the new defect report and the historical defect report,Khistorical defect reports with the highest similarity and the corresponding list of repair persons are obtained based on theKnearest neighbor algorithm, and then based on frequency and social network map of the indicators, the OSDR (Open Software Developer Recommendation) method proposed in this paper evaluates the developer’s professional competence. The real experiment data were collected from the Mozilla Firefox database to compare the accuracy and recall of different social network indicators when recommending the human. The results show that the recommended performance index is the frequency and out, and its accuracy is about 0.6 or so; Betweenness and Closeness recommended effect is the worst; Degrees, in-degree and PageRank recommended effect is good.

Open source software Defect Report Repair developer recommendation Social network analysis

2016-07-26。國家自然科學基金項目(61379046);中央高校基本科研業務費項目(buctrc201504)。張文，教授，主研領域：軟件工程，數據挖掘。李自強，碩士生。杜宇航，碩士生。趙博揚，碩士生。

TP3

A

10.3969/j.issn.1000-386x.2017.08.002