代码覆盖率很好，但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能，这些功能在会议中没有讨论)。

我不关心我的代码是否会在测试中被覆盖，但我关心的是我是否会重构我的代码并最终具有不同的行为。因此，100%的功能覆盖率是我的唯一目标。

代码覆盖率只是另一个度量。就其本身而言，它可能非常具有误导性(参见www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated)。因此，您的目标不应该是实现100%的代码覆盖率，而是要确保您测试了应用程序的所有相关场景。

我认为不可能有这样的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%。

代码覆盖率很好，但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能，这些功能在会议中没有讨论)。

我不关心我的代码是否会在测试中被覆盖，但我关心的是我是否会重构我的代码并最终具有不同的行为。因此，100%的功能覆盖率是我的唯一目标。

简单回答:60-80%

长一点的回答: 我认为这完全取决于你项目的性质。我通常通过单元测试每一个实际部分来开始一个项目。在项目的第一次“发布”时，你应该有一个相当不错的基于你所做的编程类型的基础百分比。在这一点上，您可以开始“强制”最小的代码覆盖率。