我很好奇是否有关于代码覆盖率是否真的提高了代码质量的度量标准?有调查研究吗?
如果是这样的话,它以多大的百分比变成了收益递减的情况?
如果不是,为什么这么多人把它当作一种宗教教义?
我的怀疑是轶事,是由我参与的两个项目带来的,这两个项目都实现了相同的相当复杂的产品。第一个只是到处使用目标单元测试。第二种是强制70%的代码覆盖率。如果我比较缺陷的数量,第二个缺陷几乎有一个数量级以上。这两种产品都使用了不同的技术,拥有不同的开发人员,但我还是感到惊讶。
发布于 2016-11-15 10:43:58
我假设您是指单元测试上下文中的代码覆盖度量。如果是这样的话,我认为你已经间接地回答了你的问题:
第一个项目只是到处使用目标单元测试。第二种是强制70%的代码覆盖率。如果我比较缺陷的数量,第二个缺陷几乎有一个数量级以上。
简而言之,代码覆盖度量根本不能提高项目的质量。
还有一种普遍的信念,即代码覆盖反映了单元测试的质量,但它没有,它也没有给您一个信息,您的系统的哪些部分进行了适当的测试。它只说明您的测试套件执行了哪些代码。可以肯定的是,代码覆盖率只为您提供了系统中哪些部分未被测试的信息。
但是,如果您确信单元测试的质量,代码覆盖率度量可能与总体代码质量相关。单元测试的质量可以定义为能够检测到代码库中违反某些业务需求的更改的能力。换句话说,每一项违反特定要求的更改(验收标准)都应该通过高质量的测试来检测(这类测试应该简单地失败)。衡量测试套件质量的最简单和自动化的方法之一是突变测试,它不需要您方付出太多额外的努力。
http://martinfowler.com/bliki/TestCoverage.html
发布于 2016-11-15 09:24:13
代码覆盖率告诉您测试覆盖了多少代码。它并没有告诉你太多关于测试的质量。例如,70%的代码覆盖率可能是通过自动测试来获得的,这些测试使用的是getter和setter这样的简单功能,而忽略了更重要的内容,比如验证某些复杂的计算是否提供了正确的结果、角的情况等等。即使您有100%的代码覆盖率,您的测试也不会考虑对代码的特殊输入,从而导致代码失败。因此,相对较高的代码覆盖率并不一定意味着代码经过了良好的测试,因此重要的缺陷仍可能无法被测试检测到。
另一方面,代码覆盖率低意味着许多代码根本没有经过测试,因此一些重要的模块可能没有得到正确的验证。有时,自动化测试的代码覆盖率相对较低是有意义的,例如,单击GUI按钮并验证适当的对话框打开(手动测试)比编写相应的自动测试更有效。然而,即使在这种情况下,自动化测试和手动测试的综合覆盖率也会很高。
因此,仅靠IMO代码覆盖并不能很好地反映测试的质量,因为它只能朝一个方向工作:
感谢小虫向我指出了手工测试的代码覆盖率。
发布于 2016-11-15 09:38:50
代码覆盖率可能会有所帮助,但其本身并不是一个很好的指标。
它的帮助之处在于它迫使人们有意识地使用代码来编写提供这种覆盖率的测试,这可能会导致他们发现潜在的问题并修复它们。
但是,如果这样做的人实际上对代码不感兴趣,他们可以机械地构建涵盖所有内容的测试代码,而不必费心地考虑代码到底做了什么,如果这是正确的。
因此,它可能导致一种虚假的安全感。但是,如果团队有适当的动机,并且对交付质量感兴趣,那么这是帮助团队发现代码中可疑和需要检查的潜在问题的好方法。
仅仅计算覆盖行是不够的,您还需要分支覆盖,例如,通过条件语句或所有可能的结果测试不同的路径。
https://softwareengineering.stackexchange.com/questions/336081
复制相似问题