# 自动化测试覆盖率要到多少才算足够


本文非原创，翻译自[https://qahiccupps.blogspot.com/2021/09/693-ok.html](https://qahiccupps.blogspot.com/2021/09/693-ok.html?utm_campaign=Software%2BTesting%2BWeekly&utm_medium=email&utm_source=Software_Testing_Weekly_89)

“我们的测试用例中有多少是自动化的？”

这个问题有很多内容，特别是当它是监控测试状态的指标的时候。这也不是我第一次被问到。根据我的经验，当有人提出这个问题时，可能是因为（a）他们听说过它，（b）测试用例的数量是可数的，并且（c）他们的任务是提供一个管理层可以接受的数字，并且每月向大量不会看它的人发邮件做 ppt，然后阐述自动化“测试”的价值。

如果这听起来很愤世嫉俗……好吧，我想是的。

但是，并不意味着我对了解您的需求并试图帮助你获得可以你需求的东西不感兴趣。

我们能谈谈你的追求吗？为什么？

我们可以？太好了！

我会开始。我对这个问题的一些考量是：

- 自动化测试覆盖率似乎被认为是我们测试的一种衡量标准
- 这样的数字不会说明做过的测试的价值
- 测试用例的定义没有实际意义
- ...而且，不管它们是什么，测试用例只是我们测试的一部分
- 有一个隐含的假设，即自动化程度越高越好
- ...但自动化有其自身的风险
- ...而且，无论自动化意味着什么，自动化测试用例只是我们测试自动化的一部分

如果我看看我们的测试方式，以及我们可能称之为测试用例的内容，我现在可以想到三种方式来回答您的问题：

1. 从我认为问题的意图来看，我们没有测试用例。我们所有正在进行的测试都是探索性测试，虽然我们可能会用自动化的方式记录测试结果，测试完成以后我们把现存的用例转换成自动化是没有意义的，我们标记为得分为 0%。
2. 出于练习的目的，我准备将回归测试用例集中的每个断言描述为一个测试用例。因为它们将是我们唯一的测试用例，而且它们都是自动化的。得分 100%！
3. 好的，我们在测试用例管理系统中有一些项目。这些是历史的发布验证记录，（大多数）测试团队以外的人在我们发布之前会进行这些检查。我更喜欢将它们视为检查点，但我很现实，并且知道我的一些同事只是想遵循步骤。相对于“自动化测试用例”的数量，它们很少，但如果我们将它们包括在我们的计算中，我们会将分数降低到 99%。

这些答案对我们中的任何一个来说似乎都不是很令人满意，是吗？

对我来说，这种指标充其量只涵盖了我们所做工作的一小部分，其背后的假设非常值得怀疑。对您而言，该指标的重要性不及某个合理的数字，该数字可以在 ppt 中用来量化测试的最终效果。对此我也有一些想法：

- 对我来说，测试是知识性的工作，因此很难用简单的数字来衡量
- 测试不是独立于其他产品开发活动而存在的
- 如果没有创建测试用例等人工产出物的话我们也可以完成良好的测试
- 没有经过对话交流和正当理由而强加的指标可能会受到怀疑
- 强加的指标可能会有被造假的风险
- 从产出物（bug 列表，用例设计）开始是本末倒置
- ... 最好先问你想测量的指标是什么以及为什么

那么，例如，是否希望衡量客户对产品的满意度？是为了衡量测试的贡献吗？是否要查看时间花在了企业想要停止的活动上？是寻找瓶颈吗？或者是其他东西？如果我们同意使用某种指标，我们如何向测试人员保证他们没有受到不公正的评价，并且他们不应该为了使数字看更好而修饰或者歪曲他们的工作实践？

我们需要的不仅仅是花言巧语。想象一下，你被告知你的表现将根据你发送的电子邮件数量来衡量，你会如何反应？你会在讥讽它的同时但还是发送更多的电子邮件吗？您会发送电子邮件而不是进行丁丁或者是企业微信的沟通吗？您会关心对您、他人和企业的潜在不利影响吗？别人怎么能说服你采取不同的行为？最后，您是否真的希望以良好的意图研究合理的指标并根据结果采取行动？如果是这样，那么我将尽我所能帮助获得一些合理的东西，有明确的警告，公平的，透明的，承认其收集涉及的混乱，可以有效地从数据中得出我们有，这在商定的误差范围内，这反映了我们正在做的工作。如果没有，那么我会问你什么样的数字会更好的反映出实际的工作效果？我会简单地告诉你：让我们说 69.3%，好吗？

作者使用的英文没有那么通俗，加上翻译能力有限，所以最后可能需要简单的提炼一下文章的观点

- 自动化测试的覆盖率应该不能作为汇报测试效果的指标
- 测试的目的不是为了产出好看的数据或者指标
- 不合理的指标会造成不合理的结果而忽略了测试工作的实质