开云APP·官方入口(kaiyun)(中国)官方网站IOS/Android/手机app下载

摘要测试和调试是软件开发生命周期中最昂贵也最容易堕落的阶段。自动化软件测试以及软件诊断技术可以大大提高测试和调试阶段的事情效率，从而提高软件的整体质量。在本文中，作者提供了一个可以举行自动测试和故障定位的工具集，称为 GZoltar。该工具集包罗了最小化（回归）测试套件和自动故障诊断（即基于频谱的缺陷定位）的相关技术，提供了能够对软件法式源代码举行自动插桩、并生成运行时数据的基础结构。

这些数据将在随后的事情阶段中被分析，主要用于最小化测试套件和返回诊断候选者的排名列表。为了利便全世界的使用者，该工具集被实现为一个可以即插即用的 Eclipse IDE 插件，关键词：Eclipse 插件；自动化测试；自动化调试；GZOLTAR；RZOLTAR1 测试与调试​ 测试和调试是软件开发生命周期中一个重要而又最昂贵且乏味的阶段。只管简化测试和调试任务的框架已经泛起，但这些框架往往不能提供足够的功效以支持测试和调试阶段的完全自动化。

广为人知的（单元）测试框架——如 JUnit，TestNG 和 JTest——虽然可以自动地执行测试，但并不能使用某些指标（例如笼罩率）最小化测试套件；现存的几种调试工具则多数在法式单步走查（例如，GDB 和 DDD）的基础上举行法式调试，而这些传统的手工缺陷定位技术往往存在着诸多限制。设置输出语句，并审核对应的输出，这些调试手段都属于非结构化的暂时性操作，通常需要依赖开发人员自身的直觉；此外，软件开发人员通常只关注那些能够袒露软件错误的测试用例，因而往往会忽略测试通过的测试用例反馈的有价值的信息。​ 近年来，科研人员在开发自动化测试或自动化缺陷定位技术和工具方面投入了大量精神，其主要目的为了大幅度降低测试和调试的成本。

就软件测试来说，几项相关的软件测试技术已经泛起。这些技术可以在保证原有代码笼罩率稳定的情况下，对已有的测试用例举行最小化或优先排序操作，以淘汰测试套件执行时间，同时提高错误检测效果。

本文提出了一个名为 GZoltar 的工具集，该工具集提供了一种可以缩减测试套件、确定测试优先级的技术。该技术接纳了一种基于约束的新颖方法，能够在保证代码笼罩率稳定的情况下实现原始测试套件最小化。

此外，该技术允许用户通过基数和盘算得出的测试执行时间来思量如何对测试套件举行优先排序或最小化。至于软件调试，基于黑盒统计的方法是现在最为主流的方法之一。该方法主要使用了待测法式和可用测试用例，通太过析测试用例的执行效果，返回待测法式中最有可能堕落的位置（组件），并进一步找出测试用例未通过的原因。

GZoltar 工具集实现了一种基于频谱的缺陷定位的技术 (SFL, Spectrum-based Fault Localization)。SFL 能够通过插桩技术来对法式中正在运行的部门举行追踪。工具集将分析插桩信息，并生成一个包罗源代码位置的列表。

该列表根据源代码中泛起问题的可能性巨细对代码行举行从高到低的排序。此外，GZoltar 工具集还可以设置法式的预期行为的方式来对法式举行训练，从而能够在工具视察到非预期行为时自动举行错误检测。由于不需要预先扫描法式以获取可能的错误位置，现存的软件测试工具和软件调试工具可以有效地将 GZoltar 工具集拓展到自身的事情流程中。2 GZOLTAR 工具套件GZoltar 是一个 Eclipse 插件，它使用最新的基于频谱的缺陷定位算法生成准确的缺陷定位信息，并提供回归测试领域的最新技术。

