0

可能重复：
单元测试的合理代码覆盖率是多少（为什么）？

我正在整理一些关于单元测试代码覆盖率的指导方针，我想指定一个真正有意义的数字。很容易重复我在互联网上看到的 100% 口头禅，而无需考虑成本效益分析以及实际收益递减的情况。

我征求那些实际报告过现实生活中的大中型项目代码覆盖率的人的意见。你看到的百分比是多少？多少是太多了？我真的想要一些平衡（以数字表示），这将有助于开发人员生成高质量的代码。65% 的覆盖率是否太低而无法预期？80%太高了吗？

4

6 回答 6

4

当您将代码覆盖率与圈复杂度混合在一起时，您可以使用 CRAP 指标。

来自artima.com：

个别方法解释：

Bob Evans 和我查看了很多示例（使用我们的代码和许多开源项目）并听取了很多意见。经过多次辩论，我们决定最初使用 30 的 CRAP 分数作为糟糕的阈值。下表显示了根据方法的复杂性保持在 CRAP 阈值以下所需的测试覆盖率：

方法的圈复杂度 所需覆盖率的百分比
                                      低于糟糕的阈值
------------------------------ -------------------- ------------
0 – 5 0%
10 42%
15 57%
20 71%
25 80%
30 100%
31+ 再多的测试也不会保留方法    
                                      这个复杂的垃圾领域。

没有多少代码覆盖率本身就可以保证“高质量代码”。

从评论...

将简单的方法传递给覆盖范围肯定是太松懈了。在现有代码上实现此功能时，您可能会发现代码覆盖率会随着您重构那些丑陋的方法而增加（代码覆盖率应该会增加，否则您会进行危险的重构）。

0-5 基本上是唾手可得的成果，投资回报率也不是那么好。话虽如此，这些方法非常适合学习 TDD，因为它们通常很容易测试。

于 2010-05-05T18:03:26.380 回答
2

就我个人而言，我会选择 80% 的覆盖率，但这当然只是相对的……我个人还没有达到这个目标。

目前，我们的实用程序类的覆盖率非常高（99%），这很好，因为那里的错误会在整个应用程序中追捕你。

大多数 GUI 的覆盖率一般，因为为它们编写测试既困难又费时，所以我们经常在单元测试中打开 gui，如果没有错误，我们会自动关闭它。

于 2010-05-05T17:57:41.507 回答
0

我不认为你真的可以有太多的代码覆盖率。我认为您需要确定哪些代码在应用程序中运行“常规业务流程”并完全覆盖。对于不在正常业务过程中的剩余代码，首先通过执行最关键的操作来开始削减它。不太重要的异常业务在获得良好的代码覆盖率方面收益很低。

于 2010-05-05T18:01:56.677 回答
0

唯一正确的答案是尽可能多地进行测试。显然，这是每个工程项目的公理。

除此之外，这都是主观的，并且高度依赖于手头的项目。例如，洛克希德推出的飞行控制系统最好测试超过 80%，但对于我的 GUI 前端到 XML 查看器来说，80% 可能就足够了。

通常，您会分解与团队一起运行测试的成本。在理论界，人们习惯用工时作为问题的结果：我们能负担多少测试？

在此之后，您将检查您的模块并确定代码的哪些部分花费的时间最多。每个关键模块都应该被覆盖一次。从这里开始，与执行特定模块的时间量相比，您可以提供适当数量的测试。所以最后，没有“X%”的硬数字被覆盖。

约翰穆萨有一本关于这个主题的非常有趣的书。

于 2010-05-05T18:13:57.330 回答
0

在我正在使用的程序（~500k SLOC）上，我们使用 100%。这是进入下一阶段测试的程序要求。以下是其背后的原因：

  1. 该程序用于一些安全的关键情况，您不希望不测试任何非标称条件

  2. 如果您没有达到 100%，那么您要么编写了不必要的代码，因此浪费了金钱，或者您没有完全测试您的标称路径。见#1。

  3. 无论您使用的实际程序代码覆盖率指标如何，您的单元测试场景自然应该让您接近 100%。如果某人仅根据他们的非标称情景达到 95%，那么要求 100% 并不繁重（同样，您应该问为什么那时您没有达到 100%。请参阅 #2。）

您的里程肯定会有所不同。如果您不从事任务/安全关键应用程序，那么您可能不需要担心您的代码覆盖率 - 但是，我不得不再次问：您为什么要编写您不编写的代码'不需要？

[编辑]

根据我在下面收到的评论，我应该澄清一下。程序指南是单元测试的 100% 代码覆盖率。如果由于技术原因无法到达代码分支（从不调用的受保护的默认构造函数等），则可以放弃该开发过程要求。批准通常由组织的外部独立部分授予（go go SQA ）。

从集成/系统测试开始，当您开始查看需求覆盖率时，代码覆盖率变得毫无意义。那是完全不同的毛线球。

最初的问题是寻找真实世界的情况：我同意并非（大多数？）所有真实世界的情况都可以保证在单元测试级别上 100% 的代码覆盖率，但肯定有案例可以做到，程序也可以做到。一些开发人员的习惯是编写他们不需要的代码，然后最终未经测试。这变成了维护的噩梦，因为后一个开发人员将调用从未“打算”使用的方法（或者因为有人认为它们是一个“好”的想法而被包含在内）。拍摄 100% 的覆盖率迫使你回答“我为什么要写这个？”这个问题。

于 2010-05-05T18:22:32.383 回答
-1

这真的取决于。我知道很多软件都是 0%。我有很多具有个位数百分比的软件。主要问题是在财务方面真正需要和想要什么。

于 2010-05-05T17:57:11.180 回答