单元测试的合理代码覆盖率是多少(以及为什么)？

Question

如果你要求单元测试的最小代码覆盖率,甚至可能作为提交到存储库的要求,它会是什么？

请解释你是如何得出答案的(因为如果你所做的只是选择一个号码,那么我本可以自己完成这一切;)

Answer 1

Alberto Savoia的这篇散文正好回答了这个问题(以一种非常有趣的方式解决了这个问题!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus On Test Coverage

一天早上,程序员问大师:

"我准备写一些单元测试了.我应该针对什么代码覆盖？"

大师回答说:

"不要担心报道,只要写一些好的测试."

程序员微笑,鞠躬,然后离开了.

...

那天晚些时候,第二个程序员问了同样的问题.

大师指着一壶开水说:

"我应该在那个锅里放几粒米饭？"

看起来困惑的程序员回答说:

"我怎么可能告诉你？这取决于你需要喂多少人,他们有多饥饿,你正在服务的其他食物,你有多少米,等等.

"没错,"大师说.

第二个程序员微笑,鞠躬,然后离开.

...

在一天结束时,第三位程序员来到并询问有关代码覆盖率的相同问题.

"百分之八十也不少!"主人用严厉的声音回答说,把拳头砸在桌子上.

第三个程序员微笑,鞠躬,然后离开了.

...

在最后的回复之后,一位年轻的学徒找到了这位大师:

"大师,今天我无意中听到你用三个不同的答案回答了有关代码覆盖的相同问题.为什么？"

伟大的大师从椅子上站起来:

"快来和我一起喝点新鲜的茶,让我们谈谈吧."

在他们的杯子里装满了热的绿茶之后,这位伟大的大师开始回答:

"第一个程序员是新手,刚刚开始测试.现在他有很多代码,没有测试.他还有很长的路要走; 在这个时候专注于代码覆盖将是令人沮丧和无用的.他最好习惯于编写和运行一些测试.他以后可以担心报道."

"另一方面,第二个程序员在编程和测试方面都非常有经验.当我回答问她应该放入多少粒米饭时,我帮助她意识到必要的测试量取决于许多因素,她比我更了解这些因素 - 毕竟这是她的代码.没有单一,简单的答案,而且她足够聪明,能够处理真相并与之合作."

"我明白了,"年轻的学徒说,"但如果没有一个简单的答案,那你为什么回答第三个程序员'百分之八十也不少'？"

这位伟大的大师笑得如此之大,以至于他的肚子,证据表明他喝的不仅仅是绿茶,而是上下颠簸.

"第三个程序员只想要简单的答案 - 即使没有简单的答案......然后无论如何都不会遵循它们."

年轻的徒弟和头发花白的大师在沉思的沉默中喝完了他们的茶.

Answer 2

如果100%覆盖率是您的目标(而不是对所有功能进行100%测试),则代码覆盖率是一种误导性指标.

• 你可以通过一次击中所有线来得到100%.但是,您仍然可能错过测试命中这些行的特定序列(逻辑路径).
• 您无法获得100%但仍测试了所有80%/ freq使用的代码路径.测试每个'抛出ExceptionTypeX'或类似的防御性编程守卫你测试的是'很高兴'而不是'必须拥有'

因此,请相信自己或您的开发人员要彻底,并通过他们的代码覆盖每条路径.务实,不要追逐神奇的100%报道.如果您使用TDD代码,则应获得90%以上的奖金.使用代码覆盖来突出显示您错过的代码块(如果您使用TDD,则不应该发生...因为您只编写代码以进行测试通过.没有合作伙伴测试,代码就不会存在.)

Answer 3

代码覆盖率很高,但功能覆盖率更高.我不相信我写的每一行.但我确实相信我想要提供的所有功能的100%测试覆盖率(即使是我自己带来的超酷功能,也没有在会议期间讨论过).

我不在乎我是否会有测试中没有涉及的代码,但我会关心我是否会重构我的代码并最终有不同的行为.因此,100%的功能覆盖是我唯一的目标.

Answer 4

接受的答案提出了一个很好的观点 - 没有一个数字作为每个项目的标准都有意义.有些项目不需要这样的标准.在我看来,接受的答案不足之处在于描述如何为特定项目做出决定.

我会这样做.我不是测试工程专家,很乐意看到更明智的答案.

何时设置代码覆盖要求

首先,你为什么要首先强加这样一个标准？一般来说,当你想在你的过程中引入经验信心时."经验信心"是什么意思？那么,真正的目标正确性.对于大多数软件,我们不可能在所有输入中知道这一点,因此我们决定说代码经过充分测试.这是更容易理解的,但仍然是一个主观标准:无论你是否遇到它,总是可以辩论.这些辩论是有用的,应该发生,但它们也暴露了不确定性.

代码覆盖率是一个客观的衡量标准:一旦您看到您的覆盖率报告,就没有关于标准是否有用的歧​​义.它证明是正确的吗？完全没有,但它与代码的良好测试有明确的关系,这反过来又是我们提高其正确性信心的最佳方式.代码覆盖率是我们关心的不可估量的质量的可测量近似值.

具有经验标准的一些特定情况可以增加价值:

• 满足利益相关者.对于许多项目,有许多对软件质量感兴趣的参与者可能不参与软件的日常开发(经理,技术主管等).说"我们要写所有的我们真正需要的测试"并不令人信服:他们要么需要完全信任,要么通过持续的密切监督来验证(假设他们甚至有技术理解这样做.)提供可衡量的标准并解释他们如何合理地接近实际目标更好.
• 规范团队行为.除了利益相关者之外,如果您正在一个多人编写代码和测试的团队中工作,那么对于"经过充分测试"的资格,存在模糊性的空间.您的所有同事对于什么级别的测试足够好有同样的想法吗？可能不是.你如何调和这个？找到一个您可以同意的指标,并将其作为合理的近似值接受.这在大型团队中尤其(但并非唯一)有用,例如,潜在客户可能无法直接监督初级开发人员.信任网络也很重要,但如果没有客观的衡量标准,即使每个人都善意地行事,集体行为也很容易变得不一致.
• 保持诚实.即使您是项目的唯一开发者和唯一的利益相关者,您也可能对软件有一定的品质.您可以使用代码覆盖率作为合理的近似值,让机器为您量身定做,而不是对软件的测试结果进行持续的主观评估(这需要工作).

要使用哪些指标

代码覆盖率不是单一指标; 有几种不同的测量覆盖率的方法.您可以设置哪一个标准取决于您使用该标准满足的要求.

我将使用两个常用指标作为您何时可以使用它们来设置标准的示例:

• 声明范围:测试期间执行了多少百分比的声明？有助于了解代码的物理覆盖范围:我编写了多少代码,我实际测试过了？
  • 这种覆盖支持较弱的正确性参数,但也更容易实现.如果你只是使用的代码覆盖,以确保这件事得到测试(而不是测试质量的超出了一个指标),那么语句覆盖可能就足够了.
• 分支覆盖:当存在分支逻辑(例如,a if)时,是否已对两个分支进行评估？这样可以更好地了解代码的逻辑覆盖范围:我测试过代码可能采用的路径有多少？
  • 这种覆盖范围是一个更好的指标,表明程序已在一系列综合输入中进行了测试.如果您使用代码覆盖率作为正确性置信度的最佳经验近似值,则应根据分支覆盖率或类似情况设置标准.

还有许多其他指标(行覆盖类似于语句覆盖,但是对于多行语句产生不同的数字结果;条件覆盖和路径覆盖类似于分支覆盖,但反映了更详细的可能排列的视图你可能遇到的程序执行.)

要求的百分比

最后,回到最初的问题:如果设置代码覆盖率标准,该数字应该是多少？

希望在这一点上很清楚我们正在谈论一个开始的近似,所以我们选择的任何数字都将是固有的近似值.

一些人可能选择的数字:

• 100%.您可以选择此选项,因为您希望确保所有内容都经过测试.这并没有给你任何关于测试质量的见解,但确实告诉你一些质量的测试已触及每个声明(或分支等).再次,这回到了信心程度:如果你的覆盖率低于100% ,您知道您的代码的某些子集未经测试.
  • 有些人可能认为这很愚蠢,你应该只测试代码中非常重要的部分.我认为你应该只维护代码中非常重要的部分.通过删除未经测试的代码也可以改善代码覆盖率.
• 99%(或95%,九十年代以来的其他数字.)适用于你想表达类似于 100%的置信水平的情况,但留下一些余地,不要担心偶尔难以测试的角落码.
• 80%.我已经看过几次这个号码,并不完全知道它的来源.我认为这可能是对80-20规则的一种奇怪的挪用; 通常,这里的目的是表明您的大多数代码都经过了测试.(是的,51%也会"最",但80%更能反映大多数人的意思.)这适用于"经过良好测试"不是高优先级的中间地区(你不喜欢)我想浪费在低价值测试上的努力),但是你仍然希望有一些标准.

