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

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

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

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

许多商店不看重测试的价值，所以如果你高于零，至少有一些价值的升值——所以可以说非零并不是坏事，因为许多仍然是零。

在。net世界中，人们经常引用80%作为合理的。但题目说的是溶液水平。我更喜欢在项目级别进行度量:如果有Selenium等或手动测试，那么UI项目的30%可能就可以了，数据层项目的20%可能就可以了，但是对于业务规则层(如果不是完全必要的话)，95%以上可能是可以实现的。因此，总体覆盖率可能是60%，但关键业务逻辑可能更高。

我也听过这样的话:追求100%，你就能达到80%;但是，立志达到80%，你就会达到40%。

底线:应用80:20规则，让应用程序的bug计数来指导你。

对于一个设计良好的系统，单元测试从一开始就驱动开发，我认为85%是一个相当低的数字。设计为可测试的小类应该不难更好地覆盖。

我们很容易用这样的话来回避这个问题:

覆盖的行不等于测试的逻辑，不应该对百分比进行过多的解读。

没错，但是关于代码覆盖有一些重要的地方需要注意。根据我的经验，如果使用得当，这个指标实际上非常有用。话虽如此，我并没有见过所有的系统，我敢肯定有很多系统很难看到代码覆盖率分析增加任何真正的价值。代码可能看起来很不一样，可用测试框架的范围也可能不同。

此外，我的推理主要涉及相当短的测试反馈循环。对于我正在开发的产品，最短的反馈循环非常灵活，涵盖了从类测试到进程间信号的所有内容。测试一个可交付的子产品通常需要5分钟，对于这样短的反馈循环，确实可以使用测试结果(特别是我们在这里看到的代码覆盖率指标)来拒绝或接受存储库中的提交。

当使用代码覆盖率度量时，您不应该只有一个必须实现的固定(任意)百分比。在我看来，这样做并不能给您带来代码覆盖率分析的真正好处。相反，定义以下指标:

低水位标记(LWM)，在测试系统中所见过的最低裸露线数 高水位标记(HWM)，在测试系统中所见过的最高代码覆盖率

只有在不超过LWM和不低于HWM的情况下，才能添加新代码。换句话说，不允许减少代码覆盖率，并且应该覆盖新代码。注意我如何说应该和不必须(下面解释)。

但这难道不意味着，你将不可能清理那些久经考验、不再有用的旧垃圾吗?是的，这就是为什么你在这些事情上必须务实。有些情况下必须打破规则，但根据我的经验，对于典型的日常集成来说，这些指标非常有用。他们给出了以下两个暗示。

Testable code is promoted. When adding new code you really have to make an effort to make the code testable, because you will have to try and cover all of it with your test cases. Testable code is usually a good thing. Test coverage for legacy code is increasing over time. When adding new code and not being able to cover it with a test case, one can try to cover some legacy code instead to get around the LWM rule. This sometimes necessary cheating at least gives the positive side effect that the coverage of legacy code will increase over time, making the seemingly strict enforcement of these rules quite pragmatic in practice.

同样，如果反馈循环太长，在集成过程中设置这样的东西可能是完全不切实际的。

我还想提到代码覆盖度量的另外两个一般好处。

Code coverage analysis is part of the dynamic code analysis (as opposed to the static one, i.e. Lint). Problems found during the dynamic code analysis (by tools such as the purify family, http://www-03.ibm.com/software/products/en/rational-purify-family) are things like uninitialized memory reads (UMR), memory leaks, etc. These problems can only be found if the code is covered by an executed test case. The code that is the hardest to cover in a test case is usually the abnormal cases in the system, but if you want the system to fail gracefully (i.e. error trace instead of crash) you might want to put some effort into covering the abnormal cases in the dynamic code analysis as well. With just a little bit of bad luck, a UMR can lead to a segfault or worse. People take pride in keeping 100% for new code, and people discuss testing problems with a similar passion as other implementation problems. How can this function be written in a more testable manner? How would you go about trying to cover this abnormal case, etc.

为了完整起见，一个是否定的。

In a large project with many involved developers, everyone is not going to be a test-genius for sure. Some people tend to use the code coverage metric as proof that the code is tested and this is very far from the truth, as mentioned in many of the other answers to this question. It is ONE metric that can give you some nice benefits if used properly, but if it is misused it can in fact lead to bad testing. Aside from the very valuable side effects mentioned above a covered line only shows that the system under test can reach that line for some input data and that it can execute without hanging or crashing.

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

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

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

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