从实际场景入手，补全常见分支
很多团队发现测试跑不过，问题出在只测了“正常流程”。比如用户注册功能，只测了正确填表提交，却忽略了手机号格式错误、验证码过期、重复注册这些情况。把这些真实使用中容易发生的分支补上用例，覆盖率自然就上来了。
写测试时可以问自己：用户会怎么“搞事情”？把边界值、异常输入列出来，逐个覆盖，比盲目堆用例更有效。
利用工具快速定位盲区
像 Jest、JaCoCo 这类工具能生成覆盖率报告，直接标出哪些行没被执行。打开 HTML 报告，一眼就能看到红色高亮的代码块。点进去看看，往往是某个 if 条件少测了一个分支。
有个团队发现一段权限判断逻辑始终没覆盖，查了一下才发现测试里一直用管理员账号跑，根本走不到普通用户的逻辑。换了个角色再跑，立刻补上了漏掉的路径。
优先覆盖核心链路，别贪全
刚接手老项目时，别想着一口气干到 90% 以上。先挑主流程下手，比如下单、支付、发布内容这类关键操作。把这些链路的主干和主要异常路径测全，既能提升质量，也能快速拉高整体数字。
有个开发者分享经验：他先把购物车结算流程的测试补全，覆盖率一下子从 45% 提到 68%，上线后用户投诉少了近三成。
善用 Mock 拆解依赖
有些代码依赖外部服务，比如发短信、调支付接口。真去调一遍不仅慢，还难控制结果。这时候用 Mock 把依赖替换成可控的假对象，就能精准测试各种返回情况。
jest.mock('./api/sms', () => ({
sendCode: jest.fn().mockResolvedValue({ success: false, msg: '发送频繁' })
}));
// 这样就能测“短信发送失败”分支，不用真去触发接口小改动带动大提升
有时候加一行断言，就能让一个函数的覆盖率从 70% 跳到 100%。比如某个工具函数返回布尔值，测试里只验证了 true，补上 false 的 case 就齐了。
与其花时间写一堆边缘用例，不如先扫一遍已有测试，看有没有明显缺口。这种“捡漏式”补充，投入少见效快。
把覆盖率检查嵌入日常流程
在 CI 流程里加上覆盖率门槛，比如不允许 PR 降低总体覆盖。一开始可能觉得麻烦，但时间久了，大家写代码会下意识带上测试。
有团队在 Git 提交前自动跑本地覆盖率，差得太多就提醒“先补两行测试吧”，慢慢就成了习惯。工具是手段，关键是把“要我测”变成“我要测”。