我在实践中没有看到低于80%的数字,并且很难想象一个人会设置它们的情况.这些标准的作用是增加对正确性的信心,低于80%的数字并不是特别值得信赖.(是的,这是主观的,但同样,我们的想法是在设定标准时进行一次主观选择,然后再使用客观测量.)

其他说明

以上假设正确性是目标.代码覆盖仅仅是信息; 它可能与其他目标相关.例如,如果您担心可维护性,您可能会关心松耦合,这可以通过可测试性来证明,而可测试性又可以通过代码覆盖来测量(以某些方式).因此,您的代码覆盖率标准也为近似"可维护性"的质量提供了经验基础.

Answer 5

我最喜欢的代码覆盖率为100%带星号.星号是因为我更喜欢使用允许我将某些行标记为"不计数"的行的工具.如果我已经覆盖了100%的"计数"线,我就完成了.

基本过程是:

1. 我编写测试来练习我能想到的所有功能和边缘情况(通常使用文档).
2. 我运行代码覆盖工具
3. 我检查未覆盖的任何线路或路径以及我认为不重要或无法到达的任何线路或路径(由于防御性编程)我标记为不计
4. 如果没有提到这些边缘情况,我会编写新的测试来覆盖缺失的行并改进文档.

这样,如果我和我的合作者在未来添加新代码或更改测试,有一条明确的线路告诉我们,如果我们错过了重要的事情 - 覆盖率降至100%以下.但是,它还提供了处理不同测试优先级的灵活性.

