软件测试大赛——观察与经验

一个项目即使在测试上投入大量资源，所生产的软件仍可能质量低下，关键因素不是测试花费了多少，而是测试的执行方式和执行者。如今，单元测试可用于有效地测试单个软件模块。我们举办了两次软件测试大赛（STC）;[STC 2016 和 STC 2017]，由 IEEE 可靠性学会和 MooctestLLC，赞助，是中国大学生软件测试大赛的一部分。除了教育目的之外，我们还收集了测试数据进行研究。我们将数据（除去私人信息后）存储在开源的存储库中。我们使用该存储库中的数据进行了两次实证研究。我们的发现将在以下各节中介绍。

测试大赛

STC 2016 和 STC 2017 均使用在线软件测试平台 Mooctest。每个参赛者都使用安装了 Mooctest 插件的 Eclipse IDE 连接到 Mooctest 服务器。大赛开始时，Mooctest 服务器将数个源程序部署到每个参赛者的 Eclipse IDE 中。部署完成后，参赛者开始进行测试，且平台计时器激活。在测试过程中，参赛者需要阅读和理解源程序的源代码。然后，编写 JUnit 测试用例，并提交给 Mooctest 服务器。服务器编译提交的测试用例，对照源程序执行它们，测量分支覆盖率，并计算变异分数。在这两个大赛中，都允许多次提交，每个参赛者的最终分数取决于他（她）的最后一次提交。计时结束则比赛结束，Mooctest 将不再接受新的提交。对于大赛组织者，Mooctest 提供了一个 Web 界面来管理和监视大赛，该大赛显示了所有参赛者的实时得分及其统计数据，例如平均值，中位数和标准差。

源程序

在为源程序生成测试用例之前，参赛者必须了解其规格和源代码。我们使用四个复杂度指标（代码行（LOC），分支数量（number of branches），平均方法复杂度（AMC）和平均块深度（ABD）。从 GitHub 和 SourceForge 中为 STC 选择了开源程序。这些程序在 LOC，分支数量，AMC 和 ABD 方面的复杂性与我们在南京大学软件测试课程中使用的程序类似。

表 1 列出了 STC 2016 和 STC 2017 中使用的源程序的四个复杂性指标的值。

评估标准

在 STC 2016 和 STC 2017 中，我们使用了行业中通常要求的分支覆盖标准来评估生成的测试用例的质量。我们还使用了突变评分（已在学术界广泛使用）来评估和排名参赛者。在变异测试中，变异是从原始程序派生的错误程序。当原始程序和变体在相同的测试用例中执行但行为不同时，它将被杀死。一旦完成了针对原始程序和突变体的测试执行，就将突变得分计算为杀死的突变体总数除以所有生成的突变体数目。

受之前的单元测试大赛的启发，我们将分支覆盖率和突变得分结合在一起，得出以下排名方程：

其中 P 代表一个源程序，coveragebranch 和 scoremutation 分别是指归档分支的 coverage 和突变分数，nump 是指每个大赛中源程序的总数，其中 α 和 β 是权重。

除了 STC 2016 的初赛（在排名方程中不包括突变得分）之外，我们的排名系统中均应用了分支覆盖率和突变得分，其中 α 和 β 为 0.5。

使用从大赛收集的数据进行的实证研究

软件测试大赛可以为我们的 区做出重要贡献，因为我们可以使软件测试及其技术更加完善。我们已经在http://www.iselab.cn/contest/data/上创建了一个数据存储库，即软件测试大赛数据存储库（STCDR）。使用STCDR的数据，我们进行了实证研究，回答了两个研究问题。

?分支测试的覆盖率与单元测试中的突变得分是否有很强的相关性？

?类级别的测试顺序是否会对单元测试的有效性产生影响？

1.分支测试的覆盖率与单元测试中的突变得分是否有很强的相关性？

研究 15-17 分析了分支覆盖率和突变得分之间的相关性。我们使用九个源程序的套件中的 846 个测试用例进行了分析。

图 1 显示了每个源程序的突变得分和分支覆盖范围的散点图，其中一条直线表示趋势。我们观察到在所有受试者程序中分支覆盖率和突变得分之间呈正相关。我们使用 SPSS 软件计算了 PC 系数，以测量每个受试者程序的分支覆盖率和突变得分的线性相关性。详细信息如表 2 所示。

