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级硕士汪汇翻译转述。