缺陷管理制度怎么写：分级、时限、复盘三件事

很多团队把Bug管理制度写成了原则文件：要重视质量、要及时修复、要定期复盘。条款都对，执行时还是卡在同一处：Bug来了，谁定级、多久响应、复盘改什么，没有一条能直接落到工单上。真正能执行的制度，至少要把三件事写清楚：分级、时限、复盘。

一、先定主线：制度管的是风险，不是Bug数量

Bug管理制度的起点不是让Bug数量归零，而是让不同风险的问题得到匹配的处理。数量受需求规模、测试深度和统计口径影响，单看数量容易误判：测试记录更完整，数字会上升；团队提前关闭，数字会下降，但用户风险未必同步变化。

美国国家标准与技术研究院2002年的一项研究估计，软件错误每年给美国经济造成约595亿美元损失，其中超过三分之一可通过更早、更有效的测试减少。这是2002年的美国数据，不能直接换算成当前团队的成本倍数，但它指向一个方向：越晚发现问题，修复要协调的角色越多。这也是后文复盘要追问发现时点的原因。

最小闭环可以拆成六步：发现、定级、响应、修复、验证、复盘。六步对应三件事：定级对应分级，响应、修复、验证对应时限，复盘对应改进闭环。每一步都应留下责任人、时间点和证据，否则制度容易退化成口头约定。中大型团队还要统一跨项目、跨版本的字段，否则A项目叫致命、B项目叫高，汇总时无法比较。

制度要解决的是风险分层，不是追求Bug数量归零。

二、分级：把多严重和多着急分开

1. 严重程度看影响，优先级看排期

很多团队只设一个P0-P3字段，结果产品按客户声量排、研发按技术风险排、测试按复现难度排，同一张表出现三种口径。问题不在P0-P3这个命名，而在于一个字段同时回答了两个问题。更稳妥的做法是分开维护：严重程度用S0-S3，优先级用P0-P3。

严重程度可分为四级：S0阻断、S1严重、S2一般、S3轻微。S0指核心流程不可用、数据丢失或可利用的高危安全漏洞；S1指主要功能受损且无绕行方案；S2指次要功能出错但有替代路径；S3指界面、文案、体验问题。

优先级可分为四级：P0指核心业务中断、重大合规风险或大面积客户受影响；P1指主要业务受损或关键客户受影响；P2指局部功能受影响但有替代方案；P3指一般问题，可按版本排期。判断时综合业务影响、客户范围、发布窗口和合规要求。一个S3的文案错误，如果出现在监管披露页面，优先级也可能升高；一个S1的内部工具故障，如果当前没有业务使用，优先级未必最高。严重程度描述影响，优先级决定排队。

2. 分级要有证据，也要有争议升级规则

分级不能凭感觉。提交Bug时至少写清影响版本、运行环境、复现步骤、实际结果、预期结果和影响范围，能附日志或截图就附上。信息不全的Bug进入待补充状态，待补充最长保留1个工作日；对报告影响较大的Bug，先按S0/S1或P0/P1定级并响应，不应以信息不全为由不响应。待补充只暂停修复时钟，不暂停响应时钟；信息补齐后可以调整级别，但需要记录调整原因。

出现分歧时，只对S0/S1、P0/P1或跨团队争议召开30分钟定级会：测试说明复现和影响，研发判断技术风险，产品确认业务优先级。无法达成一致时，按更高风险先处理，并在复盘时回看判断依据。争议时先按高风险处理，比事后解释更安全。

Bug系统应把影响版本、严重程度、优先级、重现步骤做成结构化字段，并允许Bug关联需求、任务、用例和版本，分级时不用再翻聊天记录。具体流转可以参考Bug管理流程。

三、时限：给每个阶段单独计时

1. 响应、修复、验证是三段时钟

用Bug从创建到关闭的天数衡量处理效率，不是一个好指标，因为它把等待分诊、等待信息、修复、回归和发布窗口混在一起。更可执行的做法是拆成三段：响应时限、修复时限、验证时限。

这张表是示例，不是行业标准。时限要按团队发布节奏、系统影响面和值班能力测算：先取最近20个同类Bug的实际耗时中位数，再留出合理缓冲。照搬别家的24小时，容易制造一批制度性超时。验证时限从修复提交开始，不含发布窗口。

2. 时限要写清起点、停表和升级

每条时限都应定义起点和终点。响应从Bug提交或告警触发开始，到责任人确认受理为止；修复从指派完成开始，到提交验证为止；验证从修复提交开始，到关闭或重新激活为止。起点不清楚，统计就会失真。

