1 引用

Tomassi D A, Dmeiri N, Wang Y, et al. Bugswarm: mining and continuously growing a dataset of reproducible failures and fixes[C]//2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019: 339-349.

2. 摘要

错误检测，定位和修复技术对软件质量保障来说至关重要，但是目前很难评估它们的扩展性、适用性以及有效性。大型、多样化、真实的数据集上持久且可复现的缺陷与修复，对软件质量技术的实验评估来说至关重要，但是收集和维护它们往往非常困难且代价高昂。这样的现代持续集成(Continuous Integration，CI)方法(如 TRAVIS-CI)被广泛使用，它们是高度可配置的并且可以在定制容器内执行，使得我们有望向更大的缺陷数据集迈进。如果我们能够识别并存档相关失败和随后成功的测试，这些容器将为构建和测试的可复现提供保证。但是上述技术还需要克服一些局限性才能具有一定的实际价值。针对真实开源的软件系统，我们提出了工具 BUGSWARM，它可以创建一系列可扩展的，多样化的，真实的，持续增长的一组可复现的失败和成功版本。BUGSWARM 已经为 Java 和 Python 语言收集了 3,091 个失败-通过版本对，同时均包装在完全可复现的容器中。此外，该工具可以定期运行以检测失败-通过活动，从而不断增扩增们的数据集。

3 引言

软件缺陷对社会经济，出行安全和生活质量具有重要的影响。缺陷的识别和修复则会耗费大量时间和经济成本；而通过研究已有的缺陷及其修复方法，可以在新版本中更有效地处理甚至避免缺陷。一些软件工程子领域(如程序分析，测试和自动程序修复)专用于开发工具、模型以及方法来寻找并修复缺陷。理想情况下这些技术应在真实的最新缺陷数据集上评估，以便用户更好地了解其运行表现。这些数据集应包含失败通过对，具体分为失败的版本(可能包括触发程序失效的测试集)和通过的版本(包括修复缺陷的修改)。以此研究人员可以深入地评估缺陷检测技术，缺陷定位(静态或动态)技术以及缺陷修复技术的有效性。因此研究进展与包含失败成功对的高质量数据集密切相关。

对于那些包含失败成功对的数据集有以下几种可取的属性。(1)可扩展性：需要足够的数据以支撑工具评估统计意义；(2)多样性：数据的可变性足以控制诸如项目规模、成熟度、领域、语言、缺陷严重性、年龄等因素，同时仍保留足够的样本量进行充分的实验；(3)真实性：能反映程序员修复实际错误的真实修复操作。(4)实时性：不断更新的缺陷数据集，与语言、平台、库、软件功能等方面的变更保持同步，以便根据当前关注的领域和相关的缺陷来评估工具。(5)可复现性，缺陷数据应具有持久的可复现性：应以支持持久构建和行为复现的方式保存缺陷数据。

一些人工汇总的数据集(如西门子测试集、SIR 存储库、Defects4J)提供了软件制品集合，以支持程序分析和测试技术的受控实验。但是这些数据是人工分析策划的，而且在规模和多样性上都非常有限；而另外一些小型的学生作业，可能无法反映真实的技术表现。其中一些存储库通常通过手动植入缺陷来生成故障，而来自现实程序员的程序错误会提供更加真实的表现。但是除非通过持续不断且昂贵的人工劳动来保持数据集的扩增，否则难以保证实时性。最后如果它们依赖于特定版本的库和操作系统，则它们之后的可复现性无法保证。

上述讨论的数据集极大地促进了软件工程的研究进展，在数据的收集、分析和处理方面具有一系列的创新。但是，我们认为规模更大，多样性，真实性，实时性和持久性更高的数据集将带来更大的进步。在不牺牲实验效力的情况下控制协变量将帮助工具构建者和实证研究人员以更高的洞察力，外部有效性和时间稳定性获得结果。但是在无需大量人工劳动的情况下，构建更大的缺陷数据集；查找特定的缺陷；并创建可复现的和可运行的失败和成功软件版本是很困难的。因为除了分析源代码，还可能需要收集特定版本的库，依赖项，操作系统，编译器和其他工具，这个过程需要较高程度的人工介入。除非以某种方式使这种手动工作自动化，否则我们将无法建立可复现的大规模，多样化，真实的以及实时的数据集。

我们认为基于云的持续集成(Continuous Integration，CI)中 DevOps 和 OSS 主导的创新是解决上述问题的关键。CI 服务(如 TRAVIS-CI)允许将开源项目中的集成测试外包。由于各种原因，OSS 项目则需要进行连续的自动化集成测试。此外如测试驱动开发之类的现代实践方法导致了自动化测试的大量增加。项目的每项更改都可以在基于云的服务上进行集中且自动的异地测试。这可以跨语言，依赖关系和运行时平台连续进行。例如，典型的 GitHub 项目要求在审核或合并之前，对每个拉取请求(PR)进行集成测试，并修复缺陷。在进行中的项目中，PR 贡献者和项目维护者之间的来回协作会在拉取请求历史记录和整个项目历史记录中创建许多失败成功对记录。

