北京
凌晨两点，一条报警短信把开发团队从床上拽起来。打开仪表盘一看，代码覆盖率稳稳停在90%，该跑的单测都跑通了。挖了四十分钟，罪魁祸首藏在没被踏过的else分支里——测试全走了一条路，另一条路连灯都没开过。
代码覆盖率这玩意儿，团队里天天念叨，但真把它用透的没几个。它量的是测试期间有多少代码被真正执行过。如果你的库里有一千行可执行代码，跑完测试触达了九百行，那行覆盖率就是90%。它是一个运行时指标，只跟踪实际运行的路径，跟代码本身长得有多危险毫无关系。跟它搭班子的静态代码分析，擅长在不执行的情况下挑出复杂度、风格、安全气味这些毛病。一个告诉你哪里可能埋着雷，另一个告诉你测试到底有没有踩到那片区域。
这里容易混淆的是“代码覆盖率”和“测试覆盖率”。很多人口中的测试覆盖率，更像是在问：我把要验证的行为都测到了没有。而代码覆盖率只管一个冰冷的数字百分之多少的语句被执行过。一个支付模块，用五个正常流程的用例可能把行覆盖率推到95%，但如果没测余额为负时怎么优雅报错，那行为层面的测试覆盖就是漏的。
光盯着行覆盖率会骗人。绝大多数工具把行覆盖率和语句覆盖率捏成一个百分比，看起来清爽，却藏住了分支、路径这些更细的盲区。假设有个判断 if (a > 0 && b > 0)，你只用一个 foo(1,1) 的用例跑过去，每一行都亮了——但 else 分支上的逻辑根本没被碰过。行覆盖率满分，分支覆盖却开了天窗。所以真正有意义的做法不是追着所有指标跑，而是挑几个核心指标死磕，比如行覆盖打个底，分支覆盖查缺口，再结合函数覆盖看哪些模块压根没被测试挂上。
那怎么把力气花在值得测的地方？可以先从认证模块、数据访问层、错误处理这些命门入手。代码覆盖率最常见的价值就是揪出那些从来没跑过的路径和边缘条件，这些地方恰恰是回归缺陷和安全漏洞最爱的藏身处。与其凑一个漂亮的全量数字，不如让关键链路做到“每个分支都有你测过的痕迹”。
下次再看覆盖率面板，别只盯着那个百分数点头。问一句：剩下那一点点没覆盖的，到底长在哪些 if 的后半段？那才可能是下一次凌晨报警的起点。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
