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

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

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

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

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

其他的笔记

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

我认为不可能有这样的B/W规则。 应该审查代码，特别注意关键细节。 然而，如果它没有经过测试，它就有一个bug!

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

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

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

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

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

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

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

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