Answer 6

我还有另外一个关于我想分享的测试报道的模式.

我们有一个庞大的项目,通过twitter,我注意到,通过700次单元测试,我们只有20%的代码覆盖率.

斯科特汉塞尔曼用智慧的话回答道:

它是正确的20%？是否代表用户最受欢迎的代码的20%？您可以添加50多个测试,仅添加2%.

再次,它可以追溯到我的Testivus代码覆盖率答案.你应该在锅里放多少米饭？这取决于.

Answer 7

对于一个设计良好的系统,单元测试从一开始就推动了开发,我认为85%是一个非常低的数字.设计为可测试的小班不应该难以覆盖.

通过以下方式解决这个问题很容易:

• 覆盖的线不等于测试逻辑,不应该读取百分比太多.

没错,但是有一些关于代码覆盖的要点.根据我的经验,如果使用正确,这个指标实际上非常有用.话虽如此,我还没有看到所有系统,我敢肯定有很多系统很难看到代码覆盖率分析增加任何实际价值.代码看起来如此不同,可用测试框架的范围可能会有所不同.

此外,我的推理主要涉及非常短的测试反馈循环.对于我正在开发的产品,最短的反馈回路非常灵活,涵盖了从类测试到进程间信令的所有内容.测试可交付的子产品通常需要5分钟,对于如此短的反馈循环,确实可以使用测试结果(特别是我们在此处查看的代码覆盖率指标)来拒绝或接受存储库中的提交.

使用代码覆盖率指标时,您不应仅具有必须满足的固定(任意)百分比.在我看来,这样做并没有给你代码覆盖率分析的真正好处.而是定义以下指标:

• 低水位标记(LWM),在被测系统中见过的最低数量的未覆盖线
• 高水位标记(HWM),是被测系统中有史以来最高的代码覆盖百分比

如果我们不超过LWM并且我们不低于HWM,则只能添加新代码.换句话说,不允许代码覆盖率降低,并且应该涵盖新代码.请注意我应该说和不应该(在下面解释).

但是,这是不是意味着不可能清除那些你再也没用过的旧的经过严格测试的垃圾了？是的,这就是为什么你必须对这些事情务实.在某些情况下,规则必须被打破,但对于典型的日常集成,我体验到这些指标非常有用.它们给出了以下两个含义.

• 推广可测试代码.添加新代码时,您必须努力使代码可测试,因为您必须尝试用测试用例覆盖所有代码.可测试代码通常是件好事.

