[论文解读]Coverage Is Not Strongly Correlated with Test Suite Effectiveness-CSDN博客

本文链接：https://blog.csdn.net/qq_33935895/article/details/107228181

Coverage Is Not Strongly Correlated with Test Suite Effectiveness

简介

论文标题

Coverage Is Not Strongly Correlated with Test Suite Effectiveness
覆盖率与测试套件的有效性没有很强的相关性
2014

摘要

测试套件的覆盖率通常被用作其检测故障能力的代理。然而，以前研究代码覆盖率和测试套件有效性之间的相关性的研究未能就这些测试套件特征之间的关系的性质和强度达成共识。此外，许多研究都是在小程序或合成程序中完成的，这使得他们的结果是否适用于较大的程序尚不清楚，而且一些研究没有考虑到测试集大小的混杂影响。此外，大多数研究都是在合适的测试套件下完成的，这在实践中是很少见的，因此结果可能不会推广到典型的测试套件

我们通过评估大型Java程序的测试套件大小、覆盖率和有效性之间的关系来扩展这些研究。我们的研究是迄今为止文献中规模最大的：我们为五个系统生成了31,000个测试套件，包括多达724,000行源代码。我们测量了这些套件的语句覆盖率、决策覆盖率和修改条件覆盖率，并使用突变测试来评估它们的故障检测效果。

我们发现，当控制套件中的测试用例数量时，复盖率和有效性之间存在低到中等的相关性。此外，我们发现，更强的覆盖形式并不能更深入地了解套件的有效性。我们的结果表明，覆盖率虽然对识别程序中测试不足的部分很有用，但不应该用作质量目标，因为它不是测试套件有效性的良好指示器。

介绍

测试是生产高质量软件的重要部分，但其有效性取决于测试套件的质量：一些套件比其他套件更善于检测故障。自然，开发人员希望他们的测试套件能够很好地暴露故障，这就需要一种测量测试套件故障检测有效性的方法。测试教科书通常建议将覆盖率作为可用于此目的的度量之一(例如，[29，34])。这在直觉上很吸引人，因为很明显，测试套件无法在它从不执行的代码中找到错误；这也得到了发现代码覆盖率和错误检测效率之间关系的研究的支持[3，6，14-17，24，31，39]。

不幸的是，这些研究没有就这些测试集特征之间的关系的强度达成一致。此外，这项研究的三个问题使得他们的结果很难概括。首先，一些研究没有控制套房的大小。由于通过向现有测试用例添加代码或向套件添加新测试用例来增加覆盖率，因此测试套件的覆盖率与其大小相关。因此，复盖率是否独立于套件中的测试用例数量与有效性相关尚不清楚。其次，除了一项研究之外，所有的研究都使用了小型或合成的程序，这使得他们的结果是否适用于工业中典型的大型程序尚不清楚。第三，许多研究只比较了合适的套间；也就是说，完全满足特定覆盖标准的套间。由于实践中很少有足够的测试套件，这些研究的结果可能不会推广到更实际的测试套件。

本文对测试集规模、覆盖率和有效性之间的关系进行了新的研究。我们回答了以下针对大型Java程序的研究问题：

研究问题1。测试套件的有效性是否与套件中的测试用例数量相关？

研究问题2.当忽略测试套件中的测试用例数量时，测试套件的有效性是否与其语句覆盖率、决策覆盖率和/或修改后的条件覆盖率相关？

研究问题3.当测试套件中的测试用例数量保持不变时，测试套件的有效性是否与其语句覆盖率、决策覆盖率和/或修改条件覆盖率相关？

本文主要做了以下几个方面的工作：

对以前调查覆盖率和有效性之间关系的研究进行的全面调查(第2节和附带的在线材料)。
经验证据表明，当控制套房规模时，覆盖率和有效性之间存在低到中等的相关性，并且所使用的覆盖率类型对关系的强度影响不大(第4节)。
讨论这些结果对开发人员、研究人员和标准团体的影响(第5节)。

方法论

为了回答我们的研究问题，我们遵循了第2节中概述的一般程序。这要求我们选择：

一套目标程序(第3.2节)；
生成程序故障版本的方法(第3.3节)；
创建测试套件的方法(第3.4节)
覆盖指标(第3.5节)
有效性度量(第3.6节)

然后，我们测量了套件的覆盖率和有效性，以评估这些特征之间的关系。

术语

在详细描述该方法之前，我们精确定义了将在整篇文章中使用的三个术语

