Bug 管理与缺陷分析教程

缺陷来自实际与预期的差异

当退款页面提示“成功”，但退款单仍为处理中，你需要先找到明确预期，再确认环境、数据和操作是否有效。没有依据时先记录疑问，不要把个人偏好直接写成 Bug。

先区分问题来源

重复支付缺陷报告

可执行步骤

1. 从干净数据开始再复现一次。
2. 压缩到仍能触发问题的最少步骤。
3. 用“当……时，……”写标题。
4. 分别记录预期和实际，不写原因猜测。
5. 附上可搜索的业务 ID 和时间。

响应证据怎么解释

支付接口返回 HTTP 200，只能说明服务正常处理了请求；还要检查业务码、支付单状态和是否发生扣款。HTTP 成功与业务成功必须分开记录。

商城缺陷分级

退回时写清原因

• 无法复现：补充缺失环境和数据，并约定再次验证。
• 重复缺陷：关联原缺陷，保留新场景证据。
• 按设计：引用已确认规则；若规则不合理转产品问题。
• 延期处理：记录风险接受人、目标版本和临时措施。

退款失败的定位顺序

1. 确认页面是否发出退款请求。
2. 检查金额、订单号与幂等键。
3. 区分 HTTP 失败和业务拒绝。
4. 用 request_id 查服务日志与下游响应。
5. 核对订单、支付单、退款单和消息。
6. 基于证据标记产品、代码、数据或环境问题。

定位型用例

• 当订单不属于当前用户时，退款请求被拒绝且订单数据不变。
• 当相同幂等键重复提交时，只存在一笔有效退款单。
• 当支付渠道超时时，退款保持可恢复状态并可被补偿任务处理。

关闭前检查

• 原缺陷稳定通过
• 相邻路径没有回归
• 数据与日志结果一致
• 修复版本和证据已记录

五问示例

1. 为什么重复退款？重复回调被再次执行。
2. 为什么会再次执行？服务没有持久化幂等结果。
3. 为什么没有设计？接口评审没有异常重试项。
4. 为什么评审漏掉？模板只覆盖正常流程。
5. 如何预防？增加幂等设计清单、自动化用例与重复退款告警。

把单个缺陷沉淀成可复用模式

AI 可以辅助复盘，但不能替开发确认根因

• AI 适合聚类相似缺陷、起草 5 Whys 和识别可能的可拦截环节。
• 推测根因必须标注待确认，与开发核对后才进入正式报告。
• 改进项需要负责人、期限和验收标准，不能停在“加强自测”。
• 验证有效的模式回填回归检查点库，下个版本继续检查是否复发。

练习：支付成功但订单仍待支付

1. 写一条“当……时，……”格式的缺陷标题。
2. 补齐环境、前置、步骤、实际、预期和证据。
3. 判断严重程度与优先级并说明理由。
4. 列出页面、请求、日志和数据的取证项。
5. 设计原缺陷、同类场景和相邻功能回归。
6. 用五问法给出可验证的预防动作。