• 遗留代码的测试范围随着时间的推移而增加.当添加新代码而无法用测试用例覆盖它时,可以尝试覆盖一些遗留代码,而不是绕过LWM规则.这种有时必要的作弊至少给出了积极的副作用,遗留代码的覆盖范围将随着时间的推移而增加,使得这些规则的看似严格的执行在实践中非常实用.

而且,如果反馈循环太长,在集成过程中设置这样的东西可能完全不切实际.

我还想提一下代码覆盖率指标的两个更广泛的好处.

• 代码覆盖率分析是动态代码分析的一部分(与静态代码分析相对,即Lint).在动态代码分析过程中发现的问题(通过purify系列等工具,http://www-03.ibm.com/software/products/en/rational-purify-family)就像未初始化的内存读取(UMR),内存泄漏等只有在执行的测试用例涵盖代码时才能找到这些问题.在测试用例中最难覆盖的代码通常是系统中的异常情况,但如果您希望系统正常失败(即错误跟踪而不是崩溃),您可能需要付出一些努力来覆盖异常情况在动态代码分析中也是如此.只是运气不好,UMR会导致段错或更糟.

• 人们为保持100%的新代码而感到自豪,人们讨论测试问题的热情与其他实现问题类似.如何以更可测试的方式编写此函数？你将如何试图掩盖这种异常情况等.

而且是否定的,完整性.

• 在一个涉及许多开发人员的大型项目中,每个人都不会成为测试天才.有些人倾向于使用代码覆盖率指标作为代码测试的证据,这与事实相差甚远,正如许多其他问题的答案所述.如果使用得当,它是一个可以为您提供一些好处的指标,但如果它被滥用,它实际上可能导致不良测试.除了上面提到的非常有价值的副作用之外,覆盖线仅显示被测系统可以达到某些输入数据的那一行,并且它可以在不挂起或崩溃的情况下执行.

Answer 8

如果这是一个完美的世界,100%的代码将由单元测试覆盖.然而,由于这不是一个完美的世界,这是你有时间的问题.因此,我建议减少对特定百分比的关注,并更多地关注关键领域.如果您的代码编写得很好(或至少是合理的传真),那么API应该有几个关键点,其中API会暴露给其他代码.

将测试工作集中在这些API上.确保API 1)记录良好,2)编写与文档匹配的测试用例.如果预期结果与文档不匹配,那么您的代码,文档或测试用例中都存在错误.所有这些都很好地审查.

祝好运!

Answer 9

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

Answer 10

很多商店都没有重视测试,所以如果你的价格高于零,至少会有一些价值升值 - 所以可以说非零也不错,因为许多商店仍然为零.

在.Net世界,人们经常引用80%的合理性.但是他们在解决方案层面说这个.我更倾向于在项目级别进行测量:如果您有Selenium等或者手动测试,30%可能适用于UI项目,数据层项目的20%可能没问题,但95%+可能对业务来说非常可行规则层,如果不是完全必要的话.因此,总体覆盖率可能是60%,但关键业务逻辑可能要高得多.

我也听过这个:渴望100%,你会达到80%; 但渴望80%,你会达到40%.

底线:应用80:20规则,让您的应用程序的错误计数指导您.

Answer 11

85%将是签入标准的良好起点.

我可能会根据运输标准选择各种更高的标准 - 取决于被测试的子系统/组件的重要性.

Answer 12

我更喜欢使用 BDD，它结合使用自动化验收测试、可能的其他集成测试和单元测试。对我来说，问题是整个自动化测试套件的目标覆盖率应该是多少。

除此之外，答案取决于您的方法、语言以及测试和覆盖工具。在 Ruby 或 Python 中进行 TDD 时，保持 100% 的覆盖率并不难，而且非常值得这样做。管理 100% 的覆盖率比管理 90% 左右的覆盖率要容易得多。也就是说，填补出现的覆盖差距（并且在做好 TDD 时，覆盖差距很少见，通常值得您花时间）比管理您没有抽出时间并错过覆盖范围的覆盖差距列表要容易得多由于您不断发现未覆盖的代码背景而导致回归。

答案还取决于您的项目的历史。我只发现上述内容对于从一开始就以这种方式管理的项目来说是实用的。我极大地提高了大型遗留项目的覆盖范围，并且这样做是值得的，但我从未发现返回并填补每个覆盖范围空白是可行的，因为旧的未经测试的代码还没有被充分理解，无法正确执行此操作，并且迅速地。