怎么保证测试覆盖率是够的？

我从两个维度保证覆盖：需求维度建需求-用例追踪矩阵，每条需求都有用例对应，双向可查；代码维度用增量覆盖率做参考，新代码必须达到阈值。另外用线上缺陷回溯——每个逃逸缺陷反推漏测原因补用例；再加探索性测试补脚本覆盖不到的盲区。覆盖率是手段，拦截风险才是目的。

我的实践组合：需求覆盖率用矩阵管理，评审时逐条勾对；自动化覆盖率卡在新增与变更代码，防止边改边漏；场景覆盖率靠用户行为数据——把埋点里的高频路径转化为主链路用例优先保障；最后是缺陷逃逸率作为结果指标倒逼改进。某次大版本靠这个组合把逃逸缺陷从 11 个降到 2 个。

『够』的定义我用风险量化回答：识别高风险区——资金、数据一致性、历史重灾区模块，这些做到边界异常全覆盖；低风险区正向覆盖即可。覆盖率指标我谨慎使用——代码覆盖率会催生为凑数的无效断言，需求覆盖率可能掩盖需求本身的坑。真正的信心来自三层：结构化覆盖、变更影响分析、生产反馈闭环。

追问『覆盖率 100% 好不好』：不可行也不必要——覆盖率高不代表断言有效，无断言的调用也算覆盖；『怎么测需求文档没写的行为』：探索性测试加与产品的澄清记录，把隐含预期显性化；『历史没覆盖的老代码怎么办』：按变更触碰逐步补，配合重构加特征测试，不搞运动式补测。