全绿的单测可能测的不是那条链路

更新于 2026-09-22

**测试绿了但真实 bug 还在，通常不是"测试没覆盖到"，而是"测试覆盖的是另一条链路"。判定方式：把测试里构造的输入形状，和真实故障时的输入形状逐项对照 —— 差在哪一项，就是没被覆盖的那条路。**

一次实例

修复"流式回答卡死"时，单测只覆盖了：

  • 「收到 terminal 后 EOF 报错」
  • scheduler（调度）行为

而真实故障链是：长工具结果 + 长 Markdown + React 状态更新同时存在。于是单测全绿，真实 bug 仍在。

同类第二例：worker 找到了一个可稳定复现的 bug（terminal 后 transport error 覆盖完成态），但它没有取得原事故的浏览器 body-read error telemetry，也没做真实浏览器验收；用户修复后又复现了卡死 —— 说明这个诊断最多覆盖一条故障路径，不是"经常卡死"的完整根因。所以 Issue 退回 In Progress 是正确的：修了一个真实 bug ≠ 修好了用户报的问题。

可迁移的判断

  • 绿灯的证明范围 = 测试构造的输入形状。要把结论扩展到真实场景，必须先证明输入形状一致。
  • 复现出一个 bug 之后，要问的是"这是用户那次的那条路径吗"，而不是"我修好了 bug 吗"。
  • 缺 telemetry 时不要二选一定根因（帧没到 / 前端丢弃 / 主线程阻塞），先补日志记录真实 event/seq 与状态迁移，再改。

相关

  • 测试策略 —— 主题聚合页：分层测试的分工
  • 通过只证明它实际驱动的路径 —— 本条是该 synthesis 的第一处证据：绿灯的证明范围 = 被驱动的那条路
  • 合并绿灯要对应当前HEAD —— 同一族：绿灯的证明范围有前提
  • 经验沉淀要在问题验证后按需触发 —— 未经验证的结论不该当成果沉淀
  • 假成功要有真失败信号
  • 验收要按唯一标识选中实例