代码覆盖率/分支覆盖率推荐值

Posted 2023-02-26

【中文标题】代码覆盖率/分支覆盖率推荐值

【英文标题】：Code coverage / branch coverage recommended values

【发布时间】：2012-01-11 14:53:45

【问题描述】：

我正在使用 Cobertura 计算带有 JUnit 测试用例的 Java 项目的代码/分支覆盖率。我知道 100% 的覆盖率并不能说明代码有多好，但目前是 6%。分支覆盖率为 1%。我的直觉说，由于该项目的决策性质，分支覆盖率可能更重要。由于这是我目前唯一的大项目，因此我对代码/分支覆盖目标的正确值没有经验。

我相信分支覆盖率在这个应用程序中非常重要，所以我将所需的值设置为 100%。我已将代码覆盖率阈值定义为 80%。

还有哪些因素会影响这些值的代码复杂性？

我可能过于强调数字，但我想听听其他人的经验。我知道这些值取决于项目的性质，但是我可以参考一些一般性的指针/文章/个人经验吗？

【参考方案1】：

当我测量用于功能测试的手动测试产生的分支覆盖率时，我得到了 ~65%

也看What is a reasonable code coverage % for unit tests (and why)?

【参考方案2】：

我想听听其他人的经验。

我编写了一个包含数千行代码的库，以及一个比库本身更长的覆盖套件。在 99.98% 的情况下，我涵盖了除一行之外的每一行：该方法来自一个遗留项目，而我不知道如何构建一个能够达到该行的测试用例。当我的库投入生产时，第一个错误报告是由那条未经测试的行引起的。

我从那个项目中学到的教训是，你不知道如何击中的线是最危险的。如果您的项目是决策密集型项目，那么获得 100% 的覆盖率符合您的最大利益。

【讨论】：

即使 100% 的线路覆盖率也不能保证软件没有错误。即使是 100% 的分支覆盖率也无法保证。

【参考方案3】：

在我工作过的大多数公司中，我们根本不强制执行分支机构覆盖。其中一家公司的分支覆盖率为 1.0，我可以告诉您，它既费时又无用。您的开发时间几乎翻了一番，最终得到一个充满无用测试的庞大代码库。此外，工程师通常不喜欢编写涵盖所有分支的测试，因为它很无聊。

对于线路覆盖率，0.7 的值效果很好，因为它迫使工程师覆盖大部分编写的代码。我工作过的大多数公司根本不强制执行测试覆盖率，这也是我喜欢的风格。工程师足够聪明，无需强制执行即可编写有用的测试。