测试选择技术，提供大量测试用例

#1 楼

您在这里有几个选择。实现和效果会有所不同，但是IME都是可行的解决方案。


覆盖范围-运行测试更改后的代码的测试。如果在给定的版本上两次运行相同的测试套件，您应该得到相同的结果（否则，我们应该讨论一些不同的东西）。
一种减少测试套件的技术size仅用于运行更改代码的
测试。您可以使用代码
覆盖率（跟踪哪些测试命中代码行）来获得超准确的结果，但是即使
特征区域中的某些元数据也可以帮助您使用类似的代码。
随机抽样-从整个产品中随机选择一组测试，或者更好的是，从每个功能区域中随机选择一组测试。我进行了多次实验（并鼓励您自己进行
），这些实验表明构成
测试套件的10％至15％的随机抽样可以很好地预测整个测试套件的通过
率。如果某个特定区域的合格率低于预期，
您可以选择在该区域中运行更多的测试。
您可以对始终通过
的测试（特别是通过测试）施加较小的负权重结合以上＃1）。给定一个测试，该测试以前已经发现了错误，而另一个测试却从未发现产品问题，所以我很可能会选择之前已经发现问题的测试。

/>还有其他（测试年龄，产品中已知错误的区域等），但是以上三个是我用于测试选择的主要启发式方法。

#2 楼

如果满足以下假设，则可能要尝试选择满足成对条件的一组测试用例：


可以用一组描述您要测试的行为独立参数，每个参数都有一组您想尝试的值。
您可以根据这些参数来描述每个测试用例，例如参数1 = X，参数3 = Y. ，参数2的值，...，参数N的值）。如果参数很多，并且每个参数都有几个可能的值，则测试用例的总数（元组的总数）可能会很大。

成对标准基于大多数错误的想法产生于单个参数值或一对参数的特定值之间的相互作用。这是标准：选择测试，以便每对可能的值至少练习一次。要了解更多信息，请在此论坛上搜索“组合测试”（我们应该为此做一个标签），或者在Google上搜索“成对测试”。

如果假设＃2为真，则可以选择以下测试满足成对标准。

#3 楼

D.W.，

背景评论

由于渴望回答您提出的问题，我进入了软件测试行业。从那时起，我一直在研究方法（a）创建数量相对较少的功能最强大的软件测试集，以及（b）测量此类测试集的实际有效性。这是我热衷的话题。 （我正在写这篇文章时，我必须是热情的，或者是发狂的，或者两者都是，因为目前是凌晨5:45。） ，“如果我无法测试所有内容，我应该测试什么？如何在尽可能少的测试中学习尽可能多的东西？”基于实验设计的测试设计方法广泛应用于农业，市场营销，制造业和许多其他行业。这些用于选择高效测试子集的基于实验设计的方法绝对适用于软件测试领域，但不到5％的软件测试人员使用它们来选择测试。

我一直在申请软件测试领域的实验设计技术已经发展了6年左右。许多论文和经验报告，包括我与3位博士在IEEE Computer中共同发表的一篇论文，都表明这些选择相对较少数量的软件测试的方法效果很好。这些技术（其中大部分是在user246对此问题的解答中提到的）包括：


逐对测试
组合测试
正交阵列测试/ OATS

针对特定问题的建议解决方案

假设您正在测试一个系统，该系统具有成千上万种可能的测试，您可以考虑执行这些测试，而时间限制不是问题。
场景1：
您没有以下任何信息：


更改了哪些代码（例如，您想测试整个系统，仅此而已）从头开始构建并有待测试），
在以前的运行中定期通过了哪些测试（因为在这种情况下，按照定义，以前没有运行过测试）

在这种情况下，我强烈建议您使用基于实验设计的组合选择测试的方法。 （免责声明：在测量基于实验设计的测试用例选择方法的有效性之后，我创建了测试用例生成工具Hexawise，因此我很可能被指责有偏见。）

从成对选择开始测试，并在执行这些测试时，从系统中进一步了解它，它是如何工作的，它的弱点在哪里等等，并且您会想到其他测试想法，然后通过以下方式编辑这些测试：（a）添加新测试输入和（b）调整测试输入上的权重以将注意力更多地集中在问题区域上，并且（c）时间允许，将生成的测试的覆盖强度提高到3种方式（三个测试输入的所有可能组合将在至少要有一个测试用例）或更高的覆盖强度（如果要自动执行测试）。

您会发现这种选择测试用例的方法是： br />比手工选择的测试用例集效率更高，这是因为（a）基于实验的设计测试将大大减少一次又一次地重复测试组合的意外重复，并且（b）基于实验设计的测试的覆盖范围将大大减少（例如，双模式故障（AKA成对缺陷）为100％）

