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

简单回答:60-80%

长一点的回答: 我认为这完全取决于你项目的性质。我通常通过单元测试每一个实际部分来开始一个项目。在项目的第一次“发布”时，你应该有一个相当不错的基于你所做的编程类型的基础百分比。在这一点上，您可以开始“强制”最小的代码覆盖率。

对于一个设计良好的系统，单元测试从一开始就驱动开发，我认为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%测试所有功能)，那么代码覆盖率就是一个误导的指标。

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

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

我对这个难题的回答是，对可以测试的代码有100%的行覆盖率，对不能测试的代码有0%的行覆盖率。

我目前在Python中的做法是将.py模块分为两个文件夹:app1/和app2/，当运行单元测试时，计算这两个文件夹的覆盖率，并直观地检查(有朝一日我必须自动化)app1的覆盖率为100%，而app2的覆盖率为0%。

当/如果我发现这些数字与标准不同，我会调查并改变代码的设计，使覆盖率符合标准。

这意味着我可以建议实现库代码的100%行覆盖率。

我也偶尔检查app2/，看看我是否可以在那里测试任何代码，如果我可以，我将它移动到app1/

现在我不太担心总覆盖率，因为这取决于项目的规模，但通常情况下我看到的是70%到90%以上。

使用python，我应该能够设计一个烟雾测试，可以自动运行我的应用程序，同时测量覆盖率，并有希望获得100%的烟雾测试与单元测试数字的聚合。

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

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