缺陷管理、根因分析与持续改进
一、缺陷生命周期：发现、记录、修复、验证
缺陷生命周期是单条 Bug 从被注意到关闭的完整流程。发现：测试、用户、监控告警等途径；记录：写入缺陷跟踪系统（如 Jira、GitHub Issues），包含复现步骤、环境、预期与实际、严重程度等，信息足够才能修；修复：指派负责人、改代码、关联提交与工单；验证：确认问题已消失、无回归，再关闭。中间可有「待确认」「进行中」「待验」等状态，视团队约定而定。关键是把「谁在什么状态下该做什么」说清，避免漏修或重复修。
二、严重程度与优先级
严重程度（Severity）描述缺陷对系统的影响有多大——例如崩溃、数据错误、功能不可用、界面错位、建议改进。用于技术评估与统计。优先级（Priority）描述「多快修」——高优可能影响线上或阻塞发布，低优可排后。两者不一定一致：严重但影响面小可能优先级低；不严重但挡了关键路径可能优先级高。团队可约定简单等级（如 S1–S4、P1–P3），并在记录时填清，便于排期与沟通。
严重程度（Severity）
缺陷对系统/用户的影响程度。
- 致命：崩溃、数据丢失、安全漏洞
- 严重：主流程不可用
- 一般：功能异常但有替代方式
- 轻微：界面、文案、体验类
优先级（Priority）
修复的紧急程度，用于排期。
- 高：阻塞发布或影响线上，立即修
- 中：本迭代或近期要修
- 低：可延后或 backlog
三、根因分析：5 Why、鱼骨图
修完 Bug 若只停留在「那段代码写错了」，同类问题可能换个地方再出现。根因分析追问「为什么会出现」，找到流程、设计或习惯上的原因，才能从根上减少复发。
5 Why：对现象连续问「为什么」，一般问 3～5 层，直到触及可行动的原因（流程缺失、培训不足、设计缺陷等）。例如：线上报错 → 为什么？接口超时 → 为什么？依赖服务慢 → 为什么？没有超时与降级配置 → 为什么？设计时未考虑依赖不可用。于是改进点可以是「加超时与降级、在设计中纳入依赖故障」。
5 Why 示例（简化）
鱼骨图（Ishikawa / 因果图）：把可能的原因按类别画成「鱼骨」——常见维度有人、机、料、法、环（或人、流程、技术、环境等），在每根骨上填具体原因，再聚焦最可能或最可改的几条。适合多人一起头脑风暴、把原因结构化。
四、从缺陷到过程改进
单次根因分析的结果要落到过程改进：改流程、改规范、改工具、改培训，让同类问题更难发生。例如：若发现「很多 Bug 因需求理解偏差」，可加强需求评审或验收标准；若发现「回归漏测」，可补充用例或自动化；若发现「环境不一致导致偶发」，可统一环境与配置管理。把「这次我们学到了什么、要改什么」写进回顾或改进清单，并跟踪落实，缺陷管理才真正推动质量提升。
一句话： 缺陷生命周期包括发现、记录、修复、验证、关闭，要闭环、信息完整。严重程度看影响，优先级看何时修，两者配合排期。根因分析用 5 Why 或鱼骨图找到可行动的真因；过程改进把教训变成流程与规范，并跟踪落实，让缺陷驱动质量提升。
五、小结
缺陷管理：发现 → 记录 → 修复 → 验证 → 关闭，闭环清晰、信息完整。严重程度描述影响，优先级决定排期。根因分析：5 Why 层层追问，鱼骨图多维度归因，找到可改进的根因。过程改进：把分析结论落到流程、规范、用例、培训，并跟踪落实。下一章讲静态分析与代码质量工具，用工具在代码层面提前发现问题。