GZoltar 还可以建立可视化的交互式诊断陈诉，例如 Treemap 图和 Sunburst 图（如 2.3 节图 3 所示）。GZoltar 与 Eclipse（最受接待的 IDE 之一）的集成很是实用。GZoltar 使用 Eclipse 的尺度功效（例如 Eclipse 检测事情区中的项目结构的功效）来构建被测系统(SUT, System Under Test)的结构，以供可视化视图使用的。此外，GZoltar 还将良好的代码编辑器和尺度的 Eclipse 警告生成机制与可视化诊断陈诉集成在一起，大大简化了整个调试历程。

GZoltar 可以资助开发人员更快地发现故障，从而淘汰了测试和调试阶段所需时间和资源。这在提高了的软件的可靠性品级的同时可能缩短一定的软件测试周期，从而能够显著降低软件开发的成本。2.1 GZoltar 架构图 1：GZoltar 图层；GZoltar 与其他技术之间的集成关系。GZoltar 主要用 Java 编写，同时也使用了一些第三方开源法式。

在 GZoltar 架构体系中，Eclipse 的 Workspace 组件用于整合工具所需信息，例如打开项目并从项目目录下类和 JUnit 测试中搜集信息；ASM 是一个 Java 字节码工程库，用来扫描 SUT 以便 GZoltar 能够在项目使用 JUnit 执行单元测试时跟踪到测试笼罩率；Eclipse 的 Workbench 组件用于生成 Eclipse 用户界面（UI），包罗了用于建立 GZoltar 视图的尺度窗口部件工具集(SWT, Standard Widget Toolkit)，并提供了与抽象窗体工具集(AWT, Abstract Windows Toolkit)关联的桥梁；JOGL(Java OpenGL)则用于生成基于 OpenGL 的可视化信息，并展示在 GZoltar 视图中。​ 集成在 GZoltar 插件中的 MINION 约束求解器是由 C 编写的；同时 TRIE 结构也是由 C 语言实现，可是具备一个 Java 编写的接口。

这样做的是为了提高组件的事情效率。关于这些技术层的组织条理及相互作用关系请参见图 1。2.2 Gzoltar 事情流GZoltar 事情流程可以分为八个主要阶段（参见图 2）：图 2：信息流​ Eclipse 的初始化集成：Eclipse 资助 GZoltar 检测 IDE 中所有打开的项目。一旦在 IDE 中打开项目，GZoltar 就会扫描项目，并为其所有类和 JUnit 测试类（具有用 JUnit 语法编写的测试方法的类，这些类会在后面的阶段执行）建设索引。

为了制止源文件和编译发生的字节码存在差异，GZoltar 这时会强制 Eclipse 再次对打开的项目举行构建，以确保字节码文件与当前源文件语义一致。​ JUnit 和 ASM：每个项目有一个记载了所有测试类的列表。对于项目中的每个类，工具将对类的代码举行插桩以利便代码笼罩流程。

该历程的主要目的是要判断类中某一行代码是否已被执行。GZoltar 使用 ASM 对所有打开的项目举行插桩，从而能够通过调试得知有哪些项目挪用了其他项目的方法。随后，工具将自动执行以 JUnit 语法实现的测试类。

​ 测试用例的执行情况也将被工具生存下来，以供 RZoltar（显示测试是否失败的视图）和 GZoltar（盘算并显示诊断陈诉的视图）使用。测试用例的执行效果将生存到一个二维笼罩矩阵(Coverage Martrix)中。

假设笼罩矩阵 A 是一个 N×M 的二维矩阵，那么 N 代表的就是测试用例的执行个数，M 则对应（被测）软件法式中的若干组件，那么 aij 则表现组件 j 在执行测试用例 i 时的笼罩率。笼罩矩阵收集完毕后，RZoltar 会对矩阵举行分析，以举行测试套件的最小化。

​ 关于 SUT 中每个测试用例代码笼罩信息的搜集历程分为以下三步：（1）插桩代码，用于记载执行测试用例时到达的语句（2）执行测试并（3）盘算笼罩轨迹（即哪些语句在本次测试中被执行到了），并将笼罩轨迹添加到笼罩矩阵中去。​ 总的来说，在本阶段工具将对 IDE 中打开的所有项目举行插桩和构建；项目中的所有测试类也将被执行；笼罩矩阵（以及其他相关信息）将会被存储以服务之后的事情。MINION：将 SUT 的笼罩信息收集到之前提到的笼罩矩阵之后，工具将会把笼罩信息通报给约束求解器，并最终返回至少一个——能够像原始测试集一样——笼罩整个软件法式的最小测试集。

