文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

最近我跟几个朋友在Twitter上聊天,重谈起了测试覆盖率的问题。我想了下,刚要准备好开始高谈阔论,我才记起来我之前在Python测试手册 中已经讨论过测试覆盖率的诸多缺陷 所以我就想,也许把部分摘录过来会比较好些。

从《Python测试手册》第九章节开始....

****

覆盖率并不是一切

你已经知道如何运行覆盖率报告了。但是不要想当然地认为越多的覆盖率就自然越好了。为了以为追求覆盖率却影响测试质量绝对是失败的最好配方了。

如何去做呢…

覆盖率报告可以提供良好的反馈。它们会告诉我们什么得到了测试,什么有没有。但是只是因为一行的代码得到了测试并不意味着它就做了所有它应该去做的事。

第 1 段(可获 1.64 积分)

你是否曾经在休息室里试图去吹嘘覆盖率的百分比分数? 为良好的覆盖率感到自豪并没有错,但是当因此而导致使用这些统计数字去比较不同的项目时,我们就是在误入歧途了。

它是怎么工作的…

覆盖率报告是应该结合他们所针对运行的代码上下文来阅读。这些报告给我们展示了什么被覆盖到了,而什么还没被覆盖到,但是这并不是说事情就完事了。相反的,事情才刚刚开始。我们需要看看什么被覆盖了,并且分析这些测试是如何适应系统的。

很显然一个模块如果有 0%的覆盖率,那就说明我们还有工作要做。 但是当我们有70%的覆盖率那又意味着什么呢?我们需要编写代码去追逐那剩余的30%吗?当然我们会的!但是关于如何看待这个问题,有两种不同学派的想法。一种是正确的,另一种是错误的:

第 2 段(可获 2 积分)
  • 第一种方式是,写针对那些明确没有被覆盖到的部分的测试,而要试图避免重复原来的那70%。也就是说,早已在其他测试中被覆盖的测试代码,是对资源的低效利用。
  • 第二种方式就是,写针对代码所期待处理但还没有被处理的的场景的测试。没有被覆盖的部分应该能够提示我们还有什么场景没有被测试到。

第二个是正确的方式。好了,我承认我以一种引领时尚的方式写了那些。但是关键是很容易找到有哪些没有被测试到,并且也很容易写出尽快缩小差距的测试来。

第 3 段(可获 1.58 积分)

还有更多…

Python 给我们提供了强大的能力,可以通过猴子补丁(monkey patch)、注入替代的方法,以及其他一些技巧来对未覆盖的代码进行练习。但是这是不是听起来有点可疑? 我们确实在给自己下了套,主要有以下几个风险:

  • 如果新的测试不是基于可靠的场景,那么它可能就会更加的脆弱。
  • 对算法的重大变更可能会需要完全重写相应的测试。
  • 曾经写过基于模拟的测试吗? 很有可能在模拟那些不存在的系统时,却仅仅测试了模拟的部分(译者注:就是说做无用功,毫无意义的事情)。
  • 尽管我们的测试中有一些(甚至大部分)可能质量都很好,但是那些低质量的测试却可能将我们整体的测试套件拉低了水准。
第 4 段(可获 1.5 积分)

如果我们做了一些影响到行数计算机制的事情的话,覆盖工具也许不会让我们从上面的一些战术中“脱身”。但是覆盖率工具是否计算代码行数,不应该成为我们决定测试质量的衡量标准。

相反的,我们应该仔细观察我们的测试,看它们是否在对我们真正要处理的用例进行练习。当我们只是在想办法获得更高覆盖率的时候,我们就会忘了我们的代码本来应该是做什么的了,那样就不好了。

那我们是不是就不要增加覆盖率了呢?

第 5 段(可获 1.33 积分)

我们应该通过改进我们的测试,覆盖更多的场景,并删除不再支持的代码来增加覆盖率。这些事情都能使我们获得更好的质量。

单纯为了覆盖率而增加覆盖率并不会提高我们系统的质量。

但是我想炫耀一下我的系统的覆盖率!

我认为因拥有良好的覆盖率而庆祝是没问题的。与你的经理分享覆盖率报告也是可以的。但不要让它消耗你。

如果你开始每周都要发布覆盖率报告,先仔细检查你的动机。同样,如果你的经理要求发布该报告,你也要同样这样做。

第 6 段(可获 1.3 积分)

如果你试图对比你的系统和其他系统的覆盖率有什么不同,那么就要注意了!除非你同时熟悉两个系统的代码并且真正明白报告的底线, 否则你可能就是在危险的领域里徘徊了。你可能会陷入错误的竞争中,从而导致你的团队写出脆弱的测试来。

****

你的观点是同意还是不同意呢?请在评论区,自由的发表您对关于测试覆盖率报告中的优缺点的看法吧。

第 7 段(可获 1.04 积分)

文章评论