# Bug Reporting

> 发现缺陷需要记录时使用。适用于功能测试、回归测试、探索式测试发现的所有缺陷。融合 Cem Kaner 缺陷报告、ISTQB 缺陷生命周期、严重度优先级矩阵。

- Skill: `zhaoxuya520/bug-reporting` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/bug-reporting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/bug-reporting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/bug-reporting

---


# 缺陷报告（Bug Reporting）

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

## 适用场景

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

## 核心原则

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

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

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

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

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

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

## 好 Bug 标题 vs 坏 Bug 标题

| 坏标题 | 好标题 |
|--------|--------|
| 登录失败 | [登录] 输入超过 64 字符的邮箱时返回 500 而非 400 |
| 提交按钮没用 | [订单创建] 网络慢时（>3s）连续点击导致重复创建 |
| 显示错误 | [订单列表] 时区切换后 created_at 显示错误（晚 8 小时） |
| 性能问题 | [搜索] 关键词包含特殊字符 % 时响应时间从 200ms 增至 30s |

## 复现步骤（最小化）

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

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

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

## 必备字段（Cem Kaner 模型）

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

## 严重度（Severity）

| 等级 | 含义 | 示例 |
|------|------|------|
| S0 致命 | 数据丢失 / 资金损失 / 全用户阻塞 / 安全漏洞 | 重复扣款 / 数据被覆盖 / SQL 注入 |
| S1 严重 | 核心功能不可用 / 部分用户阻塞 | 登录失败 / 支付失败 |
| S2 一般 | 功能不完整 / 有 workaround | 部分字段不显示 / 排序错 |
| S3 轻微 | UI / 文案 / 边缘场景 | 文案错字 / 像素偏移 |

## 优先级（Priority）

| 等级 | 含义 | 修复时间 |
|------|------|---------|
| P0 | 阻塞上线 | 立即 |
| P1 | 本版本必修 | 本迭代 |
| P2 | 下版本修 | 下迭代 |
| P3 | 排期看 | 何时都行 |

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

## Bug 生命周期（ISTQB）

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

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

或：
  ↓
Wont Fix / Duplicate / Cannot Reproduce
```

## 状态转换规则

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

## 报告 Bug 的工作流程

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

## 不可复现 Bug 处理

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

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

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

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

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

## 缺陷分布分析

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

## 质量自检

```text
□ 标题包含模块 + 现象 + 条件
□ 复现步骤是最小路径
□ 预期 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 的协作

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

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