前两列介绍源程序及其相应的 PC。在七个源程序中，我们观察到中等或强正相关（PC>0.40）19。在两个源程序（CMD 和 SuffixArray）中，相关性为正但微弱，与其他源程序不同。我们手动检查了这两个源程序以及参赛者生成的测试套件，并将它们与其他源程序进行了比较。我们发现 CMD 的所有分支都在 52 种方法中的 7 种中。换句话说，其余 45 种 CMD 方法没有任何分支。结果，突变得分和分支覆盖率之间的相关性被削弱，因为它们中的任何一个都可以独立地实现。这与我们的结果相符，如图 1（e）所示。关于 SuffixArray，我们发现竞争者很少杀死某些突变，这也削弱了相关性。由于我们在所有源程序中都使用了相同的变异运算符，因此这表明 SuffixArray 对于参赛者而言更加困难。为了确定观察到的相关性是否具有统计学显着性，我们应用了配对的 Wilcoxon 检验并进行了双尾备择假设。第三列显示有效值。所有测试的 p 值范围为 0.141 至 0.001。因此，我们可以接受另一种假设，即分支覆盖度与突变评分具有显着正相关，置信度至少为 0.859。

2.类级别的测试顺序是否会对单元测试的有效性产生影响？

类级别的测试顺序可以减少测试桩的数量并提高测试效率。这引起了一个有趣的问题，即测试顺序是否会对测试有效性产生影响。使用来自诸如 GitHub 之类的开放源代码存储库中的数据的挑战是，花费在测试生成上的时间可能会影响测试有效性。例如，给定由具有相似测试技能和领域知识的两个测试人员生成的两个测试套件，一个合理的假设是，花费更多时间生成的测试套件可能会达到更好的效果。由于我们不知道在测试生成上花费了多少时间，因此评估可能会产生偏差。使用我们比赛中的数据可以减少这种威胁，因为每个参赛者花在测试生成上的时间几乎是相同的。

在这两个大赛中，我们都观察到参赛者测试其源程序的方式有所不同。我们首先根据行业从业人员，学术界研究人员和一些参赛者的反馈确定了八种测试顺序。前两个测试顺序基于 Java 类的名称，按字母升序和降序（ALPHA ASC/ DESC）排列。在比赛中，每个参赛者使用的 Eclipse IDE 以字母顺序列出了源程序的类别。这可能导致参赛者以字母升序或降序测试类。第三和第四测试顺序是基于源程序（LOC ASC / DESC）的大小的升序和降序，LOC ASC / DESC 由 LOC 测量。这两个测试命令来自于检查策略-首先进行最简单或最困难的工作。其他四个测试顺序是基于统一建模语言（UML）类图的依赖关系（DEPEND）和关联关系（ASSN）的正向和反向确立的。

我们分四个步骤确定参赛者偏好的测试顺序。首先，对于一个源程序，我们针对每个测试顺序确定一组试点测试序列（PTS）。其次，对于每个参赛者，我们根据其方法调用的类序列来确定其在每个源程序上的 TS，其中每个类都是断言的参数。第三，我们将识别出的 TS 与八个 PTS 中的每一个进行比较。关于 ALPHA（ASC / DESC）和 LOC（ASC / DESC），如果 TS 是 TS 和 PTS 唯一元素之间的最长公共子序列，那么我们就确定使用一次 PTS 的相应测试顺序。关于 DEPEND（FWD/BWD）和 ASSN（FWD/BWD），我们获得反向 PTS（RPTS），其中包含 PTS 中每个元素的反向序列。如果 RPTS 中长度为 2 的任何子序列不在 RPTS 中，而在 PTS 中至少有一个，则我们确定使用一次相应的测试顺序。第四，如果参赛者平均使用多个测试命令，我们将随机选择一个作为他（她）的首选测试命令。

