在之前的博客文章中，我们讨论了如何分解测试挑战的一个方面，即以设计实验的形式处理多个输入，我们可以从一次关注一个输入开始。后来的一篇博客文章重新讨论了设计实验中因子效应的基本原理。现在，我们将结合这些想法，讨论在设计用于测试的实验时我们可能需要什么。
让我们回到 Beta 分布并考虑是否要测试改变 Beta 分布的输入，重点关注 q、alpha 和 beta。
假设我们为每个输入选择三个值（低/中/高）。我们可以想象尝试所有 27 个（3x3x3）可能的组合。但如果我们有 10 个输入，这会起作用吗？20 个？100 个？在某个时候，我们显然需要一种不同的策略。虽然我们有办法在典型的实验设计问题中处理这个问题，但这种方法是否适用于软件测试？回想一下，我们想要找到错误，它们潜伏在角落和边界中，让我们重新定义这一点，说我们的目标是找到会导致失败的输入组合（即，我们没有观察到预期的结果）。
那么边界又如何呢？
您可能已经注意到我似乎忽略了边界。这正是 OFAT 方法的价值所在。理想情况下，在测试进行到这个阶段之前，我们已经检查了每个输入的边界（并修复了所有问题）。不过，正如我们稍后会发现的，我们可以在改变输入时考虑边界。
超越 OFAT
在因子设计中，因子效应的基本原理与重要/显著效应有关。然而，对于软件测试，我们根据“导致故障的组合”重新定义基本原理：
组合层次： i）涉及较少输入的组合比涉及更多输入的组合更容易导致失败。ii）相同顺序的组合同样可能重要。
组合稀疏性：导致故障的组合数量将会很少。
组合遗传：如果已知涉及相互作用的父因素中至少一个更有可能导致失败，则该组合更有可能导致失败。
我们为什么需要做出区分？
测试的一个关键区别是，我们的响应只是通过/失败——我们是否偏离了预期结果？此外，我们通常假设一个确定性结果。也就是说，如果我们使用相同的输入，我们会得到相同的结果（没有错误）。虽然测试人员希望找到错误，但最终我们希望这些错误得到修复。我们并不希望拟合模型、发现效果或优化响应。事实上，与建模概念最接近的类比是追踪导致故障的组合的任务。这被称为故障定位问题，它有自己独特的挑战。
那么，这些原则对于测试来说有意义吗？
事实证明，有经验证据表明组合层次结构成立（参见 Kuhn 等人，2004 年）。另一方面，组合稀疏性可能并不总是一个合理的假设。如果系统没有经过任何类型的交互测试，甚至没有经过单个输入的测试，则测试套件中可能会出现许多失败（尤其是在开始修复错误之前）。这也与组合遗传原理有关——如果单个输入导致失败，那么涉及该输入的任何组合都会导致失败。
那么，如果这些假设合理，那么如何才能进行良好的测试呢？请继续关注我们的下一篇博客文章。
Kuhn, DR, Wallace, DR 和 Gallo, AM, 2004。软件故障相互作用及其对软件测试的影响。IEEE 软件工程学报, 三十(6)，第418-421页。
