Bug Reporting

缺陷报告（Bug Reporting）

参考来源：Cem Kaner《Lessons Learned in Software Testing》、Google Bug Tracking Best Practices、ISTQB Foundation。

适用场景

• 测试中发现 Bug 需要记录
• Bug 复现 / 跟踪 / 验证
• Bug 严重度和优先级评估
• Bug 根因分析（与开发协作）
• Bug 沉淀为回归用例

核心原则

1. Bug 报告是给开发看的
   开发能 5 分钟内复现 = 好报告

2. 标题 = 模块 + 现象 + 关键条件
   "登录失败" 是垃圾标题

3. 最小复现路径
   去掉无关步骤，留必要的

4. 预期 vs 实际明确
   不能让开发猜你想要什么

5. 严重度 × 优先级 分开
   严重度 = 影响大小（QA 判）
   优先级 = 修复紧迫度（PM 判）

6. 复现率必须说
   "偶发" / "100% 复现" 信息量天差地别

好 Bug 标题 vs 坏 Bug 标题

复现步骤（最小化）

原则：删一步还能复现，就再删

❌ 长流程：
  1. 注册账号
  2. 登录
  3. 充值 100
  4. 浏览商品
  5. 加入购物车
  6. 结算
  7. 支付
  8. 退款 → 出问题

✅ 最小：
  前置：已存在状态=paid 的订单 ORD-123
  1. POST /orders/ORD-123/refund {"amount": -100}
  2. 观察响应

必备字段（Cem Kaner 模型）

1. 标题（含模块 + 现象 + 条件）
2. 环境（版本 / 浏览器 / 设备 / 数据库）
3. 账号（角色 / 租户 / 测试账号）
4. 前置条件（最小数据准备）
5. 复现步骤（编号清晰）
6. 预期结果
7. 实际结果
8. 截图 / 录屏 / 日志 / trace_id
9. 严重度 + 优先级
10. 复现率（100% / 50% / 偶发）
11. 影响范围（用户 / 功能 / 环境）
12. 是否需要立即缓解

严重度（Severity）

优先级（Priority）

注意：S 和 P 不必相同。例如：S3 文案错但出现在落地页 → P0 立即修。

Bug 生命周期（ISTQB）

New（新建）
  ↓
Assigned（分配）
  ↓
In Progress（修复中）
  ↓
Fixed（已修复）
  ↓
Verified（QA 验证通过）
  ↓
Closed（关闭）

或：
  ↓
Reopened（验证失败，重新打开）
  ↓
（回到 In Progress）

或：
  ↓
Wont Fix / Duplicate / Cannot Reproduce

状态转换规则

QA 操作：New / Verified / Closed / Reopened
Dev 操作：Assigned / In Progress / Fixed / Wont Fix
PM 操作：调整优先级 / Wont Fix 决策 / 关闭

报告 Bug 的工作流程

1. 发现现象
   - 当前操作 / 数据 / 环境
   ↓
2. 尝试最小复现
   - 删步骤直到不能复现
   ↓
3. 收集证据
   - 截图 / 录屏 / 日志 / trace_id / cURL
   ↓
4. 评估影响
   - 严重度 / 复现率 / 影响范围
   ↓
5. 写报告
   - 标题 + 复现 + 预期 + 实际 + 证据
   ↓
6. 标定优先级
   - 与 PM 沟通
   ↓
7. 紧急的报告先短信 / 群里说
   - S0 / P0 不能只靠 ticket
   ↓
8. 修复后验证
   - 原路径 + 边界 + 回归套件
   ↓
9. 转化为回归用例
   - 见 regression-testing
   ↓
10. 沉淀经验
    - 同类问题的根因 → field-journal

不可复现 Bug 处理

1. 收集所有可能的状态
   - 时间 / 数据 / 用户 / 环境 / 时序

2. 增加日志
   - 与开发协作加 debug 日志

3. 监控触发条件
   - 用户上报 / 客诉 / 监控告警

4. 不立即关 "Cannot Reproduce"
   - 标 "Pending Reproduction" 跟踪 1 周

5. 实在再现不了
   - 关闭 + field-journal 记录现象 + 触发条件假设

缺陷分布分析

按模块：哪个模块 Bug 最多 → 重点测
按严重度：S0/S1 占比 → 上线就绪度
按发现阶段：单元 / 集成 / E2E / 探索 / 生产
  → 越晚发现，成本越高
按根因类别：
  - 需求不清
  - 设计缺陷
  - 编码错误
  - 配置问题
  - 数据问题
  - 第三方
按修复时间：
  - 平均修复时间（MTTR）

质量自检

□ 标题包含模块 + 现象 + 条件
□ 复现步骤是最小路径
□ 预期 vs 实际清晰
□ 截图 / 日志 / trace_id 完整
□ 严重度和优先级有依据
□ 复现率说明
□ 影响范围清楚
□ S0/P0 同步通知（不只靠 ticket）
□ 修复后验证 = 原路径 + 边界 + 回归
□ 同类 Bug 已转回归用例

常见坑

1. 标题"登录失败"——开发不知道哪里、什么条件
2. 复现步骤太长——9 步骤里有 7 步无关
3. 没有预期结果——开发不知道你想要什么
4. 截图但没文字描述——搜索不到、归档难
5. 缺 trace_id——后端排查无入口
6. 严重度凭感觉打——QA 拍 S0、PM 拍 S3
7. 不写复现率——偶发当 100%，浪费排查时间
8. 不可复现立刻关 Cannot Reproduce——可能是真 Bug 没抓到
9. 修复后只测原路径——边界 / 类似变体没覆盖
10. 同类 Bug 不沉淀——下次还在同地方踩

配套模板

• templates/bug-report-template.md — Bug 报告完整模板（含标题 / 复现 / 严重度 / 影响 / 验证 / 自检）

与其他 skill 的协作

上游：
  test-case-design → 用例失败时形成 Bug
  exploratory-testing → Charter 中发现 Bug
  api-testing → 接口测试发现 Bug

下游：
  regression-testing → 转化为回归用例
  test-report → 缺陷分布纳入报告
  field-journal → 同类问题根因沉淀
  开发工作流 → 修复