当团队缺陷管理混乱、Bug 没有统一的分级标准、或者领导要看缺陷趋势数据时使用此技能。覆盖缺陷从提交到关闭的完整生命周期,包括严重度/优先级分级规范、各状态流转条件和时效要求、缺陷度量和趋势分析。如果缺陷管理不规范,复盘数据就是垃圾——"严重Bug数量下降"可能是因为大家不再标记严重了。
---
name: qa-bug-lifecycle
version: 1.6.0
description: >-
当团队缺陷管理混乱、Bug 没有统一的分级标准、或者领导要看缺陷趋势数据时使用此技能。覆盖缺陷从提交到关闭的完整生命周期,包括严重度/优先级分级规范、各状态流转条件和时效要求、缺陷度量和趋势分析。如果缺陷管理不规范,复盘数据就是垃圾——"严重Bug数量下降"可能是因为大家不再标记严重了。
when_to_use: 用户说"缺陷管理"、"Bug管理"、"缺陷流程"、"Bug状态"、"严重度"、"缺陷趋势"、需要管理缺陷、分析缺陷趋势、团队需要规范缺陷管理流程时
allowed-tools: Read Grep Glob
related_skills:
upstream:
- qa-bug-reporting # 输入:Bug报告进入生命周期
downstream:
- qa-quality-metrics # 输出:缺陷数据用于质量度量
- qa-retrospective # 输出:缺陷数据用于复盘
- qa-test-reporting
input_format:
required:
- name: Bug报告
type: object
description: 来自qa-bug-reporting的缺陷报告
optional:
- name: 修复方案
type: string
description: 开发团队的修复方案
- name: 验证结果
type: string
description: 修复验证结果
output_format:
traceability:
- 每个缺陷沿用原始ID(BUG-XXXX)
- - 关联生命周期状态ID
structure:
- lifecycle_state: 当前生命周期状态
- severity_level: 严重度分级
- priority_level: 优先级分级
- state_history: 状态变更历史
- timeline: 各状态时效要求
- next_actions: 下一步操作建议
- closure_criteria: 关闭条件检查
error_recovery_guidance:
on_failure: "验证不通过时退回上一状态并附上退回原因"
retry_behavior: "退回后通知相关责任人重新处理"
categories: ['Development','Testing','Quality']
depth_requirement_quantification:
reference_value: "根据缺陷数量调整管理深度:简单×1/中等×2/复杂×3"
minimum: "至少覆盖严重度分级、状态流转、时效要求3个维度"
---
> **⚠️ 安全警告**:本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。
> 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证;测试前应脱敏/掩码处理。
> 本技能仅在 workspace/ 输出评估文件,不持久化、不外传、不跨会话复用。
# 缺陷生命周期管理
## 核心原则
缺陷管理不仅仅是记录Bug,而是驱动问题解决和质量改进。
## 缺陷生命周期
### 状态流转
```text
发现 → 确认 → 分配 → 修复 → 验证 → 关闭
│ │ │ │ │ │
│ │ │ │ │ └─ 关闭:验证通过
│ │ │ │ └─ 验证失败:重新打开
│ │ │ └─ 修复完成:等待验证
│ │ └─ 分配给开发:等待修复
│ └─ 确认为Bug:确认问题存在
└─ 测试发现:提交Bug报告
特殊状态:
├─ 拒绝:不是Bug/无法复现/设计如此
├─ 延期:当前版本不修复
├─ 重新打开:验证失败/回归失败
└─ 无法修复:技术限制/成本过高
```
### 状态定义
| 状态 | 定义 | 负责人 | 操作 |
|------|------|--------|------|
| 新建 | 测试提交Bug | 测试 | 提交Bug |
| 确认 | 确认是Bug | 测试/开发 | 确认/拒绝 |
| 分配 | 分配给开发 | 测试/开发 | 分配 |
| 修复中 | 开发修复中 | 开发 | 修复 |
| 待验证 | 修复完成等待验证 | 测试 | 验证 |
| 已关闭 | 验证通过 | 测试 | 关闭 |
| 重新打开 | 验证失败 | 测试 | 重新打开 |
| 拒绝 | 不是Bug | 测试/开发 | 拒绝 |
| 延期 | 当前不修复 | 测试/开发 | 延期 |
## 缺陷分级
### 严重程度分级
```text
P0-致命(Critical):
├─ 系统崩溃/数据丢失
├─ 核心功能完全不可用
├─ 安全漏洞
└─ 处理:立即修复
P1-严重(Major):
├─ 核心功能异常
├─ 数据错误
├─ 性能严重下降
└─ 处理:本版本修复
P2-一般(Normal):
├─ 次要功能异常
├─ 界面显示问题
├─ 操作不便
└─ 处理:下版本修复
P3-轻微(Minor):
├─ 文案错误
├─ 界面美化
├─ 优化建议
└─ 处理:排期修复
```
### 优先级定义
```text
紧急(Urgent):
├─ 影响线上用户
├─ 阻塞测试/发布
└─ 处理:立即处理
高(High):
├─ 影响核心功能
├─ 本版本必须修复
└─ 处理:优先处理
中(Medium):
├─ 影响次要功能
├─ 尽量本版本修复
└─ 处理:正常处理
低(Low):
├─ 影响较小
├─ 可以延期处理
└─ 处理:排期处理
```
## 缺陷分析
### 缺陷类型分析
```text
缺陷类型:
├─ 功能缺陷:功能不符合需求
├─ 界面缺陷:UI显示问题
├─ 性能缺陷:性能不达标
├─ 安全缺陷:安全漏洞
├─ 兼容性缺陷:兼容性问题
├─ 接口缺陷:接口问题
├─ 数据缺陷:数据问题
└─ 配置缺陷:配置问题
分析维度:
├─ 缺陷类型分布
├─ 缺陷模块分布
├─ 缺陷趋势
└─ 缺陷密度
```
### 缺陷根因分析
```text
根因分类:
├─ 需求问题
│ ├─ 需求不清晰
│ ├─ 需求变更
│ └─ 需求遗漏
│
├─ 设计问题
│ ├─ 设计不合理
│ ├─ 设计遗漏
│ └─ 设计变更
│
├─ 实现问题
│ ├─ 代码错误
│ ├─ 逻辑错误
│ └─ 边界处理
│
├─ 环境问题
│ ├─ 环境配置
│ ├─ 依赖问题
│ └─ 数据问题
│
└─ 测试问题
├─ 用例遗漏
├─ 执行遗漏
└─ 验证不充分
```
### 缺陷度量指标
```text
核心指标:
├─ 缺陷密度 = 缺陷数 / 功能点数
├─ 缺陷修复率 = 已修复缺陷 / 总缺陷
├─ 缺陷重开率 = 重新打开缺陷 / 总缺陷
├─ 缺陷逃逸率 = 线上缺陷 / (线上+测试缺陷)
└─ 缺陷修复周期 = 修复日期 - 提交日期
分析维度:
├─ 按时间:缺陷趋势
├─ 按模块:模块质量
├─ 按类型:问题分布
└─ 按人员:效率分析
```
## 缺陷报告模板
> 📌 本节与 qa-bug-reporting「Bug报告模板」为同一概念的两个版本。本技能模板侧重管理(含状态、优先级字段),bug-reporting 模板侧重执行(含前置条件、影响评估)。修改字段时请同步更新两个模板。
```markdown
# 缺陷报告
## 基本信息
- 缺陷ID:[ID]
- 标题:[标题]
- 严重程度:P0/P1/P2/P3
- 优先级:紧急/高/中/低
- 状态:[状态]
- 发现人:[人员]
- 发现日期:[日期]
## 问题描述
- 现象:[问题现象]
- 影响:[影响范围]
- 条件:[触发条件]
## 复现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]
## 预期vs实际
- 预期:[预期结果]
- 实际:[实际结果]
## 环境信息
- 环境:[环境信息]
- 版本:[版本号]
- 浏览器:[浏览器信息]
## 附件
- 截图:[截图]
- 日志:[日志]
## 根因分析(可选)
- 根因:[根因分析]
- 建议:[修复建议]
```
## 输出示例
**一个P0级Bug(支付成功但订单状态未更新)**
→ 生命周期管理:
- 提交:填写标准Bug报告
- 确认:开发确认存在该问题
- 修复:定位为支付回调处理逻辑缺陷
- 验证:QA验证修复后订单状态正常更新
- 关闭:确认已修复,关闭缺陷
**缺陷趋势分析:近3个迭代缺陷量上升30%**
→ 触发缺陷分析:按类型/模块/根因分类,识别质量下降根因,制定改进措施
## 异常处理引导
| 场景 | 表现 | 处理方式 |
|------|------|---------|
| 缺陷状态长期卡住 | Bug在"修复中"超过3天无更新 | 触发升级机制,逐级上报至项目经理 |
| 开发拒绝修复 | 标记为"设计如此"或"无法复现" | 要求书面理由,评估影响后提交产品决策 |
| 回归测试未通过 | 修复后的版本仍有问题 | 重新打开Bug,更新复现信息,提升优先级 |
| 临近发布发现P0缺陷 | 严重缺陷在发布窗口期未修复 | 评估影响面,判断是否延期,升级决策 |
## 检查清单
缺陷管理完成后检查:
- [ ] 缺陷生命周期是否清晰?
- [ ] 缺陷分级是否合理?
- [ ] 缺陷分析是否深入?
- [ ] 度量指标是否定义?
- [ ] 改进措施是否制定?
don't have the plugin yet? install it then click "run inline in claude" again.