软件项目开发全流程 · 第 22 课 · 缺陷管理：Bug 的生命周期

1、一个"已修复"却反复出现的 Bug

用户反馈："导出报表偶尔少一行。"

开发看了半天，"我本地跑没问题啊"，随手标了"无法复现"就关掉。两周后同一问题再来，这次还更严重——团队才发现：根本没有稳定的复现步骤，也没人记录环境。

Bug 管理不规范，修的是一个又一个"幽灵"。 本课讲清楚：一个 Bug 从发现到关闭的完整生命周期，以及怎么用数据度量质量。

2、缺陷（Bug）的生命周期

一个规范的 Bug 会经历这些状态：

 新建(New)
    │
    ▼
 已确认(Triaged/Confirmed) ──不是Bug──▶ 关闭为"设计如此/无法复现"
    │
    ▼
 已指派(Assigned)
    │
    ▼
 修复中(In Progress)
    │
    ▼
 待验证(Fixed / Ready for Test)
    │
    ├──验证通过──▶ 已关闭(Closed)
    └──验证不通过─▶ 重新打开(Reopened) → 回到"修复中"

每个状态变更是有纪律的：

新建：必须填写可复现的信息（见下节），否则无法进入下一状态。
已确认：由测试/负责人复审，判定是不是真 Bug、优先级多少。
待验证：开发说改好了不算，必须由测试或报告者验证通过才能关闭。
重新打开：验证不通过就重开，不许"假关闭" 糊弄统计。

3、一份合格的 Bug 报告长什么样

差报告："登录坏了。" —— 没法修。
好报告（五要素）：

标题：登录页在 Safari 17 下点击"提交"无响应
环境：macOS 14 + Safari 17.2，生产环境 v2.3.1
复现步骤：
  1. 打开 https://app.example.com/login
  2. 输入正确账号密码
  3. 点击"登录"
预期结果：跳转到首页
实际结果：页面无任何反应，控制台报 TypeError: xxx
影响范围：所有 Safari 用户无法登录（严重）
附件：截图、控制台日志、录屏

记忆口诀：标题 / 环境 / 步骤 / 预期-实际 / 证据。信息不全的 Bug，就是给未来的自己挖坑。

4、缺陷分级：严重 vs 优先

初学者常把"严重"和"优先"混为一谈，其实是两件事：

维度	含义	谁定
严重程度（Severity）	从技术/功能看有多坏	测试/开发
优先级（Priority）	从业务看多急着修	产品/负责人

两者可以错位：

高严重、低优先：只在某个小众浏览器崩溃——很坏，但用户少，可以先等等。
低严重、高优先：官网首页公司名打错一个字母——不"严重"，但必须马上改。

常见分级：

P0 / 致命：系统崩溃、数据丢失、核心功能全挂     → 立即修，停下手头的事
P1 / 严重：主要功能不可用、无绕行方案           → 本迭代必修
P2 / 一般：次要功能异常、有绕行方案             → 排进计划
P3 / 轻微：体验/文案/样式小问题                 → 有空再修

规则：P0/P1 触发"停止-抢修"（Swarming），别让它们静静躺在 backlog 里。

5、从"修一个"到"防一类"

修 Bug 的最高境界不是"修完这一个"，而是问一句：为什么会漏掉？

这个 Bug 为什么没被测出来？→ 补一条回归测试（防复发）。
这类 Bug 还有别的地方吗？→ 全局搜同类模式，一次修一类。
流程上哪一步能拦住它？→ 加 lint 规则 / 契约校验 / code review 清单。

# 修复 Bug 时，先写一个复现该 Bug 的失败测试
def test_export_report_includes_last_row():
    report = export_report([1, 2, 3])
    assert len(report.rows) == 3      # 之前的 Bug：最后一行丢失

# 然后修代码直到变绿 —— 这条测试从此永久防复发

"回归测试"= 把 Bug 钉在墙上：以后谁再改坏，CI 立刻红。

6、质量度量：用数据说话

光靠感觉不够，用指标看质量趋势（看趋势，别 KPI 化）：

指标	含义	怎么用
缺陷密度	每千行代码的 Bug 数	评估模块质量热点
缺陷逃逸率	上线后才发现的比例	测试有效性的核心指标
平均修复时长（MTTR）	从报出到关闭的时长	响应能力
重开率	被 reopen 的比例	修复质量（高=假修复多）
Bug 趋势曲线	新建 vs 关闭的累积差	判断能否发布（收敛才发）

发布判据（常用）：

未修复的 P0/P1 = 0            ← 硬门槛
Bug 曲线持续收敛（关 > 开）    ← 说明质量在变稳
新增缺陷密度下降              ← 说明测试前移见效

警告：把"Bug 数量"当 KPI 会催生不报 Bug / 少报 Bug 的坏文化。指标要用来看趋势和改进，不是用来扣人钱。

7、常见误区

误区	问题	正解
Bug 信息不全	无法复现、来回扯皮	强制五要素
"本地无法复现"就关闭	环境差异被忽视	记录环境、找差异、请报告者协助
修复不做回归测试	同一个 Bug 反复出现	修 Bug 必配回归测试
假关 Bug 冲指标	统计造假，用户遭殃	必须验证通过才关
严重=优先	优先级判断失真	两个维度分开定

8、动手实验 🎯

任务：为贯穿项目「团队任务清单」建立 Bug 管理流程。

写 Bug 模板（五要素）：在仓库加 .github/ISSUE_TEMPLATE/bug_report.md。
定义分级标准：为你的项目写出 P0~P3 的具体判据，各举一例。
造 5 个 Bug：故意在代码里埋 5 个错（空列表未处理、时区、并发、排序、边界），写成规范 Bug 报告。
走一遍生命周期：把其中 1 个 Bug 从 New → 确认 → 修复 → 待验证 → 关闭，全程记录状态与时间。
补回归测试：每修一个 Bug，配一条能复现它的回归测试，确认"改回错误版本会红"。
算指标：根据你的 5 个 Bug，算出缺陷密度和重开率（哪怕数据很小）。
反思：如果 Bug 在上线后才被发现，代价和"在测试阶段发现"差多少？

下一课：性能与安全测试。

9、今天你带走的三句话

Bug 有生命周期：新建→确认→指派→修复→验证→关闭（或重开），验证通过才算修好。
五要素报告 + 严重/优先分离，才能高效调度修复。
修 Bug 必配回归测试；质量指标看趋势，别当 KPI 去压人。