我想分享另一个关于测试报道的趣闻。

我们有一个巨大的项目，在twitter上，我注意到，700个单元测试，我们只有20%的代码覆盖率。

斯科特·汉塞尔曼的回答充满智慧:

这是正确的20%吗?是20%吗 代表您的用户的代码 打击最大?你可能会再加50个 测试后只添加2%

这又回到了我关于代码覆盖率的答案。你应该在锅里放多少米?视情况而定。

我更喜欢做BDD，它使用自动化验收测试、可能还有其他集成测试和单元测试的组合。对我来说，问题是自动化测试套件作为一个整体的目标覆盖率应该是多少。

That aside, the answer depends on your methodology, language and testing and coverage tools. When doing TDD in Ruby or Python it's not hard to maintain 100% coverage, and it's well worth doing so. It's much easier to manage 100% coverage than 90-something percent coverage. That is, it's much easier to fill coverage gaps as they appear (and when doing TDD well coverage gaps are rare and usually worth your time) than it is to manage a list of coverage gaps that you haven't gotten around to and miss coverage regressions due to your constant background of uncovered code.

答案也取决于项目的历史。我发现上述方法只适用于从一开始就以这种方式管理的项目。我已经极大地改进了大型遗留项目的覆盖率，这样做是值得的，但是我从来没有发现回过头去填补每个覆盖率空白是可行的，因为旧的未经测试的代码不能很好地理解，不能正确和快速地完成这些工作。

从Testivus的帖子中，我认为答案上下文应该是第二个程序员。

从实际的角度来看，我们需要争取参数/目标。

我认为这可以在敏捷过程中进行“测试”，方法是分析我们拥有的代码、架构、功能(用户故事)，然后得出一个数字。根据我在电信领域的经验，我认为60%是一个很好的值。

根据代码的关键程度，75%-85%是一个很好的经验法则。 运输代码肯定应该比房屋公用事业等更彻底地测试。

一般来说，从我读过的几篇工程卓越最佳实践论文来看，单元测试中80%的新代码是产生最佳回报的点。如果超过这个CC%，所付出的努力就会产生更少的缺陷。这是许多大公司所采用的最佳实践。

不幸的是，这些结果大多是公司内部的，所以我没有公开的文献可供参考。

如果你的目标是100%的覆盖率(而不是100%测试所有功能)，那么代码覆盖率就是一个误导的指标。

你可以通过一次命中所有的线来获得100%。然而，您仍然可能错过测试这些行命中的特定序列(逻辑路径)。 您不能得到100%，但仍然测试了所有80%/频率使用的代码路径。测试每个“抛出ExceptionTypeX”或类似的防御性编程保护是“有就好”而不是“必须”

所以要相信你自己或你的开发人员是彻底的，并覆盖他们代码中的每一条路径。要务实，不要追求神奇的100%覆盖率。如果你用TDD开发你的代码，你应该得到90%以上的覆盖率作为奖励。使用代码覆盖来突出你错过的代码块(如果你使用TDD就不应该发生这种情况。因为您编写代码只是为了通过测试。没有伙伴测试，任何代码都不能存在。)