我更喜欢做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.

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

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

我认为不可能有这样的B/W规则。 应该审查代码，特别注意关键细节。 然而，如果它没有经过测试，它就有一个bug!

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

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

我认为正确的代码覆盖率的最佳症状是单元测试帮助解决的具体问题的数量合理地对应于您创建的单元测试代码的大小。

如果你已经做了相当长一段时间的单元测试，我认为没有理由不接近95%以上。然而，至少，我总是使用80%的测试，即使是刚开始测试的时候。

这个数字应该只包括在项目中编写的代码(不包括框架、插件等)，甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。