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

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

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

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

根据代码的关键程度，75%-85%是一个很好的经验法则。 运输代码肯定应该比房屋公用事业等更彻底地测试。

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%的数字并不能特别鼓舞人们的信心。(是的，这是主观的，但同样，这个想法是在你设定标准时做出一次主观选择，然后再使用客观的测量方法。)

其他的笔记

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

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

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

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

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