等待需求确认、第三方接口或生产窗口时可以暂停计时，也就是停表，但需要填写停表原因、恢复时间和批准人。没有记录的延期，按超时处理。超时后的动作也要提前写：P0/P1超时升级到测试负责人、研发负责人和产品负责人；同一P2 Bug在两个阶段超时，或连续两个统计周期超时，进入周会；P3在下个迭代排期时优先复核。时限的作用不是惩罚，而是让风险及时暴露。

Bug系统应支持提交、确认、解决、验证和关闭的状态流转，配合报表可以看每天新增、解决和遗留的Bug，也能按严重程度和优先级筛选。更完整的测试管理能力可以看测试管理功能。

四、复盘：追为什么没早发现

1. 复盘只挑三类Bug

不是每个Bug都值得开会。优先复盘三类：线上逃逸的Bug，即发布后才发现的问题；重复复发的Bug；S0/S1、P0/P1或长时间未闭环的Bug。它们分别对应发布门禁、根因治理和流程协同的问题。

复盘输入至少包括Bug时间线、影响范围、发现阶段、根因分类、修复方式、是否重开、相关需求和用例。重开指验证不通过后重新打开。没有这些材料，会议容易变成下次注意。材料不必写成长篇报告，但每个结论都应能指回一条记录。

2. 复盘输出要能验证

一场30到45分钟的复盘，按四步走：还原时间线，找出最早可以发现的节点，追问为什么没有发现，确定能验证的改进动作。通常一条根因对应一条改进，单次复盘控制在3条以内，避免会议纪要变成待办堆叠。

改进动作要具体到：改哪个用例、加哪条代码评审规则、补哪个监控告警、调整哪个发布门禁，并写清负责人和完成日期。下次复盘先检查上次动作是否完成、指标是否变化。复盘的价值不在会议纪要，而在下个版本少犯一次同样的错。

Bug系统应支持Bug归因、测试报告和仪表盘，能按严重程度、模块、版本聚合，复盘时直接用数据说话；Bug与需求、用例、版本的关联也能帮助定位逃逸环节。相关做法可以参考如何做有效的Bug管理。

五、把三件事写成一份可执行的制度

1. 制度目录

一份可执行的Bug管理制度，尽量控制在一页纸，建议包含八块：目的与适用范围、角色与职责、分级表、时限表、状态流转、超时升级、复盘机制、度量指标。每一块都要回答谁在什么时候做什么，而不是只写应及时处理。

2. 三条示范条款

• 分级条款：Bug严重程度分为S0-S3，由测试提出、研发确认；优先级分为P0-P3，由产品负责人确认，重大客户或合规事项由业务负责人参与。

• 时限条款：P0在15分钟内确认受理，4小时内给出临时方案，24小时内提交验证；验证时限从修复提交开始，不含发布窗口。

• 复盘条款：S0/S1、P0/P1和线上逃逸Bug在3个工作日内复盘，通常每条根因对应一条改进动作、一个负责人和一个完成日期。

3. 试点与指标

落地时不建议一次性全量推行。选一个项目或一个版本试运行两周，用20到30个真实Bug校准分级和时限。校准可以由测试和产品各自独立定级，再对比差异，避免一个人拍板。

统计周期按周或按迭代固定，跨团队才能比较。先在一个项目试运行两周，再决定是否推广。

工具方面，禅道把产品、项目、质量管理和Bug流转放在同一条链路里，适合中大型团队把制度固化到日常操作中。系统支持Bug结构化字段、状态流转、测试报告和仪表盘，能让分级、时限和复盘留下可查的记录。

六、常见问题

1. 跨项目、跨团队的Bug归谁负责？

先按受影响的产品和版本确定归属，再按代码库或服务的责任人确定修复人。跨团队依赖时设一个联合负责人，由该负责人协调排期；超时仍按高优先级升级路径处理，避免两边都能管、两边都不管。

2. 历史积压的Bug要不要一次性清零？

不建议一次性清零。先按风险分三批：P0/P1立即处理；P2设截止日期；P3集中评审：确认不再复现或不再适用的关闭；仍需修复的排期处理；属于需求变更的转需求。积压治理的目标是让每一条都有明确状态，而不是只追求数量下降。

3. 外包或供应商的Bug怎么纳入同一套时限？

在合同或协作约定中写清分级、响应、修复和验证时限，并要求对方在同一个Bug系统里更新状态。内部责任人负责验收和关闭，不应把Bug转给对方后就视为完成。超时同样进入升级路径。

三件事可以收成一句话：分级定风险，时限定节奏，复盘定改进。 一份好的Bug管理制度，不是让团队多填几张表，而是让每个Bug都知道下一步该找谁、什么时候有结果、下次怎样少出现。

参考资料：NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, Planning Report 02-3, 2002. https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf