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

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%。

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

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

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

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

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

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

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

我更喜欢做BDD，它使用自动化验收测试、可能还有其他集成测试和单元测试的组合。对我来说，问题是自动化测试套件作为一个整体的目标覆盖率应该是多少。

That aside, the answer depends on your methodology, language and testing and coverage tools. When doing TDD in Ruby or Python it's not hard to maintain 100% coverage, and it's well worth doing so. It's much easier to manage 100% coverage than 90-something percent coverage. That is, it's much easier to fill coverage gaps as they appear (and when doing TDD well coverage gaps are rare and usually worth your time) than it is to manage a list of coverage gaps that you haven't gotten around to and miss coverage regressions due to your constant background of uncovered code.

答案也取决于项目的历史。我发现上述方法只适用于从一开始就以这种方式管理的项目。我已经极大地改进了大型遗留项目的覆盖率，这样做是值得的，但是我从来没有发现回过头去填补每个覆盖率空白是可行的，因为旧的未经测试的代码不能很好地理解，不能正确和快速地完成这些工作。

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

如果这是一个完美的世界，100%的代码将被单元测试覆盖。然而，因为这不是一个完美的世界，这是一个你有时间做什么的问题。因此，我建议少关注特定的百分比，而更多地关注关键领域。如果你的代码写得很好(或者至少是一个合理的副本)，应该有几个关键点将api暴露给其他代码。

将您的测试工作集中在这些api上。确保api是1)良好的文档化的，2)已经编写了与文档相匹配的测试用例。如果预期的结果与文档不匹配，那么您的代码、文档或测试用例中都存在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%的数字并不能特别鼓舞人们的信心。(是的，这是主观的，但同样，这个想法是在你设定标准时做出一次主观选择，然后再使用客观的测量方法。)

其他的笔记

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