如果你已经做了相当长一段时间的单元测试，我认为没有理由不接近95%以上。然而，至少，我总是使用80%的测试，即使是刚开始测试的时候。

这个数字应该只包括在项目中编写的代码(不包括框架、插件等)，甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。

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

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

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

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

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

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

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

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

底层流程是:

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

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

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

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

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

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

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