unit-testing - 您的项目的代码覆盖率是多少？

Question

你项目的代码覆盖率是多少？我很好奇为什么。

开发团队对此满意吗？如果没有，增加它的障碍是什么？

Stuart Halloway 的项目目标是 100%（否则构建会中断！）。有人在那个水平吗？

我们处于痛苦的 25%，但渴望 80-90% 的新代码。我们有遗留代码，我们决定在它消失时不去管它（我们正在积极重写）。

score 3 · Accepted Answer

我们以 85% 的代码覆盖率运行，但低于它并不会破坏构建。我认为使用代码覆盖率作为重要指标是一种危险的做法。仅仅因为某些东西在测试中被覆盖并不意味着覆盖是好的。我们尝试将其用作我们覆盖范围较弱的领域的指导，而不是作为一个硬性事实。

score 2 · Accepted Answer

80% 是里程碑的退出标准。如果我们没有通过 sprint（即使我们确实提前计划了时间），我们会通过稳定来添加它。我们可能会针对特定组件或功能进行例外处理，但我们会为下一个里程碑打开 Pri 1 项目。

在编码期间，代码覆盖率会在每日构建时自动测量，并将报告发送给整个团队。任何低于 70% 的东西都是黄色的，低于 50% 的东西是红色的。我们目前没有使构建失败，但我们计划在下一个里程碑中添加它。

不确定开发人员的快乐与单元测试有什么关系。聘请开发人员来构建优质产品，并且应该有一个流程来执行最低质量和衡量它的方法。如果有人对该过程不满意，他们可以自由地提出另一种验证其代码的方法，然后再将其与其余组件集成。

顺便说一句，我们也在自动化场景测试中测量代码覆盖率。因此，我们有三个 unmbers——单元、场景和组合。

score 1 · Accepted Answer

我们公司的目标是 80% 的语句覆盖率，包括异常处理代码。就个人而言，我喜欢在我检查的所有东西上都超过 90%。

score 0 · Accepted Answer

几年前我做的一个项目实现了 100% 的线路覆盖率，但我完全控制了它，因此我可以执行目标。
我们现在的目标是覆盖 50% 的新代码，这个数字在不久的将来会上升，但无法衡量。我们很快就会有工具来测量每晚运行单元测试的代码覆盖率，所以我相信我们的情况会有所改善。

score 0 · Accepted Answer

我经常在我们的自动化测试套件下使用代码覆盖率，但主要是为了寻找未测试的区域。我们大部分时间都得到大约 70% 的覆盖率，并且永远不会达到 100%，原因有两个；

1) 我们通常会在发布后自动执行新功能，这些功能会在首次发布时进行手动测试，因此不包含在覆盖率分析中。在我们的案例中，自动化主要用于功能回归，并且是执行和调整代码覆盖率的最佳场所。

2) 需要故障注入才能获得 100% 的覆盖率，因为您需要进入执行处理程序。自动化是困难且耗时的。我们目前不这样做，因此永远不会得到 100%。Jame 的 Whittakers 关于破解软件的书籍很好地涵盖了这个主题，任何有兴趣的人都可以阅读。

还值得记住的是，代码覆盖率并不等同于测试覆盖率，正如SQAforums 上的this和this等线程中经常讨论的那样。因此，100% 的代码覆盖率可能是一个误导性指标。

score 0 · Accepted Answer

几年前，我测量了 Perl 的测试覆盖率。在 250 个测试用例结束时，它达到了 70% 的代码和 33% 的完全测试分支

score 0 · Accepted Answer

0% 可悲的是在我们的工作场所。将致力于改善这一点，但试图告诉老板我们需要它，这并不容易，因为他们看到了测试！= 编码更少的钱。

7 回答 7