从另一个角度查看覆盖率:具有清晰控制流的编写良好的代码是最容易覆盖、最容易阅读的，并且通常是错误最少的代码。在编写代码时牢记清晰和可覆盖性，并在编写代码时并行编写单元测试，以我之见，您将得到最好的结果。

代码覆盖率很好，但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能，这些功能在会议中没有讨论)。

我不关心我的代码是否会在测试中被覆盖，但我关心的是我是否会重构我的代码并最终具有不同的行为。因此，100%的功能覆盖率是我的唯一目标。

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

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

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

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

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

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

这在很大程度上取决于您的应用程序。例如，一些应用程序主要由不能进行单元测试的GUI代码组成。