专栏进度：06 / 10 (测试理论专题)
一个只会提交"这里报错了"的测试员是平庸的。一个顶尖的 QA 应该能通过一个 Bug 看到背后的需求模糊、逻辑漏洞或环境污染。
一、 Bug 的"生态分布"：80/20 原则
在测试理论中，Bug 并不是均匀分布的。
缺陷集群效应 (Defect Clustering)：80% 的错误通常集中在 20% 的模块中。
逻辑：某些模块由于逻辑复杂（圈复杂度高）、历史债多（Legacy Code）或者由新人编写，天然就是 Bug 的温床。
策略：一旦发现某个功能点连续冒出 3 个以上的 Bug，不要停，继续深挖，那里一定还有一个"Bug 窝"。
二、 缺陷的生命周期：从出生到坟墓
一个标准的 Bug 必须经历严谨的状态流转，严禁私下通过口头沟通"修好了"。
New (新建)：测试员发现问题，提交至管理系统。
Open (打开)：开发负责人确认这是一个 Bug，并分配给具体开发。
Fixed (已修复)：开发修改完代码，推送到测试环境。
Retest (回归测试)：测试员验证。注意： 必须在相同环境、相同步骤下验证。
Closed (关闭)：验证通过，Bug 归档。
Reopened (激活)：如果验证不通过，坚决打回，生命周期重启。
三、 根因分析 (RCA)：挖掘 Bug 的"祖坟"
修掉一个 Bug 只是治标，分析它为什么产生才是治本。常用的方法是 5-Why 分析法：
现象：用户无法登录。
-
为什么？ 数据库连接超时。
-
为什么？ 数据库连接池满了。
-
为什么？ 某个查询语句没有关闭连接。
-
为什么？ 开发人员忘记在 finally 块中释放资源。
-
为什么？（根因） 项目组缺乏代码规范检查（Lint）和 Code Review。
结论：修掉那个连接只是暂时的，引入 静态代码扫描 才是真正的解决方案。
四、 缺陷报告的"黄金标准"：不可抵赖性
一份让开发无法拒绝的 Bug 报告应包含：
标题：[模块] [操作] [现象]。
复现步骤：1. 2. 3. 明确且简洁。
预期结果 vs 实际结果：用对比彰显荒谬。
附件：截图、视频、关键日志（Log）。没有日志的 Bug 就像没有物证的指控。
严重程度 (Severity)：致命、严重、一般、微小。
五、 避坑指南：缺陷管理的"人性博弈"
拒绝"这不是 Bug，这是设计"：如果开发这么说，请拉出第一篇提到的 RTM（需求跟踪矩阵）。只要偏离了用户需求，就是 Bug。
避免 Bug 堆积：上线前夕才处理 Bug 是自杀行为。坚持"Bug 日清"制度。
不要为了绩效凑数：提交 10 个错别字 Bug 的价值，远不如发现一个会导致数据库死锁的逻辑 Bug。