从另一个角度查看覆盖率:具有清晰控制流的编写良好的代码是最容易覆盖、最容易阅读的，并且通常是错误最少的代码。在编写代码时牢记清晰和可覆盖性，并在编写代码时并行编写单元测试，以我之见，您将得到最好的结果。

这取决于您所处的应用程序开发生命周期的哪个阶段。

If you've been at development for a while and have a lot of implemented code already and are just now realizing that you need to think about code coverage then you have to check your current coverage (if it exists) and then use that baseline to set milestones each sprint (or an average rise over a period of sprints), which means taking on code debt while continuing to deliver end user value (at least in my experience the end user doesn't care one bit if you've increased test coverage if they don't see new features).

根据你的领域，达到95%并不是不合理的，但我不得不说，平均而言，你将看到的平均情况是85%到90%。

我认为最重要的是了解随着时间的推移，覆盖率的趋势是什么，并理解趋势变化的原因。你认为趋势的变化是好是坏取决于你对原因的分析。

一般来说，从我读过的几篇工程卓越最佳实践论文来看，单元测试中80%的新代码是产生最佳回报的点。如果超过这个CC%，所付出的努力就会产生更少的缺陷。这是许多大公司所采用的最佳实践。

不幸的是，这些结果大多是公司内部的，所以我没有公开的文献可供参考。

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%的功能覆盖率是我的唯一目标。