看看Crap4j。这是一种比直接代码覆盖稍微复杂一些的方法。它结合了代码覆盖率度量和复杂性度量，然后向您展示哪些复杂的代码目前没有测试。

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

看看Crap4j。这是一种比直接代码覆盖稍微复杂一些的方法。它结合了代码覆盖率度量和复杂性度量，然后向您展示哪些复杂的代码目前没有测试。

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

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

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

如果这是一个完美的世界，100%的代码将被单元测试覆盖。然而，因为这不是一个完美的世界，这是一个你有时间做什么的问题。因此，我建议少关注特定的百分比，而更多地关注关键领域。如果你的代码写得很好(或者至少是一个合理的副本)，应该有几个关键点将api暴露给其他代码。

将您的测试工作集中在这些api上。确保api是1)良好的文档化的，2)已经编写了与文档相匹配的测试用例。如果预期的结果与文档不匹配，那么您的代码、文档或测试用例中都存在bug。所有这些都是值得调查的。

好运！