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 级博士张犬俊翻译转述。 |
