自动化测试并不总是最经济有效的方法。

永远不要花六分钟手工地做某事，当你可以花六个小时试图自动化它 - 张佐威

为了符合投资回报的主题，我确实认为开发者忘记了一个事实，即自动化代码测试并不是测试功能或代码的唯一方法。如果你正在开发一个基于网页的应用程序，有像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%。很难量化维护这两个功能所需的努力程度，但任何人都应该明白其中一段代码具有显著更高的价值。

将80%的帕累托原则作为默认最低阈值让我觉得这是误解、严重误用，坦白说，这很可笑。比误解它并将其作为 everywhere代码覆盖率的默认值更荒谬的事情，是盲目相信代码覆盖率为衡量代码的终极指标。

正因如此，我相信我们所有人都使用80%的原因是因为80/20法则。有人在某个地方读到它，没有理解它的意思，喜欢它听起来的样子，然后将其设为默认。

我的意思是，80%也是美国大多数学校（及其他地方）B等级的最低标准。没有人愿意写出C等级的代码，但在到处都要求B作为最低标准，感觉上就像是足够好了。开发者现在生活在一个所有我们的拉取请求都因为某人误解了80/20法则或继续以字母等级来思考而被扣留的世界里。