自动化测试并非总是最具性价比的测试方法

标签： 2026-10-20　

是否采用自动化测试，应比较开发与维护投入、手工执行成本和预期复用次数。

自动化测试的成本考量

为了符合投资回报的主题，我确实认为开发者忘记了一个事实，即自动化代码测试并不是测试功能或代码的专属方法。如果你正在开发一个基于网页的应用程序，有像Selenium和Cypress这样的工具。如果你正在测试移动应用程序或桌面应用程序，还有其他选择。通常这些工具不测量代码覆盖率。

还有传统的方法，这涉及到一个实际用户通过手动操作来验证功能或代码是否正常工作。考虑为一组特定功能编写自动化测试所需的时间与手动测试相同事情所需的时间。

例如，如果你能在四小时内编写自动化测试（4 X 60 = 240分钟），并且从头到尾手动测试相同功能需要20分钟，粗略估算一下，你可能会在该软件的第12次发布/部署后看到投资回报。

还有其他成本是我们故意不考虑的，例如手动执行测试的人的成本、人类与代码相比的潜在可靠性问题、在你的管道中运行这些测试的云成本。即使没有这些数值，也很容易通过规模经济来理解自动化测试在这种用例中提供了好处。根据功能和该应用程序的性质，通常会在多个地方对同一功能进行测试，例如自动化测试和手动测试。

自动化测试的局限性

有时某个特定功能很难生成自动化测试，即使考虑到规模，手动测试它可能花费更少的时间。我已忘记被分配的那些任务，编写测试的难度明显大于编写代码。同样的数学规则适用——想象一个需要16小时（两天）X 60分钟 = 960分钟努力编写的自动化测试。将其与手动测试同一功能进行比较，可能只需要五分钟。你需要192次部署才能从那个自动化测试中看到回报。

有很多次优代码存在于代码库中。你的自动化测试代码只能有多好。你的整个测试策略只有在所验证的功能有多重要。将代码覆盖工具添加到次优代码库中，希望它能神奇地提高你应用程序的质量，这是行不通的。这也可能会让你的开发团队更难改进代码。

如果我能传达任何信息，我希望传达的是，你的代码结构对代码覆盖数据的准确性有很强的相关性。这一观点仍需结合具体代码结构、测试覆盖与缺陷数据判断。

80%代码覆盖率阈值探讨

80%的阈值从何而来？

我做了一次强制性的谷歌搜索，希望可以找到一些科学上证明的依据，解释为什么默认阈值是80%。然而我一无所获。

然而，有观点将80%覆盖率阈值与帕累托原则联系起来，但这种联系并不足以证明阈值的来源或合理性。因此，不能将帕累托原则直接作为设置覆盖率门槛的依据。

帕累托原则规定，“大约80%的后果来自于20%的原因。”帕累托原则应用于测试的一个例子如下；

“80%的投诉来自于20%的重复问题。”

有很多方法可以将帕累托原则应用于测试。它可能意味着查看你80%的投诉，找到相应的代码并提高覆盖率和质量。或者，也许它意味着你将识别出为你的客户提供较大价值的20%的代码，并将80%的资源和精力放在那里。正确应用的话，它意味着你会花更多的时间测试重要的事情，比如“我们如何处理失败的交易”，而减少验证诸如“深色模式是否正常工作？”这样的事情的时间。

这并不是执行80%代码覆盖率所做的一切——它将每行代码在每个文件中的价值等同看待。这意味着如果你有一个文件有200行代码来验证用户的信用卡，另一个文件有200行代码允许用户将默认外观更改为暗模式，有些项目可能使用总体覆盖率门槛，也可能设置特定目录或文件级规则，但并不存在普遍适用的逐文件80%要求。很难量化维护这两个功能所需的努力程度，但任何人都应该明白其中一段代码具有显著更高的价值。