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

85%是签入标准的一个很好的起点。

我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。

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

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

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

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

我认为最重要的是了解随着时间的推移，覆盖率的趋势是什么，并理解趋势变化的原因。你认为趋势的变化是好是坏取决于你对原因的分析。

代码覆盖率是很好的，但前提是你从中得到的好处超过了实现它的成本/努力。

一段时间以来，我们一直在努力达到80%的标准，但我们刚刚决定放弃这个标准，转而更专注于我们的测试。专注于复杂的业务逻辑等，

这个决定是由于我们花在追逐代码覆盖率和维护现有单元测试上的时间越来越多。我们觉得我们已经到达了这样一个点:我们从代码覆盖率中得到的好处被认为比我们为实现它所付出的努力要少。