测试用例：测试套件中的一个测试。测试用例作为一个单元执行；它要么被执行，要么不被执行。在JUnit测试框架中，每个以单词test(JUnit3)开头或以@Test(JUnit4)注释的方法都是一个测试用例。因此，我们将交替使用术语“测试方法”和“测试用例”。
测试套件：一组测试用例
主套件：由主题程序的开发人员编写的整个测试套件。例如，Apache POI的主套件包含1,415个测试用例(测试方法)。我们创建和评估的测试套件是主套件的严格子集。

目标程序

我们从不同的应用领域选择了五个主题。第一个是Apache POI[4]，它是一个用于操作Microsoft文档的开源API。第二个是Closure Compiler[7]，它是一个开源的JavaScript优化编译器。第三个，HSQLDB[23]，是一个开源的关系数据库管理系统。第四个是JFreeChart[25]，它是一个用于生成图表的开源库。第五个是Joda Time[26]，它是Java Date和Time类的开源替代品。

我们使用了许多标准来选择这些项目。首先，为了帮助确保我们研究的新颖性和概括性，我们要求项目相当大(大约100,000 SLOC)，用Java编写，并积极开发。我们还要求项目具有相当多的测试方法(大约1,000个)，以便我们能够生成大小合理的随机测试套件。最后，我们要求项目使用Ant作为构建系统，使用JUnit作为测试工具，从而允许我们自动化数据收集。

表2总结了我们程序的显著特征。程序大小是用SLOCCount[38]测量的。第7行到第10行提供了与突变测试相关的信息，将在第3.3节中进行说明。

生成错误程序

我们使用开源工具PIT[35]来生成程序的错误版本。要描述PIT的运作，我们必须先对突变检测做一个简要的描述

变体是通过对原始程序进行微小的语法更改而创建的程序的新版本。例如，可以通过修改常量、否定分支条件或删除方法调用来创建突变体。得到的突变体可能会产生与原始程序相同的输出，在这种情况下，它被称为等效突变体。例如，如果图1中的代码片段中的相等性测试被更改为if(index>=10)，那么新程序将是一个等价的突变体。

像PIT这样的突变测试工具会生成大量的突变，并在每个突变上运行程序的测试套件。如果测试套件在给定的突变体上运行时失败，我们就说该套件杀死了该突变体。那么，测试套件的突变复盖率就是它杀死的非等价突变的分数。等同的突变体被排除在外，因为根据定义，它们不能被单元测试检测到。

如果突变体没有被测试套件杀死，则需要手动检查以确定它是等价的，还是只是被测试套件遗漏了4。这是一个耗时且容易出错的过程，因此将测试套件的子集与主套件进行比较的研究通常使用不同的方法：它们假设主套件无法检测到的任何突变都是等价的。虽然这项技术往往高估了等效突变体的数量，但它通常被应用，因为它允许研究更大的程序。

尽管PIT生成的突变体模拟真实故障，但套件杀死突变体的能力不是检测真实故障能力的有效衡量标准，这一点并不是不言而喻的。然而，一些先前和当前的研究支持使用这种测量方法[2，3，10，27]。以前的工作还表明，如果测试套件检测到由单一不正确的源代码行引起的大量简单故障，那么它将检测大量较难的、多行故障[28，32]。这意味着，如果一个测试套件可以杀死很大比例的变种，那么它也可以检测到软件中较难的故障中的很大比例。因此，文献表明，套的突变检测率是对其故障检测能力的相当好的度量。我们将在第6节和第7节回到这个问题上。

现在我们可以描述表2的其余行了。第七行显示了每个项目生成了多少个突变PIT。第八行显示了该套件可以检测到多少突变体。第九行显示了有多少突变体不能被整个测试套件检测到，因此被认为是等价的(即，第7行是第8行和第9行的总和)。最后一行给出了相当的突变体占总数的百分比。

生成测试套件

对于每个主题程序，我们使用Java的反射API来标识该程序的主套件中的所有测试方法。然后，我们通过在没有替换的情况下随机选择这些方法的子集来生成固定大小的新测试套件。更具体地说，我们通过重复使用TestSuite.addTest(Test T)方法创建了一个JUnit套件。每个套件都创建为一个JUnit套件，以便为每个测试方法运行必要的设置和拆卸代码。给定这个创建套件的过程，在本文中，我们的随机套件的大小应该始终理解为它们包含的测试方法的数量，即调用addTest的次数。