场景2：
您正在测试相同的被测系统（理论上可以考虑进行万亿次可能的测试），但是这次您确实掌握了信息关于：


哪些代码刚刚更改（例如，您想测试整个系统，并且全​​部是从头开始构建的，尚待测试），
哪些测试有定期通过并在以前的运行中失败

在这种情况下，我鼓励您：

从基于实验设计的方法开始，选择刚才提到的测试，并且正如艾伦（Alan）所建议的那样，还更改代码：
将测试套件中的测试包括在内，以彻底测试最近更改的代码。为此，您可以指示测试生成工具播种/包含您在基于实验设计的测试中生成的特定测试。
在先前的运行中比其他测试失败次数多的测试：考虑播种这些测试在生成的一组测试中也是如此。

这些方法将为您提供：


在尽可能少的测试中实现最大覆盖*（两种情况） >最少的重复浪费（两种情况）
另外重点放在高优先级区域（仅在情况2下-例如，代码已更改且已知故障点位于的地方

*值得指出的是，当您使用这种方法选择测试时，可以选择适合您的通透性目标和时间限制的覆盖强度，例如，如果您急于进行，则可以生成数十个2向测试（AKA成对测试或全成对测试）或数千次6路测试，如果您想获得非凡的彻底性或几胡ndred 4路测试。或介于两者之间的任何数量的测试。

#4 楼

如果您确实必须使用子集，请使用过去最有效地捕获错误的测试用例。处于危险之中（要么是因为它们已更改最多，要么是因为与故障相关的成本更高）。 >

#5 楼

我认为是詹姆斯·巴赫（James Bach）证明了（嗯，更多“解释”）为什么成对和随机测试会随着随机测试数量的增加而收敛。
选择测试数量的经验法则是-


找到具有最大单个值数量的两个变量
将那些单个值的数量乘以
再乘以一个常数（2是一个很好的选择：- ））
结果是测试次数

在此处查看James的文章

此处的播客有更多详细信息

数学解释，生日悖论

#6 楼

MS的这篇文章有用吗？

#7 楼

在阅读测试文献时，我发现了一些有关“最小化测试集大小”的研究论文。他们讨论了如何使用块覆盖率来最小化测试集。

这是工作原理。给定大量的测试用例T，他们将查找与T具有相同块覆盖率的测试用例的子集S（即，T中某个测试用例覆盖的每个块也将在S中被某个测试用例覆盖） ）。这是一个集合覆盖问题。

我发现了一篇论文，对这种测试集最小化做了一个实验，他们发现基于覆盖的最小化非常有效：它只减少了一点点。测试设备在检测故障方面的有效性，同时大大减小了测试设备的尺寸。这是参考：


测试集大小最小化和故障检测有效性：在空间应用中的案例研究。 W. Eric Wong，Joseph R. Horgan，Aditya P. Mathur和Alberto Pasquini。计算机软件和应用程序会议（COMPSAC）1997。

侧边栏：这是我从那篇论文中删除的一个有趣的细节。他们讨论了使用覆盖率进行最小化的一种混合方法，而不是直接使用集线覆盖来最小化测试集。

有两个阶段。在阶段1中，他们依次评估每个测试集。如果测试t覆盖了先前测试之前未覆盖的某个新块，则保留t。另一方面，如果t不覆盖任何新块，则丢弃t。然后，将在阶段1中保留的测试用例集用作阶段2的输入。在阶段2中，我们对集合覆盖问题应用算法，以找到具有相同总覆盖率的那些测试用例的最小子集。由于已经大大减少了阶段2的输入，因此可以将昂贵的算法应用于布景保护。

为什么不将套封面应用到整个测试用例集并跳过阶段1？据推测，他们担心在最坏的情况下机盖问题是指数级的。通过减小阶段1中测试池的大小，他们可以应用更昂贵的set-cover算法来查找确切的最小解决方案，而不是近似的解决方案。


但是，后来的一篇论文报道了一些注意事项。他们发现，基于覆盖率的测试集最小化的实用程序因程序而异。对于某些程序，基于覆盖率的最小化可以显着减少测试用例的数量，而不会显着影响测试集检测故障的有效性。但是，对于某些其他程序，基于覆盖率的最小化会带来副作用，即大大降低测试集的有效性。他们得出的结论是，基于覆盖范围的最小化的好处尚不清楚，并且很难预测，并且这一领域没有人们所希望的那样被很好地理解。这是参考文献：测试套件简化的经验研究。 Gregg Rothermel，Mary Jean Harrold，Jeffery von Ronne和Christie Hong。软件测试，验证和可靠性。 2002年12月，第12卷，第4期，第219--249页。