以一个名为 A，B，C 和 D 的四个类的程序为例，并以图 2 中所示的测试套件为例。在这种情况下，PTSALPHA（ASC）为（A，B，C，D），而测试套件的 TS 为（A，B，C）。请注意，由于 B 不是断言的参数，因此不认为 B 在第 5 行进行了测试。结果，我们确定使用一次字母升序，因为 TS 是 TS 和 PTSALPHA（ASC）的唯一元素之间的最长公共子序列。关于前向依赖关系测试顺序，假设 A 和 B 依赖于 C，而 D 没有依赖关系。在这种情况下，

?PTSDEPEND（FWD）是[（A，C），（B，C）]。

?RPTSDEPEND（FWD）为[（C，A），（C，B）]。

?TS 为（A，B，C）。TS 的长度为 2 的所有子序列均为[（A，B），

（A，C），（B，C）]。

结果，由于（A，C）和（B，C）在 PTSDEPEND（FWD）中，并且 TS 的长度 2 的子序列在 RPTSDEPEND（FWD）中，因此确定前向依赖性测试顺序被使用一次。

为了准确地衡量测试顺序，我们使用了来自 STC2017 初赛的参赛者的数据，他们仅编写了一个 JUnit 类并为每个源程序提供了一个测试功能。我们进行了 10 次分析以获得平均结果，以减少随机引入的偏差。结果示于表 3。

结果表明，尽管按类名的字母顺序（由 EclipseIDE 提供）是呈现给参赛者的第一顺序，但它并不是最受欢迎的测试顺序。将近 30％的参赛者在比赛中选择了著名的“首先回答最容易或最困难的问题”考试策略。大约 25％的参赛者根据他们的依赖关系测试了源程序，而前向依赖测试顺序更受欢迎。这表明，如果参赛者在测试某个类别（例如 A 类）时发现了一个参考的类别（例如 B 类），那么他们很可能会在 A 类之后进行 B 类别的测试。此外，其中有一小部分参赛者赞成基于关系的顺序。

使用 ALPHA（ASC）的参赛者的平均得分仅比使用 ALPHA（DESC）的参赛者的平均得分低 2.25。这符合我们的预期，因为我们认为使用按类名按字母升序或降序进行的测试不会产生重大影响。LOC（ASC）的平均得分比 LOC（DESC）的平均得分高 7.92。这表明先回答最简单的问题的策略比先回答最困难的问题的策略更有效。关于基于 UML 关系的测试顺序，前向测试顺序 DEPEND（FWD）和 ASSN（FWD）的平均得分几乎相同。这些前向测试顺序的平均得分分别比后向测试顺序的 DEPEND（BWD）和 ASSN（BWD）更高，分别为 7.13 和 18.0。这表明基于 UML 关系的两个测试顺序（依存关系和关联）同等有效，并且向前测试顺序要比向后测试顺序更有效。使用其他测试命令的参赛者获得了 37.94 分的最高平均得分。

观察和经验

通过举办软件测试大赛，我们可以提高学生的软件测试技能，还可以收集真实的测试数据以进行软件测试和工程研究。

已经提出了突变测试以基于突变得分来测量测试用例的故障检测强度。但是，由于变异测试执行成本高，因此可能不可行。我们使用 846 个手动创建的测试套件进行的分析表明，分支覆盖率和突变得分之间存在显着的中度至高度的正相关关系。这表明当突变测试不可行时，仍然可以使用分支覆盖率作为替代方法。

除了分支覆盖率和变异分数之间的相关性分析外，我们还分析了不同测试顺序的测试有效性及其受欢迎程度。从分析结果中得出了三个有趣的观察结果。首先，回答最简单的问题优先策略的表现要比回答最困难的问题优先策略的要好。其次，基于前向 UML 的测试顺序要比基于后向 UML 的测试顺序更好。第三，“其他”测试顺序的最高平均得分为 37.94，明显高于第二最高的平均得分 27.20。这种观察提出了一个问题，即是否存在我们未确定的特定测试顺序。在我们的实验设计中，我们根据行业从业人员，学术界研究人员和一些参赛者的反馈，分析了八个测试顺序。我们相信我们在分析中不会错过任何特定的测试顺序。如果是这样，则表明灵活的测试顺序可以达到良好的效果。尽管如此，我们将进行更多的实验以进一步研究该观察结果。

致谢