我们制作了1000个套件，每个套件的大小如下：3个方法，10个方法，30个方法，100个方法等等，直到遵循这个模式的最大数量少于测试方法的总数。这导致了五个学科系统总共有31,000个测试套件。比较来自同一项目的大量套件允许我们控制大小；它还允许我们将结果应用于常见的研究实践，即使用不同的测试生成方法比较为同一主题程序生成的测试套件。

测量覆盖范围

我们使用开源工具CodeCover[8]来测量三种类型的覆盖率：语句、决策和修改后的条件覆盖率。

语句覆盖率指的是程序中由测试套件运行的可执行语句的部分。它相对容易满足，易于理解，并且可以快速测量，因此受到开发人员的欢迎。但是，它是覆盖率较弱的形式之一，因为执行一行并不一定会显示该行中的错误

决策覆盖率指的是程序中由其测试套件执行的决策(即分支)的比例。决策覆盖率比语句覆盖率更难满足和度量。

修改条件覆盖(MCC)是这三种方法中最难满足的。对于要被修改的条件足够(即具有100%修改的条件覆盖)的测试套件，该测试套件必须针对其中具有n个条件5的每个决策包括2n个测试用例[22]。这种覆盖形式在实践中并不常用；但是，它与航空电子行业中广泛使用的修改条件/决策覆盖(MC/DC)非常相似。具体地说，美国联邦航空管理局标准DO-178B规定，飞机中最关键的软件必须使用修改后的条件/决策覆盖范围足够的套件进行测试[22]。因此，MC/DC是实践中广泛和定期使用的最严格的覆盖形式之一。通过测量修改后的条件复盖率，可以深入了解更强的复盖率类型(如MCC和MC/DC)是否提供了比编写足够多的测试来满足它们所带来的额外成本更大的实际好处。

我们没有测量任何类型的数据流覆盖率，因为很少有Java工具可以测量这些类型的覆盖率。一个例外是Coverlipse[9]，它可以测量所有用途的覆盖率，但只能用作Eclipse插件。据我们所知，目前还没有针对Java的开源覆盖工具可以测量其他数据流覆盖标准，也没有可以从命令行使用的工具。因为开发人员使用他们拥有的工具，所以他们不太可能使用数据流覆盖指标。使用开发人员使用的度量标准，无论是出于工具可用性还是法律要求，都意味着我们的结果将更准确地反映当前的开发实践。然而，我们计划在未来的工作中探索数据流覆盖，以确定开发人员是否会从使用这些覆盖类型中受益。

衡量有效性

在本研究中，我们使用了两种有效性度量：原始有效性度量和归一化有效性度量。原始kill score是测试套件检测到的突变体的数量除以为被测试的主题程序生成的不等价突变体的总数。归一化有效性度量是测试套件检测到的突变数量除以它覆盖的非等价突变的数量。如果突变体是通过更改测试套件执行的一行代码来生成的，则测试套件将覆盖该突变体，这意味着测试套件可能会检测到该突变体。

我们包括标准化的有效性度量，以便在更公平的基础上比较测试套件。假设我们将覆盖50%的套件A与覆盖60%的套件B进行比较。套件B几乎肯定会有更高的原始有效性度量，因为它覆盖了更多的代码，因此几乎肯定会杀死更多的变种。然而，如果套件A杀死了它覆盖的突变体的80%，而套件B只杀死了它覆盖的突变体的70%，那么在某种意义上，套件A是一个更好的套件。归一化有效性度量捕捉到了这一差异。请注意，如果测试用例覆盖了大量代码，但杀死的变种很少，那么当将新的测试用例添加到套件中时，归一化有效性度量可能会下降

将标准化的有效性度量视为深度度量可能会有所帮助：测试套件对其运行的代码的执行有多彻底？原始效率度量是广度的度量：套件执行了多少代码？

请注意，套件覆盖的非等价突变体的数量是套件可能检测到的最大突变体数量，因此归一化有效性度量的范围从0到1。通常，原始有效性度量不会达到1，因为大多数套件会杀死一小部分不等价的突变体。然而，请注意，完整的测试套件的归一化有效性度量为1，原始有效性度量为1，因为我们确定它没有杀死的任何突变体都是等价的。

结果

在这一部分中，我们定量地回答了第一节中提出的三个研究问题。如第三节所述，我们通过随机抽样生成固定大小的测试用例集，使用CodeCover测量它们的语句、决策和MCC覆盖率，并使用突变测试工具PIT来测量它们的有效性，从而收集数据来回答这些问题

