为什么好的测试设计是不可避免的?

许多书籍、博客文章等表明，要么您花费大量金钱和时间进行测试以达到高质量，要么您节省了资金，但您的软件质量仍然很差。这不是真的。现实情况是，团队可以修改软件开发生命周期 (SDLC) 中的两个重要成本要素：测试和错误修复。它们都不是线性的。

当我们想要发现更多错误时，测试成本就会增加。一开始，增加或多或少是线性的，即执行两倍的测试用例意味着检测到的错误数量将增加一倍。但是，通过添加更多测试用例，成本变得非线性。原因是到了一定层次后，我们需要通过组合的方法对输入域的元素进行组合(和测试)。例如，我们首先测试一些分区，然后是它们的边界，然后是边界值的对或三元组等。假设项目中测试用例的数量不可忽略。没有理由设计和执行过多的测试，因为即使进行了许多额外的测试，我们也无法找到大量的错误。

另一个因素是缺陷纠正(错误修复)的成本。我们越晚在软件生命周期中发现错误，纠正它的成本就越高。根据一些出版物，校正成本是“时间指数”，但明显超过线性，很可能显示多项式增长。因此，如果我们能够在生命周期中及早发现故障，那么总的纠正成本可以大大降低。如下所示，综合考虑这两个因素，总成本具有最佳值。(图非真实，仅演示概念)

这意味着降低测试和测试成本并不是一个好的策略，因为您应该同时考虑这两个因素。主要问题是——这种成本优化是否会产生可接受的生产代码质量?这不是一个简单的问题。假设您应用了低效的测试设计。在这种情况下，由于测试成本很高，未检测到的错误数量仍然很高，即使达到最佳状态，软件质量也可能无法接受。相反，如果您应用非常有效的测试设计技术，最优值将被移动到检测到的错误率更高的点，从而导致可接受的质量，见下图：

因此，需要一种有效的测试设计技术来降低 SDLC 成本并同时使代码质量变得可以接受。然而，不同的功能需要不同级别的测试设计。让我们考虑两个实现的功能，并假设第一个的代码更复杂(在某些方面)。因此，它包含更高概率的故障。如果我们以相同的成本和彻底性进行测试，那么在测试之后，更多的错误将留在第一个代码中。这意味着总的校正成本会更高。

我们可以使用类似的论据来考虑风险。假设我们有两个功能具有相同的复杂性和测试成本(故障分布相似)，但第一个风险更大。例如，此功能使用得更频繁，或者该功能在“关键”流程中使用。因此，在此功能中将检测和修复更多的错误，并且在生命周期中具有更高的纠正成本。请注意，我们在这里谈论的是对错误的检测，而不是关于错误的存在。

粗略地说，如果测试工作/成本保持不变，更复杂的代码和更高的风险会增加修复错误的成本。由于这种额外的错误修复发生在生命周期的后期，因此发布时的代码质量会更差。因此，风险更大或更复杂的特征必须以更彻底的方式进行测试，即以更高的测试成本。这种较高的测试成本对于实现最优总成本是不可避免的，见下图，其中 HRF 是高风险函数，LRF 是低风险函数。

对于传统的风险分析，有两个因素，影响和概率。在这里，我们可以将复杂性视为第三个因素。

通过将风险大小映射到特征，我们可以使测试设计接近最优。对于风险更高的代码，我们应该选择更强的测试设计技术。一个好的选择是使用具有不同测试选择标准的相同测试设计技术。例如，如果您使用状态转换测试或动作状态测试设计技术，您可以选择最小测试选择标准、低风险特征的全转换测试，或者风险较高的特征更强的全转换对标准。如有必要，您可以使用更严格的标准。

让我们假设您确实为风险更高的功能选择了更强大的测试设计技术，但是您如何检查您是否接近最佳状态?这不是一件容易的事。唯一的方法是尽可能多地收集数据。例如：让我们分别衡量您对功能的测试工作量。首先应用一个更简单的标准，然后扩展它并衡量这两项努力。然后测量检测到的错误的错误修复成本。最后，衡量发布后检测到的错误的错误修复成本。现在，您可以通过近似更简单标准的错误修复成本(对于更强标准检测到的错误)来计算应用较弱和更强标准的测试和修复成本的总和。最后，考虑风险。如果更简单标准的总成本较低，那么您可以为该风险值选择此标准。

哪些测试应该自动化?

没有人自动化所有的测试用例。一些特性不是很重要，或者改变功能的可能性接近于零(假设这个特性在静态分析意义上独立于其他特性)。相对于单个手动测试执行而言，测试自动化成本很高。自动化这些功能是否合理?当然不是。也可能有些功能只会更改一次或两次。如果测试自动化的成本是单个手动测试的五倍，那么自动化就毫无价值。

另一方面，如果一个错误会阻碍软件的使用，或者该功能会被多次修改或受到许多频繁更改的功能的影响，那么毫无疑问，测试自动化是必须的。

