测试与排错：把主流程守住

早期产品不需要追求测试覆盖率数字，但必须保护那条产生用户价值和收入的主路径。

测试的目标不是证明"代码没有问题"，而是让问题出现时能稳定复现、快速定位、确认没有再犯。

先写关键旅程

把主路径写成用户动作：

1. 新用户打开页面
2. 注册或登录
3. 提交一种有效输入
4. 系统完成处理并展示结果
5. 用户创建订单并付款
6. 账号获得正确权益
7. 用户再次登录仍能访问结果

第七步最常被漏掉。 前六步都测了、第七步没测，结果是用户付了钱、第二天登录进来什么都看不到——这是最伤的一类 bug。

这条旅程至少保留一个自动化冒烟测试，或者一份每次发布都执行的人工清单。

分三层测试

• 规则测试：价格计算、权限判断、状态转换等纯逻辑
• 接口测试：数据库、支付回调、邮件和第三方服务的连接边界
• 旅程测试：从浏览器走完用户真正关心的完整流程

不要用大量组件快照代替业务测试。页面颜色不变，订单状态仍然可能错。

第一版的投入顺序：先写规则测试（最便宜、最稳定），再补一个旅程测试（最值钱），接口测试按出过事故的地方补。

涉及钱的地方优先写测试

如果时间只够写五个测试，全部给这些场景：

这五个都是"出一次就要人工补单"的问题。 补单的时间成本远高于写测试。

每个问题先变成复现步骤

一个可处理的问题记录应包含：

环境：生产 / 本地，浏览器和账号状态
前置：用户有什么数据或权益
步骤：依次做了什么
实际：看到了什么状态和错误编号
预期：应该发生什么
频率：必现、偶发，还是只出现一次

不能复现时，先补日志和上下文，不要凭感觉改代码。

凭感觉改的问题在于：如果它本来是偶发的，改完之后没再出现，你无法判断是修好了还是碰巧没触发。

"频率"这一行决定处理方式。必现的问题好办，偶发的问题往往和并发、缓存或时序有关，值得多花时间找到确切条件。

用二分法缩小范围

排错时依次判断：

• 请求有没有到达服务端
• 参数是否正确、身份是否存在
• 数据库读写是否成功
• 第三方接口是否收到并返回
• 状态是否正确保存
• 前端是否展示了保存后的真实状态

一次只改变一个变量。 连续改五处再测试，即使成功也不知道真正原因——而且你可能同时引入了一个新问题，只是它还没显现。

让 AI 帮排错的正确方式

给它三样东西：复现步骤、实际的错误输出、相关代码。

只说"这个功能不工作"会得到一堆猜测。给了这三样，它通常能直接指出位置。

一条实用做法：先让它列出三个可能原因和各自的验证方法，你验证完再让它改。 直接让它改，它会同时改掉三个地方，你不知道哪个是真原因。

修复必须带回归证据

每次修复至少留下一个东西：

• 一个自动化测试
• 一条明确的发布检查项
• 一条能识别同类问题的监控规则
• 一段解释根因和触发条件的记录

否则同类问题只是暂时消失，不是被系统性解决。

第四条的价值容易被低估。根因记录能让你发现同一类错误在别处也存在——修了一个地方的空值判断，往往意味着还有三个地方有同样的问题。

线上问题的响应流程见监控与故障处理。

常见错误

只测到"付款成功"，不测第二天登录还能不能看到。 最伤的一类 bug。

用组件快照代替业务测试。 颜色不变，订单状态照样能错。

问题不能复现就凭感觉改。 改完没复现，你不知道是修好还是没触发。

一次改五处再测。 成功了也不知道原因。

页面数据不对就先改前端。 可能请求根本没发出去。

让 AI 直接改，不先让它列可能原因。 它会同时改三处。

修完不留回归证据。 同类问题只是暂时消失。

验收标准

• 主路径七步都被走过，包括"第二天再登录"
• 涉及钱的五个场景都有测试或明确的人工检查项
• 每个 bug 记录都有环境、步骤、实际、预期、频率
• 排错时一次只改一个变量
• 每次修复都留下了测试、检查项、监控规则或根因记录之一
• 有一份发布前必跑的清单，人工执行也行

本章动作

选择最值钱的一条用户旅程，为正常、失败、重复提交、未登录四种情况各写一个测试。

在下一次发布前全部执行一遍。

下一步

1. 监控与故障处理——上线后的问题发现机制
2. 发布与回滚——发布清单放在哪
3. AI 功能的质量、成本与兜底——AI 结果的另一套验收方式