规模是否与有效性相关

研究问题1询问测试套件的有效性是否受其包含的测试方法数量的影响。此研究问题提供了支持有效性度量使用的“健全性检查”。图2显示了我们为回答这个问题而收集的一些数据。在每个子图中，x轴表示对数刻度上的套件大小，而y轴表示我们计算的归一化效率值的范围。使用R的lm函数将每个图上的红线与数据拟合。每条回归线的调整r2值显示在每个绘图的右下角。这些值的范围在0.26到0.97之间，意味着相关系数r在0.51到0.98之间。这表明，这些项目的归一化效力和规模之间存在中等到非常高的相关性7。非归一化效能测量的结果类似，r2值在0.69到0.99之间，这意味着非归一化效力与大小之间存在很高的相关性。这个尺寸的数字可以在在线上找到。

http://linozemtseva.com/research/2014/icse/coverage/

答案1.我们的结果表明，对于大型Java程序，测试套件的有效性和它包含的测试方法的数量之间存在中等到非常高的相关性。

当忽略规模时，覆盖率是否与有效性相关？

研究问题2询问当我们忽略套件大小的影响时，测试套件的有效性是否与套件的覆盖率相关。表3和表4显示了我们为回答这个问题而计算的肯德尔τ相关系数；所有系数在99.9%的水平上都是显著的。表3给出了不同覆盖类型与归一化有效性度量之间的相关性。表4给出了不同覆盖类型和非归一化有效性度量之间的相关性。对于除HSQLDB之外的所有项目，当不考虑规模时，我们看到覆盖率和有效性之间存在中等到非常高的相关性。HSQLDB是一个有趣的例外：当有效性度量按覆盖的突变体数量归一化时，覆盖率和有效性之间的负相关性很低。这意味着具有较高覆盖率的套件在每单位覆盖范围内杀死的变种较少；换句话说，具有较高覆盖率的套件包含运行大量代码但不会杀死该代码中的许多变种的测试用例。当然，由于随着突变体的生长，这些套件总共杀死了更多的突变体，因此HSQLDB的覆盖率和非标准化有效性之间存在正相关。

答案2.我们的结果表明，对于许多大型Java程序，当忽略测试套大小的影响时，测试套的有效性与覆盖率之间存在中等到高度的相关性。研究问题3探讨这种相关性是否由覆盖范围较高的套间尺寸较大引起。

当规模固定时，覆盖率是否与有效性相关？

研究问题3询问当测试套件中的测试用例数量受到控制时，测试套件的有效性是否与其覆盖率相关。图3显示了我们为回答这个问题而收集的数据。每个面板都显示了我们针对一个项目和一个套件大小获得的结果。项目名称位于每列的顶部，而套件大小位于每行的右侧。不同的覆盖类型按颜色区分。最下面的一行是显示所有大小结果的边距图，而最右边的一列是显示所有项目结果的边距图。该图显示了归一化有效性度量的结果；在这种大小下，非归一化有效性度量往往很小，很难看到。非归一化有效性测量的数字可以在网上与其他补充材料一起找到

我们计算了每个项目、每个套件大小、每个覆盖类型以及两种有效性度量的有效性和覆盖率之间的Kendall τ相关系数。由于这导致了大量的数据，我们在这里总结结果；完整的数据集可以在与图表相同的网站上找到。

我们的结果好坏参半。对套间大小的控制总是会降低覆盖率和有效性之间的相关性。然而，变化的大小取决于所使用的有效性衡量标准。一般说来，一旦控制了规模，归一化有效性度量与覆盖率的相关性较低，而一旦控制了规模，非归一化有效性度量与覆盖率的相关性是中等的。

也就是说，结果因项目而异。Joda时间是一个极端：当忽略套件大小时，覆盖率和有效性之间的相关性在0.80到0.85之间，但当控制套件大小时，覆盖和有效性之间的相关性降至基本上为零。当使用归一化有效性测量时，闭合也有同样的效果。

Apache POI跌到了另一个极端。在这个项目中，当忽略套间大小时，覆盖范围与非归一化有效性度量之间的相关性为0.94，但当控制套间大小时，覆盖与非归一化有效性度量之间的相关性降至0.46至0.85之间。虽然在某些情况下这是一个很大的降幅，但是这个范围内的相关性可以提供关于测试套件质量的有用信息。