同样，我们可以进行风险分析。如果影响非常高或很高，那么即使不会发生任何变化，我们也应该自动化测试。原因是即使一个特征保持不变，其他一些特征也可能会影响它。如果这些“影响者”功能正在改变，未修改的可能会出错。问题是如何计算风险。显然，影响是一个关键因素。概率是另一个需要考虑的因素。然而，我们应该考虑另一种类型的概率，即变化的概率，而不是复杂性。

因此，风险分析只进行一次，所有四个风险项(影响、概率、复杂性和变更概率)都应由团队确定。您可以使用著名的风险扑克。根据风险，您可以决定要自动化哪些功能。如果您想以不同的强度进行回归测试，风险分析也会有所帮助。例如，您可以在每次代码修改后执行一些风险较高的功能测试，而每周只执行一次风险较低的其他功能测试。

最后一步是验证以改进流程。在这里您可以验证功能的自动化是否合理。您知道在自动化测试执行期间检测到的错误，与这些错误相关的错误修复成本，您测量了测试自动化成本，并且您拥有关于发布后检测到的错误的平均错误修复成本的历史数据。根据这些数据，您可以计算自动化是否合理。如果没有，您可以微调基于风险的策略。

测试应该如何自动化?

出色的!我们有一个很好的测试设计，我们知道要自动化什么。唯一要做的就是测试自动化本身。乍一看，测试很容易自动化。测试用例由用户操作和系统响应组成。在这两种情况下，您都应该识别被测 UI 对象。对于任何测试自动化框架，解决方案都是类似的。对于操作，您使用选择器/定位器和关键字。以下是使用赛普拉斯的示例：

这里#add Coke选择添加可乐的'+'按钮，click()是点击这个按钮的关键字。对于验证，解决方案非常相似：

您可以非常快速地编写测试代码，但是，存在一个重大问题：DRY，即不要重复自己。DRY“是旨在减少软件模式重复的软件开发原则”。由于可能更多的测试用例包含单击添加可乐按钮，因此将重复相同的语句。在维护期间，如果测试发生变化，您应该在多个位置进行更改。

为避免这种情况，建议使用页面对象模型 (POM)。页面对象模型是一种设计模式，其中页面对象与自动化测试脚本分离。您应该为应用程序中的每个页面创建单独的类。然后为每个动作和响应创建单独的方法，并且分离选择器。例如，这里是添加可乐的 POM 版本：

现在，如果要修改选择器或操作代码，您可以在一个位置进行。很好，我们完成了。糟糕，有一个问题：POM 代码比原来的要大很多。选择器的变量声明，动作/响应的方法以及对该方法的调用，而不是单个语句。粗略地说，我们将代码大小增加了两倍以保持 DRY。然而，

1、某些操作/响应永远不会被修改。

2、一些动作/响应在一个测试用例中并且只有一次。

在这种情况下，修改只发生在一个位置。您可能会认为“没问题，让我们再次使用风险分析”。不幸的是，在这里我们应该分别分析每个动作/响应，这是非常昂贵的。现在可以做什么?幸运的是，有一个很好的解决方案：基于模型的测试!

基于模型的测试 (MBT) 是一种固有地涉及 DRY 解决方案的技术。MBT 的本质是，我们不是一个一个地手动创建测试用例，而是创建一个适当的测试模型，MBT 工具可以从中根据适当的测试选择标准生成测试用例。该模型可以是文本的或图形的。模型基于测试设计技术。例如，状态图是进行状态转换测试的表示。下面是著名的 ATM 认证的状态图：

满足全转移对准则，“插入有效卡”动作涉及 3 次。在模型中，这个动作只发生一次。这意味着这个动作只执行一次，如果有任何修改，你应该在一个位置修改它。模型显然比模型所代表的对象更紧凑。我的经验告诉我，文本模型由三分之一的最简单(非 POM)测试代码组成。因此，POM 版本大约是模型的 9 倍。在另一篇博客中，我将比较不同的 MBT 方法，但每种方法都比使用原始 POM 更好。

使用 MBT 的另一个优点是测试设计和测试执行自动化结合在一起。我们非正式地证明了先进的测试设计是必须的。做一个单独的测试设计，然后一个一个地编写测试完全是多余的。制作模型然后生成测试是一种快速有效的解决方案。维护也很高效，因为您从不接触代码，只接触模型。每次模型修改后都会生成测试代码。

这意味着同时使用 MBT 和测试执行框架是提高软件质量和降低 SDLC 成本的最佳方法。

结论

关于软件测试有很多误解。在这里，我展示了使用有效的测试设计不仅可以提高质量，还可以降低 SDLC 总成本。我试图回答哪些测试用例应该自动化的问题。最后，我展示了使用 MBT 可以提高测试自动化工作的效率。不要丢弃您的测试自动化框架，而是使用测试设计自动化工具对其进行扩展。在另一个博客中，我将展示如何做到这一点。

卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的软件测试报告。点击→→可了解测试报价

部分文字、图片来自网络，如涉及侵权，请及时与我们联系，我们会在第一时间删除或处理侵权内容。负责人：曾菲       电话：4006070568