测试造假源于目标错位，需以服务质量为导向；识别空壳测试、实现绑定测试、路径堆砌测试三类信号；通过CI管控、风险标注、命名契约、僵尸清理及真实故障注入等机制防伪。
别让测试变成“走形式”的代码表演
覆盖率造假不是技术问题，而是目标错位的结果。当团队把“80% 覆盖率”当成上线门槛，而不是“关键路径是否被真实验证”的判断依据时，测试就容易滑向空跑、无断言、强耦合实现的无效状态。防范的核心，是把指标拉回服务质量的轨道，而不是让它成为考核的替代品。
识别三类典型造假信号
这些写法在报告里能刷高数字，但对发现 Bug 几乎没用：
-
空壳测试（no assertion）：只调用函数，不检查返回值或副作用。例如
calculateTotal(items)被调了，但没验证结果是否等于预期，甚至没传边界数据（空数组、null、超大数） - 实现绑定测试（test implementation, not behavior）：断言组件内部 state、mock 私有方法调用次数、校验 hook 的执行顺序。一旦用 useState 替代 class state 或重构为自定义 Hook，测试立刻失效，但功能完全正常
-
路径堆砌测试（coverage padding）：为覆盖
if (x && y || z)硬写 4 个组合用例，却漏掉真正影响业务的场景——比如y是 API 错误码，但所有测试都用 mock.success()，从不模拟网络失败
用机制代替自觉：落地级防伪策略
靠开发者自律很难持续，需嵌入流程和工具：
- CI 中禁止单独提升覆盖率阈值：不接受“本次 PR 覆盖率 +0.5%”作为合入理由；要求每次新增覆盖率，必须附带对应业务场景说明（如：“补了支付失败重试逻辑的分支覆盖，对应订单页‘重试按钮点击后状态更新’”）
- 报告中强制标记“高风险低覆盖区”：用 nyc 配置自动突出导出函数、事件处理器、catch 块、默认 case 等位置的未覆盖语句；这些地方标红，比整文件平均值更值得优先处理
-
测试命名即契约：强制采用“被测对象 + 场景 + 预期结果”三段式（如
it('Counter component increments count when increment button is clicked, showing updated value in DOM'）。名称读起来不像需求描述的，直接驳回 -
定期清理“僵尸测试”：每季度运行
nyc check-coverage --functions 0找出零调用函数，grep 全局确认是否真废弃；对长期未修改、但测试全绿的模块，抽样人工走查——常会发现测试只是在“模拟调用”，并未验证行为
用真实反馈校准测试价值
最有力的防伪手段，是让测试缺陷暴露得更快：
- 把线上错误日志中的堆栈路径，反向映射到本地覆盖率报告，看对应行是否被测过。如果高频报错点常年红色，说明测试覆盖与实际风险严重脱节
- 在测试中主动注入故障：比如用
jest.mock('axios', () => ({ get: jest.fn().mockRejectedValue(new Error('timeout')) }))，强制走错误分支，并验证 UI 是否正确显示提示——这类测试天然难造假，因为要写出合理预期 - 对核心流程（如登录、下单、支付）做端到端快照测试，对比渲染结果。若单元测试覆盖率 95% 但快照测试一跑就崩，说明单元层的“覆盖”根本没守住真实行为