完成此功能需要两项关键的技术：高效的、可自定义的基于容器的虚拟化简化了对复杂依赖性的处理，而脚本化 CI 服务器允许自动化的构建和测试过程。项目维护者创建脚本来定义其项目的测试环境(平台，依赖项等)；基于云的 CI 服务可以使用这些脚本构建虚拟化的运行时(通常是 Docker 容器)以构建和运行测试。之后对 CI 结果进行存档以便后期挖掘和分析。我们正是利用这些 CI 数据和技术创建一个自动化的，持续增长的，大规模的，多样化的，真实且持久的可复现缺陷数据集。

本文我们介绍了 CI 收集工具 BUGSWARM，以及一个持续增长的可复现的大型缺陷数据集。该工具使实时更新性和增加多样性成为可能。BUGSWARM 利用已归档的 CI 日志记录来创建详细的工件，包括错误代码版本，失败的回归测试集和缺陷修复操作。当找到一对连续的提交时，第一个提交中 CI 日志显示运行失败，第二个提交则通过运行，则 BUGSWARM 使用项目的 CI 定制脚本创建制品：完全容器化的虚拟环境，包括版本和脚本，以收集所有必需的工具、依赖项、平台和操作系统等。BUGSWARM 构件允许完整构建和测试成对的失败/通过运行。容器化可以持久地复现这些制品。使用 CI 服务的相关项目的规模和多样性使 BUGSWARM 也可以捕获大规模的、持续增长的、多样化且最新的制品。

具体地，我们的贡献如下：

(1)我们提出一种利用 CI 的方法，该方法可以挖掘开源项目中失败成功对并尝试在 DOCKER 容器中自动重现这些对。

(2)我们展示了这些失败-成功对在开源项目中是常见的，并且讨论了复现这些失败-成功对的挑战性。

(3)我们提供了 BUGSWARM 数据集，它为 Java 和 Python 提供了 3091 个制品，据我们所知它是最大的，连续扩增的，可持久复现的缺陷数据集。

4. 背景与动机

带有 CI 服务的现代 OSS 开发提供了一个支持工具和数据支持的生态系统，可以支持 BUGSWARM 的创建。本节我们描述了这个生态系统的相关组成部分，并给出了一个示例。

4.1 开源 CI 生态系统

(1)Git 和 GitHub。Git 对现代软件开发至关重要。每个项目都有一个存储库，其每次更改均通过提交进行，每个提交均具有一个通过具有 SHA-1 哈希派生的唯一标识符。项目历史记录是一系列提交。Git 支持分支，主要的开发则通常维护在一个称为 master 的分支中。GitHub 是托管 Git 存储库的基于 Web 的服务。

(2)Travis-CI 持续集成。Travis-CI 是与 Github 集成的、最流行的、基于云的托管 CI 服务。它可以通过自动构建和自动测试自行管理提交。用户可以通过项目存储中.travis.yml 文件来配置 Travis，并指定测试项目的所有环境。

(3)Docker。Docker 是一种轻量级虚拟机服务，可提供应用程序隔离、不变性和自定义。用户可以将应用程序与代码、运行时、系统工具、库和 OS 打包成一个不变的、独立的、定制的、持久的 Docker 映像，并在任何支持的平台上随时随地运行 Docker。2014 年底，Travis-CI 开始在 Docker 容器内运行构建和测试，每次运行都通过 Travis-CI 中的.travis.yml 文件进行自定义。

图 1 BUGSWARM 生命周期

4.2 挖掘与复现

我们利用 TRAVIS-CI 创建 BUGSWARM。图 1 描述了 TRAVIS-CI 构建和测试 PR 的生命周期。一个贡献者复制该存储库并进行了三个提交，直到 prV1；然后贡献者打开 PR，要求将所做的更改合并到原始存储库中。PR 的创建会触发 TRAVIS-CI，同时在打开 PR(prV1 和 baseV1)时检查 PR 分支和主分支之间是否存在合并冲突。如果没有，则 TRAVIS-CI 会从基础分支创建一个临时分支，PR 分支合并到该分支中以产生 temp1。TRAVIS-CI 然后从.travis.yml 文件生成构建脚本并启动构建，即运行脚本进行编译，构建和测试项目。

