覆盖率数字别拿来当目标，盖到的地方才是真底气
覆盖率是个容易骗人的指标，冲数字凑出来的测试盖了行没盖心。盖了行的人以为稳了，稳了的系统一改就挂，挂了才知那些行从没被真正触发过，触发条件根本没测。一、数字别当目标
覆盖率数字别拿来当目标，盖到的地方才是真底气。当目标就有人凑，凑出来的数字好看，好看的背后是大量无断言的空壳用例，空壳一遇真改动全露馅。覆盖率报告进看板，进看板了团队天天见，见多了才上心。测试先覆盖主干路径，主干稳了边角出问题影响也有限，有限才好救。
露馅的表现是改一处红一片，红一片让人不敢动，不敢动就绕，绕出更绕的实现。实现越绕越难测，难测覆盖率又掉，掉下去再凑，凑绕循环越滚越大。覆盖率数字别当目标，冲数字凑出来的测试盖了行没盖心。债务影响要评估，评估清楚了优先还那笔会炸的，炸了比别的更麻烦。
二、关键路径比数字重要
数字高但关键分支没测，高数字像纸糊的墙，墙一推就倒，倒了关键功能先挂，挂了用户直接走。测试价值讲给业务听，业务懂了才肯给写测试的时间。测试用例要能跑快，跑得慢大家就不爱跑，不跑等于没写。
关键路径怎么定，定在出错代价高的地方，代价高的多花力气测。力气花在刀刃上，刀刃稳了边界处偶发错也撑得住，撑得住的系统才经得起折腾，折腾多了不崩。关键路径覆盖要比数字重要，重要处稳了整体才敢动。新人别一上来填坑，填坑前先有人带，带过才不越填越乱。
三、没覆盖的标出来
有底才敢动那块，敢动才能逐步补，补一块少一块盲区，盲区少了出事概率降，降了线上才安宁。覆盖率不是越高越好，到边际价值骤降那点就可以收手。测试数据要可控，可控了同一用例每次结果一致，一致了才好信。
标出来还要定期回顾，回顾看盲区是不是在缩小，缩小了说明在进步。进步给人信心，信心足了团队愿意投入补测试，投入形成习惯，习惯让覆盖率自然涨，涨得结实。没覆盖的地方标出来，标出来的人下次改它心里有底。还债前后比一比，比了能证明值不值，值了下回才好申请时间。
四、掉了要报警
拆了没人知，知的还是用户，用户踩了才回查，回查发现是某次重构顺手删了用例，用例删了防护没了。债务记一笔台账，记了才知欠多少，知了还的时候有次序。改完代码先跑测试，跑过了再提，提了才不把毛病传给别人。
报警要指到具体模块，指到模块负责人才能行动，行动快地补回。补回慢了期间又改，改叠加在缺防护的状态上，状态越缺越不敢动，不敢动债务堆高。覆盖率掉了要报警，报警了才知道哪次提交把防护拆了。债务原因要复盘，复盘出的根因不改，旧债还了新债又生。
五、分支比行难
缺陷藏在没走到的分支，分支走到才暴露，暴露的问题若是边界，边界错算的结果差之千里。还债排进迭代，排进了才不会被新功能永远挤掉，挤掉就烂。测试别依赖顺序，依赖顺序的一换环境就红，红得莫名其妙。
难的就更要测，测了分支才敢说稳，稳了重构不慌，不慌大胆改，改完跑一遍分支全绿，全绿的底气来自真的走过，走过不是数字堆出来的假象。分支覆盖比行覆盖更难，难处正是容易藏逻辑缺陷的地方。关键模块债务优先清，清了那块才敢大改，大改才不被绊。
六、不是越高越好
收手不是放弃，是性价比到了拐点，拐点到处硬凑反而拖慢，拖慢开发节奏，节奏乱了需求压过来慌。临时方案打标记，打标了谁都知这是权宜，权宜迟早要还。边界条件单独写用例，写上的那个极端值往往藏着难发现的坑。
收手后把精力转防御性测试，防御性的用例更抗变，抗变的测试在重构里活得久，活得久才持续有价值，价值不靠一次覆盖数字，数字会骗人用例不骗。历史低覆盖模块排计划，排了才一步步把坑填平，不平总绊脚。债务看板对老板可见，可见了要资源时才拿得出理由。
覆盖率是体检报告，报告看趋势和盲区，不看单点数字。趋势、关键、盲区、报警、分支、拐点，六件事看明白，覆盖率才是指南针，不是用来邀功的奖牌。 支持理性讨论，反对无脑争吵，楼主带了个很好的头。 楼主分析得很到位，很多地方都很实用，已经默默收藏起来慢慢看。 虽然篇幅不长，但句句都是重点，简洁又有深度，非常不错。 内容真实不做作，没有多余套路，都是实实在在的经验之谈。
页:
[1]