筛选解决方案：使用 TRIE 数据结构，约束求解提供的效果会在这个阶段获得筛选。此阶段本质上是将获取的非最小测试荟萃从效果集中剔除。

​ 显示解决方案：在此阶段，用户可以选择一个约简后的测试集并重新执行测试；也可以通过基数和执行时间对所有测试子集举行排序。​ 运行 Ochiai：在此阶段，GZoltar 执行 SFL 算法 Ochiai（该算法被认为是性能最好的缺陷定位技术之一）举行缺陷定位。基于所有 JUnit 测试效果，GZoltar 将为系统的每个元素盘算 Ochiai 相似系数。

​ 图形可视化：为了执行 SUT 的可视化清晰而有效，GZoltar 使用 OpenGL 技术以更好地使用图形处置惩罚单元（GPU）。​ 警告生成和 Eclipse 收尾集成：GZoltar 插件还将生成警告信息，以见告用户哪些代码行存在潜在的错误。GZoltar 将警告生成器与代码编辑器集成在一起，从而可以直接标志可能泛起错误的代码行。

​ 在履历以上所有阶段之后，用户可以对运行失败的单元测试和以及堕落的代码行（如果存在的话）举行审查。由于 GZoltar 事情流程是一个递归历程，因此在未解决所有故障之前，用户都可以从运行效果中选取最小测试集并重新举行测试（这样可以节约测试时间），并在修复部门错误并再次重复相同的操作。

2.3 Eclipse 视图默认情况下，GZoltar 提供了两个集成到 Eclipse IDE 中的视图：GZoltar（图 3）和 RZoltar（图 4）。图 3：GZoltar 的可视化效果：Treemap 和 Sunburst图 4：RZoltar 界面在分析 SUT 时，用户只需单击 GZoltar 视图上的可视化代码行，便可直接跳转到 Eclipse 代码编辑器中该行对应的位置。此外，GZoltar 还会在代码编辑器的垂直标尺上生成标志列表。

当鼠标在标志上悬停时，界面会显示出对应的堕落概率。凭据颜色差别，这些标志分为三种类型：（1）红色代表该语句包罗错误的概率排在前三；（2）黄色代表错误概率排在中间的三条语句；（3）绿色代表概率最小的第三条语句。此外，每个标志还内置了 ColorADD2 符号，可以资助色瞽者员区分标志。

这些注释标志也会显示在 Eclipse“问题”视图中。GZoltar 视图还提供了 Treemap 和 Sunburst 两种可视化形式，如图 3 所示。通过这种无缝集成，用户可以轻松分析 SUT 结构，并快速定位软件错误的源头。

GZoltar 提供了一种可以使开发人员直接会见源代码并修复错误的轻便技术。RZoltar 视图（图 4）分为两层。在左侧视图中，用户可以看到 RZoltar 提供的最小笼罩规模列表（这个列表也包罗原生测试套件，思量到用户可能需要重新执行所有测试）而且可以生茶测试用例的执行效果（通过，失败或错误）。

如果测试失败或返回错误，RZoltar 则会在右侧“跟踪”窗口中将错误消息显示出来。用户可以在任意图层中双击测试用例以跳转至对应测试用例文件，也可以在“跟踪”窗口处双击跟踪链以进入对应的行。这项功效有些类似于 JUnit 提供的功效。

RZoltar 视图给出了用于对测试举行优先排序的两个指标：基数和运行时间。后者根据再运行的时间由短到长对所有最小化测试荟萃举行排序；前者则通过测试集中包罗的测试用例个数举行从小到大排序。

致谢本文由南京大学软件学院 2020 级硕士生钱瑞祥翻译转述。谢谢国家重点研发计划（2018YFB1003900）和国家自然科学基金（61832009，61932012）支持！。

本文来源：开云app官网-www.dxdtc.com