一个非常有趣的结果是，一般来说，使用的覆盖类型对结果没有很大影响。即使每个套件的有效性分数(y值)对于所有三种覆盖类型(x值)都是相同的，情况也是如此。为了阐明这一点，请看图4。该图显示了针对覆盖率的有效性的两个假设图。在上图中，覆盖类型1与有效性没有很强的关联。在底图中，即使每个点的y值没有改变(例如，两个图中的三角形都在y=0.8)，覆盖类型2也与有效性强相关。我们看不到语句、决策和MCC覆盖之间的这种差异，这表明不同类型的覆盖衡量的是同一件事。我们可以通过测量每个套件的不同覆盖类型之间的相关性来证实这一直觉(表5)。考虑到这些高度的相关性，并且考虑到所有三种覆盖测量的点云形状相似(参见图3)，我们可以得出结论，在本研究中，所使用的覆盖类型对覆盖与有效性之间的关系影响不大。

回答3.我们的结果表明，对于大型Java程序，当控制套件大小时，覆盖率和有效性之间的相关性会下降。在这种下降之后，相关性通常在低到中等的范围内，这意味着假设有效性与覆盖相关通常是不安全的。当使用非归一化有效性度量时，相关性更强。此外，所使用的覆盖类型对关系的强度几乎没有影响。

讨论

这项工作的目标是确定当控制测试套件的大小时，测试套件的覆盖率是否与其故障检测有效性相关。我们发现，当忽略套件大小时，覆盖率和有效性之间通常存在中到高的相关性，而当控制大小时，这种相关性下降到低到中等的相关性。这一结果表明，覆盖本身并不能很好地预测测试套件的有效性；在许多情况下，这种明显的关系很大程度上是由于高覆盖套件包含更多测试用例这一事实。特别是Joda Time和Closed的结果表明，假设覆盖范围与有效性相关通常是不安全的。有趣的是，Joda Time和Closed的套件是我们研究的五个套件中最大和最全面的，这可能表明随着套件的改进，相关性会变得更弱。

此外，我们发现，测量的覆盖类型对覆盖和有效性之间的相关性影响不大。图3中点云的形状加强了这一点：对于任何一个项目和套件大小，对应于三种覆盖类型的云在形状和大小上都是相似的。这一点，再加上不同覆盖率度量之间的高度相关性，表明较强的覆盖率类型提供的关于套件质量的额外信息很少。

我们的发现对开发人员、研究人员和标准团体具有重要意义。开发人员可能希望使用此信息来指导其覆盖范围的使用。虽然覆盖率测量对于识别程序中测试不足的部分很有用，并且低覆盖率可能指示测试套件不足，但是高覆盖率并不表明测试套件是有效的。这意味着使用固定的覆盖率值作为质量目标不太可能产生有效的测试套件。虽然测试社区的成员以前已经提出了这一点[13，30]，但由于缺乏考虑我们调查的规模系统的研究，因此很难评估他们的建议。此外，使用更简单的覆盖措施可能最符合开发人员的利益。这些测量提供了关于套件有效性的类似数量的信息，但引入的测量开销较少。

研究人员可能希望使用这些信息来指导他们的工具构建。特别是，测试生成技术经常试图最大化结果套件的覆盖率；我们的结果表明这可能不是最好的方法。

最后，我们的结果与设定软件测试要求的标准团体相关。本文前面提到的FAA标准DO-178B要求使用MC/DC适当的套件来确保结果软件的质量；然而，我们的结果表明，这一要求可能会增加费用，但不一定会提高质量

当然，开发人员仍然希望测量他们的测试套件的质量，这意味着他们需要一个确实与故障检测能力相关的度量标准。虽然这仍然是一个悬而未决的问题，但我们目前认为突变评分可能是这一背景下覆盖范围的一个很好的替代品[27]。

对有效性的威胁

在这一部分中，我们讨论了对本研究的结构效度、内部效度和外部效度的威胁。

结构有效性

在我们的研究中，我们测量了随机测试套件的大小、覆盖率和有效性。规模和覆盖率很容易衡量，但有效性则比较模糊，因为我们试图预测一个从未在实践中使用过的套件的故障检测能力。正如我们在第3.3节中所描述的，以前和当前的工作表明，套件杀死突变体的能力是检测真正故障的能力的相当好的度量[2，3，10，27]。这表明，在没有等效突变体的情况下，该度量具有很高的结构效度。不幸的是，我们对等价突变体的处理给这一测量的有效性带来了威胁。回想一下，我们假设程序的整个测试套件无法检测到的任何突变都是等价的。这意味着我们将高达35%的生成突变体归类为等价的(参见表2的最后一行)。从理论上讲，这些突变体是整个突变体集合中的一个随机子集，所以忽略它们不应该影响我们的结果。然而，这可能不是真的。例如，如果开发人员频繁测试Off-by-One错误，则会更频繁地检测到模拟此错误的突变体，并且不太可能将其归类为等价的。

