1 引用
Zhou C. Intelligent bug fixing with software bug knowledge graph[C]//Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. ACM, 2018: 944-947.
2 摘要
隨著軟件規模和複雜性的增加，bug修復變得越來越困難。bug和開源項目、問答和其他軟件資源的數據包含大量 Bug 知識，可用於幫助開發人員理解和修復 Bug。現有工作側重於從單一特定的軟件資源中獨立挖掘數據，幫助修復錯誤，但是可能會降低錯誤修復的效率。
如何從多源軟件數據中獲得、組織和理解bug知識，這個問題尚需解決。為了解決這個問題，我們利用知識圖譜（KG）探索了多源軟件數據中深層的語義和結構關係，提出了基於知識圖譜的搜索和推薦技術，並設計了一個bug修復的知識問答系統，以幫助開發人員進行智能的軟件bug修復。目前，我們設計了一個bug知識圖譜構建框架，提出了Bug知識實體和關係的識別規則和方法，構建了基於Bug庫的初步知識圖譜。在以下工作中，我們將進一步完善知識圖譜，完成多源數據的知識圖譜融合，通過知識推理理解bug，利用協同搜索推薦技術進行bug修復知識問答。
關鍵詞：智能bug修復，軟件bug知識圖譜，協同搜索推薦，bug修復問答。
3 介紹
由於對需求的理解偏差、開發過程不合理或開發人員沒有經驗，軟件bug發生引起運行錯誤，從而導致異常結果或行為。在嚴重的情況下，可能造成無法彌補的巨大的損失。為了便於管理這些軟件bug，許多大型軟件系統都配備了bug跟蹤系統，以收集跟蹤軟件項目的bug,比如bugzilla。在 Bug 跟蹤系統中（也稱為 Bug 存儲庫），每個 Bug 的整個生命週期為從提交/打開到被修復/審查。同時，開發人員也喜歡在軟工問答社區中（如 StackOverflow）搜索、溝通和協作，分享經驗，並快速更新信息。在 StackOverflow中發佈的許多問題中，有些問題提供了Bug 的描述和解決方案。這些開源軟件社區（例如源代碼，錯誤報告，問答文檔）包含大量複雜和語義相關的Bug信息，可以幫助開發人員理解Bugs執行修復。
但是，如何組織和使用知識來修復 Bug 面臨著許多挑戰：
l 各種Bug 相關的數據通常是異構的、不均衡的，並且包含噪聲。由於規模和複雜性的增加，bug 數據不斷擴展和更新速度加快。現有的搜索引擎不能幫助軟件開發人員準確獲取必要的知識，信息使用的效率也降低了。
l Bug 知識是從多源軟件數據中提取的。不同的數據源具有不同的數據格式和內容，並有自己的特徵。目前的漏洞信息檢索工作大多侷限於從某一軟件平臺挖掘數據，沒有對多源數據進行關聯挖掘。
l Bug 知識是一個多維度知識集合，包含Bug 描述文本、Bug的代碼環境以及其他 Bug屬性。獲取數據時，會人為地遺漏某些類型的bug數據。在現有研究中，人們總是忽略bug報告和源代碼之間的整體結構特徵和內部語義連接。
知識圖譜，作為一種新的知識表示和管理方式，能有效地為用戶提供更全面的信息和知識。軟件bug知識圖譜是由來自不同軟件資源的bug知識圖譜組合而成的知識系統，用於使用各種類型的bug特定實體描述某一bug。bug特定實體是指在bug數據中可區分、可識別並具有特定語義關係的單元。
基於知識圖譜的智能Bug修復主要有以下五個步驟：Bug數據採集、Bug知識圖譜構建、Bug分類、Bug定位和Bug修復建議。目前，我們已經做了以下工作：（1）通過分析大量的bug數據，設計了一個bug知識圖譜構建框架。（2）分析了軟件源代碼、Bug報告、問答文檔的Bug知識特徵，定義了Bug相關概念層，分別提取了相應的Bug特定實體、關係和屬性，構建了基於Bugzilla的初步知識圖譜。為了繼續智能Bug修復工作，我們計劃通過知識推理獲得Bug知識，並提供Bug的精確分類。然後，利用協作搜索和推薦技術進行錯誤修復知識問題和回答。
3 已完成的工作
圖1 軟件bug知識圖譜的構建框架
3.1 bug知識圖譜
圖1顯示了軟件bug知識圖譜的構建框，該框架由四部分組成：Bug知識提取、Bug知識融合、Bug知識圖譜存儲與管理、Bug知識推薦。
考慮到bug知識的兩個特徵：多源（不同軟件數據源的數據結構不同）和多維（每個Bug都可以從多個維度理解），我們首先定義了知識實體的概念層和統一的正式表示形式
Bugzilla 等 Bug 跟蹤系統以 Bug 報告的形式記錄和管理Bug。每個 Bug 報告及其 Bug 描述文本和修補程序都可以作為知識實體進行提取。實體屬性設置如下：
Bug = {Identifier, Product, Component, Priority, Status, Reported data, Reporter, Modified data, Assignee, Version, Target}
Textual Description = {Identifier, Title, Description, Comment, Commit message, Commenter, Updater, Comment data, Update data}
Code Context = {Identifier, Patch name, Patch content, Submit- ter, Create date, Code-line, Bug-location, Language, Repair structure}
Stack Overflow等問答類社區以問答文檔的形式記錄管理數據。我們只選擇與bug相關的Q&A數據。每個問題及其問答描述文本和開發者都可以被提取為一個知識實體。實體屬性設置如下:
Question = {Question Identifier, Question Tag, Votes, Be adopt answer identifiers, Views, Questioners, Question date}
Textual Description = {Identifier, Question, Answer, Com- ment, Answer votes, Responder, Answer data, Commenter, Com- ment data}
Developer = { User ID, User Display Name, User Reputation, Votes, Criticism, Views, Created Date , Latest Visit Date}
Github等軟件項目管理平臺以存儲庫的形式儲存和管理軟件項目。我們只選擇與 Bug 相關的代碼數據來幫助解釋 Bug 知識圖譜。每個 Bug、修復程序和開發人員都可以提取為知識實體。實體屬性設置如下：
Bug = {Identifier, Product, Status, Reported data, Reporter, Mod- ified data, Assignee, Version }
Code Context = {Identifier, Patch name, Patch content, Submit- ter, Create date, Code-line, Bug-location, Language, Repair structure}
Developer = { User ID, User Display Name, User Reputation, Stars, Criticism, Views, Created Date , Latest Visit Date}
3.2軟件bug特定的命名實體識別
命名實體識別(NER)是用於構建知識圖譜信息推理的一個子任務，它旨在將目標文本中的命名實體分類到預定義的類別中。通過對軟件bug庫中大量bug再現的研究，總結出bug報告中實體的三個特徵:詞性、描述短語和實體分佈。基於這些特徵，我們開發了一個用於缺陷實體分類的分類法，如表1所示，並在兩個開源項目Mozilla和Eclipse上構建了一個基準缺陷數據庫。
我們提出了一種基於CRF模型的半監督bug 命名實體識別方法BNER，定義了一組基於基線語料庫的模型訓練特徵，然後使用word embedding技術從整個軟件缺陷庫中提取特性。我們對Mozilla和Eclipse這兩個項目進行了研究，結果表明設計的基線語料庫是有用的，使用非監督詞嵌入作為bug特定實體的特性對BNER的影響最大，該方法對於跨項目的NER也是有效的。
4 正在做的工作
4.1基於 Bug 知識圖譜的 Bug 自動分類
分析軟件bug需要對軟件bug分類，準確合理的 Bug 分類不僅可幫助開發人員瞭解 Bug，還可以幫助開發者洞察問題的存在，並提出解決方案。當用戶報告的新bug被分配給開發人員時，他們首先需要理解bug報告表達了什麼，以及為什麼會出現這個bug，然後才能修復它。經過多輪修改，最終確定修復方法。在實際的修復過程中，確定“為什麼”是確定“如何”的必要條件。同時，開發人員總是通過回顧相關歷史bug的“如何”信息來確定“為什麼”。基於知識圖譜的強大關聯和推理功能，我們可以從三個維度what, why 和 how對 Bug 進行分類。在我們的工作中，軟件 Bug 的分類遵循以下三個步驟：
首先，根據Bug 報告（如安全錯誤、性能錯誤和功能錯誤）中的信息，Bug 文本描述實體被分類為"what"類別。
然後，根據bug修復的性質，從程序構造的角度進行分類。代碼上下文實體可以分為三個"how"類別：缺少結構、錯誤結構、冗餘結構。它們將進一步分類並細化到特定類型, 是bug的進一步擴展。每種類型是根據其語言結構和程序上下文定義的。修復通常是微不足道的，儘管對程序的進一步分析可能增加實現開銷，但是更精確的錯誤類型提供了更精確的歷史“how”信息。
最後，在構建 Bug 知識圖譜後，通過對大量數據的探索，探索描述文本和 Bug 修復模式之間的連接，以確定 Bug 的原因，並從“why”的角度對bug實體進行分類。
總之，自動分類過程是對錯誤的綜合分析和表徵，可以有效地指導以下智能錯誤修復過程。
3.2 錯誤修復搜索和建議
圖2顯示了建議的bug修復搜索和推薦框架。用戶報告的大多數新bug信息都是不完整的。該系統通過形式化搜索和子圖匹配，將相關的歷史bug信息作為候選集在知識圖譜中搜索。用戶可以進一步驗證候選集以獲得準確的搜索結果。通過候選集的信息，對新bug進行補全和自動分類。經過一定數量的人機交互，最終推薦最合適的bug修復位置和補丁。3.3 用於智能修復錯誤的 QA 系統
問答系統（QA）是一種有效的手段，幫助人類理解和解決問題。在我們的工作中，我們還致力於實現 QA 以幫助開發人員實現智能bug修復。從用戶提出的問題q開始，我們首先識別相應bug知識圖譜中的實體d，並根據d的概念分佈生成模板t。最後，給定實體 d 和模板 t 的屬性 p，我們通過搜索知識圖譜獲得答案。此外，還可以通過瀏覽知識圖譜來推薦一些bug修復信息，如 Bug 位置和修復解決方案。通過這種方式，開發人員可以更高效地理解和修復分配給他的 Bug。
4 本文主要貢獻
開源項目的源代碼、bug 報告、問答文檔和其他軟件資源包含大量具有複雜結構和豐富語義關聯的Bug 知識，可用於幫助開發人員理解和修復 Bug。知識圖譜適用於存儲和管理這種大規模、複雜結構和語義相關的 Bug 知識。在我們的工作中，我們旨在利用知識圖 （KG） 技術進行智能 Bug 修復，即基於知識圖譜進行搜索推薦，並設計一個 Bug 修復知識 QA 系統，以幫助開發人員有效地理解 Bug、錯誤位置和 Bug 解決。
致謝
本文由南京大學軟件學院2019級碩士汪匯翻譯轉述。
感謝國家重點研發計劃（2018YFB1403400）和國家自然科學基金（61690200）支持！
閱讀更多 慕測科技 的文章
