🐛 缺陷管理规范
1. 缺陷管理概述
缺陷管理（Defect Management）是测试管理中最核心的管理活动之一，涵盖缺陷从发现到关闭的全生命周期管理。在银行业，缺陷管理不仅要满足项目管理的需要，还要满足监管合规和审计追溯的要求。
2. 缺陷生命周期
缺陷状态流转
📝 新建(New) → 👀 已确认(Confirmed) → 🔧 已分配(Assigned) → ✅ 已修复(Fixed) → 🔄 待验证(Verified) → ✔ 已关闭(Closed)
特殊流转路径：
- 已关闭 → 重新打开：验证不通过或缺陷复现
- 已分配 → 拒绝：经确认非缺陷（Not a Bug）
- 已确认 → 延期：经评审确认可延期修复
- 任何状态 → 挂起：因外部原因暂时无法处理
3. 缺陷严重程度与优先级
| 等级 | 严重程度 | 定义 | 响应时间 | 修复时间 |
|---|---|---|---|---|
| P0 | 致命 | 资金计算错误、数据丢失、安全漏洞、系统崩溃 | <1小时 | <4小时 |
| P1 | 严重 | 核心功能不可用、业务流程中断 | <4小时 | <24小时 |
| P2 | 一般 | 非核心功能异常、次要功能降级 | <24小时 | <3个工作日 |
| P3 | 轻微 | 界面问题、文案错误、体验优化 | <5个工作日 | 本版本内或下版本 |
4. 缺陷提交规范
一份高质量的缺陷报告应包含以下要素：
- 标题：简洁准确地描述缺陷现象（例："信贷审批页面，金额输入框未做千分位校验"）
- 所属模块：缺陷发生的功能模块或子系统
- 测试环境：测试环境的标识（环境名称、版本号、配置）
- 前置条件：复现缺陷所需的前提条件
- 复现步骤：清晰、可操作的重现步骤，每一步包含具体操作和输入
- 实际结果：执行步骤后观察到的实际现象
- 预期结果：按照需求或设计应该表现出的正确结果
- 附件：截图、日志、报文等辅助定位材料
5. 缺陷评审机制
5.1 缺陷评审会
建议每周组织一次缺陷评审会（Defect Triage Meeting），参与角色：测试组长（主持）、开发组长、业务代表、项目经理。会议议题：
- 评审新增缺陷的严重程度和优先级是否合理
- 确认延期缺陷的处理方案和时间表
- 回顾缺陷修复率和趋势
- 讨论缺陷根因和预防措施
5.2 缺陷根因分析
对于P0/P1级缺陷和建议定期进行根因分析（Root Cause Analysis）：
- 5 Whys分析法：连续追问"为什么"直到找到根本原因
- 鱼骨图：从人、机、料、法、环五个维度分析
- 因果分析：识别缺陷产生的直接原因、间接原因和根本原因
6. 缺陷度量指标
| 指标 | 定义 | 银行参考目标 |
|---|---|---|
| 缺陷发现密度 | 每功能点或每KLOC发现的缺陷数 | 2-5个/功能点 |
| 缺陷修复率 | 已修复缺陷数/总缺陷数 | ≥ 95%（上线前） |
| 缺陷逃逸率 | 生产缺陷数/(测试缺陷数+生产缺陷数) | ≤ 5% |
| 缺陷平均修复时间 | 从提交到修复通过的平均时长 | P0<4h, P1<24h |
| 缺陷回测通过率 | 一次修复验证通过的缺陷比例 | ≥ 85% |