编译：TesterHome
原文标题：3 Ways To Get Higher ROI From Your Test Plan
作者：NickD，解决方案架构师

以下为作者观点：

现在是年末，一系列假期来临，世界各地的工程师们都在尽最大努力在假期开始前不做任何危险的工作。现在我们比以往任何时候都有更重要的事情要担心，而不是失败的部署。这篇文章将给你三个简单的想法，可以帮助提高你的测试覆盖率，并增加你的测试套件的投资回报率，并尽可能减少你的工作量。

什么算作是测试套件的良好 ROI？

在我们开始讨论测试策略之前，当我们说一个测试套件 (Test Suite) 应该有 ROI时，这里我认为一般来说，与你节省的 QA 团队和工程师的时间相比，你在制作和维护测试上投入的工作越少，你的测试套件的 ROI 就越好。考虑到这一点，这里有 3 个增加你的测试套件的 ROI 的想法。

不要担心 100% 的覆盖率

当你从头开始写一个测试套件时，很容易陷入一个循环，即确定你的应用程序的行为的一个部分，然后向下挖掘，直到你覆盖了该行为的每个方面。当然，然后对你的应用程序的每一个其他部分重复这个过程，直到你还没有完成一半，就有数以百计的 "用例 "需要检查。

这也是许多人放弃测试的原因，或者许多组织认为他们没有资源来处理这个问题。

然而，当你开始测试你的应用程序时，比覆盖所有东西更重要的是覆盖” 哪些”。即使在拥有一流的测试文化的组织中，获得 100%（有用）的覆盖率也是闻所未闻的。

与其担心你没有覆盖所有的东西，不如专注于自动化，哪怕只是几个小任务，也会更有成效。理想情况下，你应该首先关注那些任务。

• 最耗时的检查
• 最容易测试的
• 如果发生故障，会造成最大的麻烦

这可能会导致你的测试看起来很 "小"，没有涵盖你的应用程序的一些更复杂的方面，但这些测试仍然可以大大改善你的整体 QA 效率。例如，如果你的应用程序或网站包含多种语言的服务条款，那么检查这个区域是否可以被用户访问，可能是你手动测试程序的一个重要部分。然而，即使这个动作本身很简单，对你的 QA 团队来说还是很耗费时间。

更不用说，即使你要测试的用户动作很难自动化，它可能仍然需要 QA 团队花费和那些容易自动化的事情一样的时间。如果你能把所有简单的测试都自动化，那么你的 QA 团队将有更多的时间来仔细检查你的应用程序的更复杂的部分。

如果不能实现自动化，那就记录它

如果你没有自动化你的所有测试案例，你应该正确记录所需的步骤和剩下的手动测试的预期结果。这是使你的 QA 周期尽可能有效的另一个好方法，并增加你的测试套件的 ROI。

人们很容易犯错误，忘记事情，或者跳过步骤。特别是在发布之前，这些问题往往会变得更加复杂。通过让你的 QA 团队更清楚地了解需要测试什么，以及预期的结果是什么，你可以减少额外的工作，这些工作来自于回过头来修复在最后一轮 QA 中漏掉的错误。

记录你的用例也有另外两个直接的好处。首先，它将鼓励你以一种非常有条理的方式来思考对你的应用程序的期望是什么。通过这样做，你可能会发现，有一些用例，你以前认为很难测试，但实际上是很简单的。

其次，你记录的手动测试可以作为以后转换为自动测试的一个很好的指南。即使你不能立即将手动测试转换为自动测试场景，自动测试的工具也在一天天变得更加聪明。特别是随着 ML(Machine Learning) 在测试应用中变得越来越普遍，越来越多的你记录的手动测试可以成为自动化的放手测试。

即使你根本没有自动化任何东西，只是把你的手动测试计划记录下来，也是简化你的 QA 过程和减少每次发布前的混乱的好方法。

减少手工编码

开发人员对保持最新的 E2E（端到端）测试套件最常见的抱怨之一是，测试的规模很快就会失去控制。执行 E2E 测试所需的代码往往会超过应用程序本身的代码。

用代码编写 E2E 测试需要大量的工作。即使是设置初始场景，不仅需要你的工程团队花费大量的时间，特别是在较大的团队中，还会有非常高的沟通成本。此外，用代码编写的 E2E 测试很容易被破坏。你的用户界面的一个小变化有可能导致工程人员花费数小时的时间来更新代码，以便 "修复 "测试。

对于那些有更严格的工作流程来发布新工作的大型组织来说，在 "问题 "被修复之前，所损失的时间可能会在多个领域累积起来。在最坏的情况下，你的用户界面的一个小变化可能会在组织的其他地方增加十几个小时的损失。

这个问题在很大程度上可以通过使用无代码或低代码的测试工具来解决，这些工具允许你通过浏览你的应用程序和执行像你的用户一样的操作来直观地定义你的测试。在大多数情况下，测试方案可以在不使用任何工程资源的情况下建立和运行。

此外，如果你使用这些工具，机器学习算法已经到位，可以检查小的变化并自动修复你的测试。因此，你的用户界面的一个小更新可能会给你的团队带来意想不到的工作，可能对你的测试根本没有任何影响。如果你的应用程序的变化确实破坏了一个测试，更新场景可以由没有工程经验的团队成员完成。