内部有效性

我们关于规模、覆盖率和有效性之间关系的结论依赖于我们对肯德尔τ相关系数的计算。这给研究的内部有效性带来了威胁。肯德尔最初的τ公式假定数据中没有绑定的等级；也就是说，如果数据经过排序，则在不破坏排序顺序的情况下，不能交换任何两行。当关系确实存在时，就会出现两个问题。首先，由于原来的公式不处理领带，所以必须使用修改后的公式。我们使用了Adler提出的版本[1]。其次，联系使得计算相关系数的统计显著性变得困难。可以证明，在没有联系的情况下，τ是正态分布的，这意味着我们可以用通常的方式使用Z分数来评估重要性。然而，当存在联系时，τ的分布会发生变化，这取决于联系的数量和性质。这可能导致非正态分布[18]。为了确定平局对我们计算的影响，我们计算了发生的平局数和计算每个τ时执行的比较总数。我们发现平局很少发生：对于最糟糕的计算，4.6%的比较结果是平局，但对于大多数计算来说，这个百分比要小几个数量级。由于纽带如此之少，我们假设它们对正态分布的影响可以忽略不计。

内部有效性的另一个威胁来自重复测试套件的可能性：如果两个或更多套件包含相同的测试方法子集，我们的结果可能会出现偏差。幸运的是，我们可以使用我们收集的关于平局的信息来评估这一威胁：由于重复的套件自然具有相同的覆盖范围和有效性分数，因此平局比较的数量为比较了多少相同的套件提供了上限。由于平局的数量如此之少，重复套间的数量也一定同样低，因此我们忽略了他们可能引入的小偏差，以避免不必要地增加我们研究的内存需求。

既然我们已经研究了相关性，我们就不能对因果关系的方向做出任何断言。

外部有效性

我们研究的外部有效性面临六个主要威胁。首先，以前的工作表明，程序的大小、覆盖率和有效性之间的关系取决于检测程序中错误的难度[3]。此外，以前的一些工作是用手工播种的故障完成的，这已经被证明比突变体和真正的故障都更难检测[2]。虽然这不会影响我们的结果，但它确实使我们更难将它们与早期研究的结果进行比较

其次，以前的一些研究发现，直到达到非常高的覆盖水平才出现覆盖和有效性之间的关系[14，17，24]。由于我们生成的套件的覆盖率很少达到非常高的值，因此我们可能错过了这种关系的存在。也就是说，目前还不清楚这种关系在实践中是否有用。要达到极高的覆盖率是非常困难的，所以在达到90%的覆盖率之前没有出现的关系在功能上等同于对大多数开发人员来说根本没有关系。

第三，在面向对象的系统中，大多数故障通常只在系统的几个组件中发现[12]。这意味着规模、覆盖范围和有效性之间的关系可能会因系统内的不同类别而不同。因此，覆盖率可能与具有特定特征(如高流失率)的班级的有效性相关。然而，我们的结论仍然适用于度量程序整个测试套件的覆盖率的常见实践。

第四，程序或套件的其他功能可能会影响覆盖范围和有效性之间的关系。例如，以前的工作表明，类的大小会影响面向对象度量的有效性[11]。虽然我们在这项研究中控制了每个测试套件的大小，但我们没有控制每个测试方法所来自的类的大小。

第五，正如第3.2节所讨论的，我们的主题必须满足特定的纳入标准。这意味着它们相当相似，因此我们的结果可能不会推广到不符合这些标准的程序。我们试图通过从不同的应用领域选择程序来缓解这种威胁，从而确保主题具有一定的多样性。不幸的是，很难找到可接受的主题；尤其是，主题有1000个测试用例的要求被证明很难满足。实际上，似乎大多数开放源码项目都没有全面的测试套件。这得到了Gopinath等人的研究[20]的支持，在他们最初考虑的1254个开源Java项目中，只有729个(58%)拥有测试套件，远没有那么全面

最后，虽然我们的研究对象比以前研究中使用的程序要大得多，但从行业标准来看，它们仍然不算大。此外，所有的项目都是开源的，所以我们的结果可能不会推广到封闭源代码系统。