在我们的示例中，测试失败会导致第一个构建失败。TRAVIS-CI 则通知贡献者和项目维护者，如图 1 中的虚线箭头所示。贡献者进行了修复，并使用新的提交更新 PR。同样 TRAVIS-CI 在 PR 分支(prV2)和基础分支(于 baseV1)之间创建合并，以生成 temp2。构建再次失败，显然修复失败。因此贡献者通过添加新的提交 prV3 来更新 PR。触发 ATRAVISCI 构建，其中将测试 PR 分支(prV3)和基础分支(baseV2)之间的合并(temp3)。最终构建通过，PR 被接受并合并到基础分支中。

5 方法介绍

5.1 术语

项目的构建历史记录是指先前触发的所有 TRAVIS-CI 构建。一个构建可能包含许多工作；例如 Python 项目的构建可能包含单独的作业，并使用 2.6、2.7、3.0 等版本进行测试。

提交对是一个二元组的 GIT 提交 SHA，每个 SHA 在相同的构建历史中触发了 TRAVIS-CI 构建。规范的提交对包括一个无法通过测试的提交，以及一个通过测试的修订提交。术语构建和作业对分别是指来自项目构建历史的一个二元组的 TRAVIS-CI 构建或作业。对于给定的构建，触发器提交是提交到远程存储库后导致 TRAVIS-CI 开始构建的提交。

BUGSWARM 具有四个组件：PAIRMINER、PAIRFILTER、REPRODUCER 和 ANALYZER。这些组件形成管理 BUGSWARM 制品的管道，并且相对独立和一般性。本节描述了每个组件的职责和实现，以及一组有助于使用数据集的支持工具。

5.2 设计挑战

在用户试图连续自动地挖掘 TRAVIS-CI 时过程中会出现一些挑战，该工具基础架构旨在处理以这些的某些特定挑战。我们将对每种情况均列出实际解决挑战的工具。

(1)提交恢复：现构建需要找到触发时的提交；(2)镜像恢复：原则上 TRAVIS-CI 会创建并保留 DOCKER 图像，以此重新创建构建和测试事件；(3)运行时恢复：构建特定的项目版本通常需要满足对工具、库和框架的大量软件依赖；(4)日志分析：一旦运行对被恢复完成，BUGSWARM 就会尝试从日志中确定缺陷的确切性质，这些日志的结构不完善，每种语言、构建系统和测试工具集组合的格式也不同。

5.3 挖掘失败成功对

PAIRMINER 从项目的 GIT 中提取并建立历史记录，以获取一组失败成功作业对(如算法 1 所示)。PAIRMINER 将 GITHUB 块作为输入，并为每个作业的父版本生成一组故障传递作业对，并用触发提交信息进行注释。PAIRMINER 算法涉及(1)将项目的构建历史线性化；(2)提取失败成功构建对；(3)将提交分配给每个对；(4)从每个失败成功构建对中提取作业对。

算法 1 PAIRMINER 算法

5.4 查询复现信息

PAIRMINER 鉴定的相关对必须组装到可复制容器中。对于管道中的每个作业，PAIRFILTER 都会检查是否可以获取这些必需信息。如果 PAIRMINER 认为项目状态可恢复，则 PAIRFILTER 会检索作业的原始 TRAVISCI 日志并提取有关执行环境信息。PAIRFILTER 使用日志中的时间戳和实例名称，以确定作业是否在 DOCKER 容器中执行。

5.5 复现失败成功对

REPRODUCER 首先需要检查每个工作是否可以持久复现，这需要以下几个步骤。(1)生成工作脚本，travis-build 从.travis.yml 文件生成 Shell 脚本，以运行 TRAVIS-CI 作业；(2)匹配环境，为了匹配原始作业的运行时环境，REPRODUCER 从 TRAVIS-CI 公开可用的 DOCKER 图像集中进行选择；(3)还原项目，对于项目历史记录还原，REPRODUCER 提交克隆项目并重置其状态；(4)复现工作，REPRODUCER 创建一个新的 DOCKER 映像，运行生成的作业脚本，并将生成的输出流保存在日志文件中。

5****.6** **结果分析****

ANALYZER 解析 TRAVIS-CI 构建日志以了解构建状态以及回归测试用例集的运行结果。如果测试失败，则 ANALYZER 还将检索其名称。而构建日志的格式随特定的构建系统和测试框架而有很大不同；因此解析器必须与每个构建和测试框架对应。对于 Java，我们支持最流行的构建系统 Maven、Gradle 和 Ant 以及测试框架 JUnit 和 TestNG。对于 Python，我们支持最受欢迎的测试框架 unittest、unittest2、nose 和 pytest。

7 总结与展望

本文介绍了 BUGSWARM，一种利用 CI 来挖掘和复现实际开发中真实的失败-成功对方法。同时我们描述了一些具有意义的未来工作方向，以进一步完善数据集。我们希望 BUGSWARM 将尽可能地减少复现错误时的重复工作，并为评估软件工具和进行大规模软件研究提供新的研究机会。

致谢

本文由南京大学软件学院 2020 级博士张犬俊翻译转述。