Jon Limjap提出了一个很好的观点——没有一个单一的数字可以作为每个项目的标准。有些项目根本不需要这样的标准。在我看来，公认的答案不足之处在于，它没有描述一个人如何为一个给定的项目做出决定。

我将尝试这样做。我不是测试工程方面的专家，很高兴看到一个更明智的答案。

何时设置代码覆盖率需求

First, why would you want to impose such a standard in the first place? In general, when you want to introduce empirical confidence in your process. What do I mean by "empirical confidence"? Well, the real goal correctness. For most software, we can't possibly know this across all inputs, so we settle for saying that code is well-tested. This is more knowable, but is still a subjective standard: It will always be open to debate whether or not you have met it. Those debates are useful and should occur, but they also expose uncertainty.

代码覆盖率是一种客观的度量:一旦您看到覆盖率报告，对于是否满足标准是有用的就没有什么不明确的了。它能证明正确性吗?完全不是，但是它与代码测试的良好程度有明确的关系，这反过来是我们增加对其正确性信心的最佳方式。代码覆盖率是我们所关心的不可测量的质量的可测量近似值。

在某些具体情况下，经验标准可以增加价值:

To satisfy stakeholders. For many projects, there are various actors who have an interest in software quality who may not be involved in the day-to-day development of the software (managers, technical leads, etc.) Saying "we're going to write all the tests we really need" is not convincing: They either need to trust entirely, or verify with ongoing close oversight (assuming they even have the technical understanding to do so.) Providing measurable standards and explaining how they reasonably approximate actual goals is better. To normalize team behavior. Stakeholders aside, if you are working on a team where multiple people are writing code and tests, there is room for ambiguity for what qualifies as "well-tested." Do all of your colleagues have the same idea of what level of testing is good enough? Probably not. How do you reconcile this? Find a metric you can all agree on and accept it as a reasonable approximation. This is especially (but not exclusively) useful in large teams, where leads may not have direct oversight over junior developers, for instance. Networks of trust matter as well, but without objective measurements, it is easy for group behavior to become inconsistent, even if everyone is acting in good faith. To keep yourself honest. Even if you're the only developer and only stakeholder for your project, you might have certain qualities in mind for the software. Instead of making ongoing subjective assessments about how well-tested the software is (which takes work), you can use code coverage as a reasonable approximation, and let machines measure it for you.

使用哪些指标

代码覆盖率不是单一的度量;有几种不同的方法来衡量覆盖率。您可以根据哪一种标准来设置标准，这取决于您使用该标准来满足什么。

我将使用两个常见的指标作为例子，说明何时可以使用它们来设置标准:

Statement coverage: What percentage of statements have been executed during testing? Useful to get a sense of the physical coverage of your code: How much of the code that I have written have I actually tested? This kind of coverage supports a weaker correctness argument, but is also easier to achieve. If you're just using code coverage to ensure that things get tested (and not as an indicator of test quality beyond that) then statement coverage is probably sufficient. Branch coverage: When there is branching logic (e.g. an if), have both branches been evaluated? This gives a better sense of the logical coverage of your code: How many of the possible paths my code may take have I tested? This kind of coverage is a much better indicator that a program has been tested across a comprehensive set of inputs. If you're using code coverage as your best empirical approximation for confidence in correctness, you should set standards based on branch coverage or similar.

还有许多其他指标(例如，行覆盖率与语句覆盖率相似，但对于多行语句产生不同的数值结果;条件覆盖和路径覆盖类似于分支覆盖，但反映了您可能遇到的程序执行的可能排列的更详细的视图。)

需要多大的比例

最后，回到最初的问题:如果您设置了代码覆盖率标准，那么这个数字应该是多少?

希望大家已经很清楚了我们讨论的是一开始的近似值，所以我们选的任何数都是固有的近似值。

你可以选择一些数字:

100%. You might choose this because you want to be sure everything is tested. This doesn't give you any insight into test quality, but does tell you that some test of some quality has touched every statement (or branch, etc.) Again, this comes back to degree of confidence: If your coverage is below 100%, you know some subset of your code is untested. Some might argue that this is silly, and you should only test the parts of your code that are really important. I would argue that you should also only maintain the parts of your code that are really important. Code coverage can be improved by removing untested code, too. 99% (or 95%, other numbers in the high nineties.) Appropriate in cases where you want to convey a level of confidence similar to 100%, but leave yourself some margin to not worry about the occasional hard-to-test corner of code. 80%. I've seen this number in use a few times, and don't entirely know where it originates. I think it might be a weird misappropriation of the 80-20 rule; generally, the intent here is to show that most of your code is tested. (Yes, 51% would also be "most", but 80% is more reflective of what most people mean by most.) This is appropriate for middle-ground cases where "well-tested" is not a high priority (you don't want to waste effort on low-value tests), but is enough of a priority that you'd still like to have some standard in place.

在实践中，我从未见过低于80%的数字，也很难想象在什么情况下会设置这些数字。这些标准的作用是增强人们对正确性的信心，而低于80%的数字并不能特别鼓舞人们的信心。(是的，这是主观的，但同样，这个想法是在你设定标准时做出一次主观选择，然后再使用客观的测量方法。)

其他的笔记

以上假设正确性是目标。代码覆盖率只是信息;它可能与其他目标相关。例如，如果您关心可维护性，那么您可能会关心松耦合，松耦合可以通过可测试性来证明，而可测试性又可以(以某种方式)通过代码覆盖率来度量。因此，代码覆盖率标准也为近似“可维护性”的质量提供了经验基础。

我最喜欢的代码覆盖率是100%。星号之所以出现，是因为我更喜欢使用工具，允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行，我就完成了。

底层流程是:

我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径，以及我认为不重要或无法到达的线或路径(由于防御性编程)，我将其标记为不算数 我编写了新的测试来覆盖缺失的行，并在没有提到这些边缘情况时改进文档。

这样，如果我和我的合作者将来添加新代码或更改测试，就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而，它也提供了处理不同测试优先级的灵活性。

简单回答:60-80%

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

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

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

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

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

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

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

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

我使用cobertura，无论百分比是多少，我都建议保持cobertura检查任务中的值是最新的。至少，不断提高totallinerate和totalbranrate到刚好低于你当前的覆盖率，但永远不要降低这些值。还将Ant构建失败属性绑定到此任务。如果构建因为缺乏覆盖而失败，那么您知道有人添加了代码，但没有测试它。例子:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

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

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