为什么那么看重代码覆盖率？

                                                                                                                                                <p style="color:#252b3a; margin-left:0px !important; margin-right:0px !important; text-align:start">大家好，我是陈哥。</p> 

我看到有不少读者给我留言吐槽代码覆盖率很像自欺欺人的数字游戏，低了怕影响质量，高了又怕陷入“为了覆盖而覆盖”的无效内卷。明明功能测得差不多了，为啥非要揪着这个百分比不放？

今天，我们就一起谈谈为什么那么看重代码覆盖率。

一、测试人员的经验和责任没法量化

很多人觉得，测试用例写得够不够，全靠测试人员的经验和责任心。这话没错，但经验和责任心是主观的，没办法量化。

你说你测得全，怎么证明？你说这个功能没问题，依据在哪？这时候，代码覆盖率就是最客观的标尺。

代码覆盖率，简单说就是你的测试用例到底执行了多少行代码。

比如一段100行的代码，测试用例跑下来，只执行了60行，那覆盖率就是60%。剩下的40行，就是测试的盲区。这些盲区里，可能藏着边界条件、异常场景，甚至是逻辑错误。

有人说，覆盖率高不代表代码质量好。这话是对的，但反过来想，覆盖率低的代码，质量就会好了吗？覆盖率就像考试的及格线，考60分不一定学习好，但连60分都考不到，肯定算不上合格。

对于团队而言，并不需要靠覆盖率来证明代码完美，只需要用它来判断测试有没有做到位。至少，能让我们把看得见的漏洞先补上。

二、提高代码覆盖率不是测试一个人的事

现在很多团队都在推敏捷开发，讲究快速迭代、小步快跑。但快不等于乱，迭代不等于敷衍。

我发现一个很有意思的现象：重视代码覆盖率的团队，研发流程往往更规范；反之，流程混乱的团队，覆盖率通常也低得可怜。

为什么会这样？因为要提高代码覆盖率，不是测试一个人的事，而是需要开发和测试的配合。

开发写代码的时候，要考虑可测试性，不能写一堆耦合度高、逻辑混乱的代码，否则测试根本没办法设计用例。测试设计用例的时候，要对照着代码逻辑，把每个分支、每个条件都覆盖到，不能只测主流程。

举个例子，我们团队以前开发新功能，都是开发写完就扔给测试，测试发现Bug就打回去。

后来我们规定，所有新功能提交前，开发必须先做单元测试。这么做了之后，我们团队的效率明显提升，测试环节反馈的低级 Bug 数有所下降，来回返工的时间大幅减少。大家能把精力集中在核心功能打磨上，版本上线的稳定性也跟着提高。

因为开发在写单元测试的时候，其实是在自己检查代码逻辑。

很多低级错误，比如变量名写错、条件判断颠倒，在这个阶段就被发现了，根本轮不到测试去提Bug。而且，单元测试写得好，后续集成测试和系统测试的效率也会提高。

这就是覆盖率的价值，它能逼着整个研发流程往更规范的方向走。

三、代码覆盖率降低长期维护成本

很多人算不清一笔账：觉得花时间提高覆盖率，是增加了研发成本。

但他们忘了，线上Bug的修复成本，是研发阶段的几十倍甚至上百倍。

一个小Bug，研发阶段改可能只需要1小时，到了测试阶段可能需要1天，到了线上，可能需要一个团队折腾好几天，还要面对用户投诉、数据回滚、赔偿损失等一堆麻烦事。

而重视覆盖率的团队，虽然在研发阶段多花了一点时间，但长期来看，维护成本会大大降低。

因为覆盖率高的代码，意味着测试更充分，潜在的Bug 更少。后续迭代的时候，开发可以放心地修改代码，不用担心改了这一处，会触发另一处的隐藏Bug。

当然，我也不是说覆盖率越高越好。有人追求100%的覆盖率，为了覆盖一行无关紧要的代码，写一堆复杂的测试用例，这就是走向极端了。

测试代码覆盖率更像是一种研发态度，代表着团队对代码质量和用户的负责。

我见过太多因为偷工减料而付出的代价，也正是因为这些经历，我才一直坚持在代码质量这件事上，容不得半点马虎。

                                                                                </div>

Source link