对于一个设计良好的系统，单元测试从一开始就驱动开发，我认为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.

在我看来，答案是“这取决于你有多少时间”。我试着达到100%，但如果我没有在我拥有的时间内完成它，我也不会大惊小怪。

当我编写单元测试时，我戴着与开发产品代码时不同的帽子。我考虑测试的代码声称要做什么，以及可能破坏它的情况是什么。

我通常遵循以下标准或规则:

单元测试应该是关于我的代码的预期行为的一种文档形式。给定特定输入的预期输出以及它可能抛出的客户端可能想要捕获的异常(我的代码的用户应该知道什么?) 单元测试应该帮助我发现我可能还没有想到的假设条件。(如何使我的代码稳定和健壮?)

如果这两条规则不能产生100%的覆盖率，那就顺其自然吧。但是一旦我有时间，我就会分析未覆盖的块和行，并确定是否仍然存在没有单元测试的测试用例，或者是否需要重构代码以消除不必要的代码。

直到几天前，我们的目标是>的80%，但在我们使用了大量生成代码后，我们并不关心%age，而是让审核人员决定覆盖率要求。

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

从Testivus的帖子中，我认为答案上下文应该是第二个程序员。

从实际的角度来看，我们需要争取参数/目标。

我认为这可以在敏捷过程中进行“测试”，方法是分析我们拥有的代码、架构、功能(用户故事)，然后得出一个数字。根据我在电信领域的经验，我认为60%是一个很好的值。

当我认为我的代码没有经过足够的单元测试，并且我不确定接下来要测试什么时，我使用覆盖率来帮助我决定接下来要测试什么。

如果我在一个单元测试中增加覆盖率——我知道这个单元测试有价值。

这适用于未覆盖的代码，50%覆盖或97%覆盖。