缺陷受理规则要解决的是“这条缺陷是否受理、由谁受理、按什么优先级处理”。本文给出一份完整填写的缺陷受理判定表示例，用影响范围、严重程度、复现稳定性、业务紧迫性四个字段组合出受理结论，再按模块归属和当班角色指定责任人，并逐项解释取值理由与迁移到其他团队时的调整边界。示例为演示情景，数值仅作说明。
要点总览（TL;DR）
- 缺陷受理判定表用影响范围、严重程度、复现稳定性、业务紧迫性四个字段组合出受理结论，再按模块归属与当班角色指定责任人。
- 影响范围与严重程度要分开填写：前者看波及谁，后者看坏到什么程度，合并成一个字段会低估影响面小但后果严重的缺陷。
- 复现稳定性决定现在能否判断，业务紧迫性只调节优先级，不改变受理与否的结论。
- 迁移到其他团队时保留四个字段结构，替换取值枚举、优先级档位和响应时限，示例中的4小时仅为演示数值。
- 受理规则只管去留与责任人，状态流转归缺陷生命周期管理，根因规律归缺陷分析与预防，例外情形需另设升级通道。
示例要解决什么：受理决策要在一张表里说清
这份示例设定在一个常见的研发团队场景中：产品、测试、研发共用一套缺陷提交入口，每天有新缺陷进入待受理队列。团队希望把“收不收、谁来看、先处理谁”的判断从口头讨论变成一张可填写的表，让提交人、测试负责人和研发负责人在同一套取值上对话。以下内容均为演示情景，不对应任何真实客户或真实项目。
受理决策需要在一张表里回答四个问题：这条缺陷是否进入处理队列（受理结论）；进入队列后排在什么位置（优先级）；由哪个模块的哪类角色接手（责任模块与责任人角色）；多久之内必须给出第一次回应（首次响应时限）。四个问题对应四组字段，填写完成后即可完成一次分诊。
这张表的作用范围限定在受理决策环节。缺陷受理之后如何流转状态、如何定位根因、如何制定预防措施，分别属于缺陷生命周期管理和缺陷分析与预防的工作，不在本表示例的覆盖范围内。把边界先划清，表格才能保持简洁，避免把状态字段、根因字段一并塞进受理判定。
完整示例：一份填好的缺陷受理判定表
示例缺陷条目的背景如下：某业务系统的订单结算页面在特定操作下出现金额显示异常，由测试人员在回归测试中发现并提交。提交信息包含页面截图、操作路径和发生时间。以下表格展示该条目在受理判定表中的完整填写结果。
| 字段 | 填写值 | 说明 |
|---|---|---|
| 缺陷标题 | 订单结算页金额显示异常 | 提交人填写的简要描述 |
| 影响范围 | 部分用户（使用优惠券的订单） | 按受影响用户与功能范围取值 |
| 严重程度 | 高（金额错误，影响交易信任） | 按功能受损程度取值，与影响范围分开判断 |
| 复现稳定性 | 稳定复现（按提交路径三次均出现） | 按复现次数与条件一致性取值 |
| 业务紧迫性 | 紧迫（临近促销活动上线） | 按业务时间窗口取值 |
| 受理结论 | 受理 | 由四个判定字段组合得出 |
| 优先级 | P1 | 受理后按组合规则确定处理顺序 |
| 责任模块 | 交易结算模块 | 按缺陷所属功能归属确定 |
| 责任人角色 | 交易模块当班研发负责人 | 按模块归属与当班角色指定 |
| 首次响应时限 | 4 小时内 | 按优先级对应服务承诺推导，示例数值 |
这张表的价值在于结论可追溯：任何人看到“受理、P1、交易结算模块、当班研发负责人、4 小时内响应”，都能还原出判断依据，而不需要再问提交人或分诊人当时为什么这样定。表格中的时限数值属于演示设定，实际取值应由团队按自身服务承诺确定。
逐项解释：每个字段为什么这样填
影响范围与严重程度是两个独立维度，需要分开填写再组合判断。影响范围回答“多少人、哪些功能受影响”，示例中限定为使用优惠券的订单，属于部分用户；严重程度回答“功能受损到什么程度”，金额显示错误会直接影响用户对交易的信任，因此定为高。若把两者合并成一个“大问题/小问题”字段，就会出现“影响面小但后果严重”的缺陷被低估的情况。组合判定的常见做法是：影响范围广且严重程度高，直接受理并给高优先级；影响范围窄但严重程度高，同样受理，优先级视业务紧迫性调节；影响范围广但严重程度低，受理但排入常规队列；两者都低时，进入观察或合并处理。
复现稳定性影响的是受理结论的确定性。示例中按提交路径三次均出现，属于稳定复现，分诊人可以直接进入责任模块判定。若缺陷偶发、无法按描述复现，通常先不受理为正式缺陷，而是退回提交人补充环境、日志或录屏，或转为观察项跟踪。复现稳定性不直接决定优先级，它决定的是“现在能不能判断”，因此填写时应记录复现次数和复现条件，避免只写“偶现”这类无法核对的描述。
业务紧迫性作为优先级的调节项，而不是受理与否的门槛。示例中临近促销活动上线，业务时间窗口紧，因此在“影响范围部分用户、严重程度高”的基础上把优先级提到 P1。若同样的缺陷出现在业务平稳期，受理结论不变，优先级可能降为 P2。把业务紧迫性单独成字段，可以让分诊人明确区分“缺陷本身严重”和“现在必须优先处理”这两件事，也便于事后复核优先级是否被业务压力过度抬高。
责任模块与责任人角色成对填写。责任模块按缺陷所属功能归属确定，示例落在交易结算模块；责任人角色则按模块归属加当班安排指定，示例为交易模块当班研发负责人。这里填角色而非具体人名，是为了让规则在人员轮换、请假时仍然可用。模块归属存在争议时，例如缺陷横跨结算与优惠券两个模块，应在受理时明确主责模块，另一模块作为协作方记录，避免出现两边都等对方处理的情况。
首次响应时限由优先级推导，而不是逐条协商。示例中 P1 对应 4 小时内首次响应，P2、P3 依次放宽。响应时限指接手人给出第一次实质性回应的时间，包括确认收到、补充提问或给出初步判断，不等同于修复完成时间。团队应把每个优先级对应的时限写成固定对照，示例数值仅作演示，实际取值需结合团队规模、值班安排和业务时段确定。
可迁移规律：换一个团队怎么改这张表
四个判定字段具有通用性：影响范围、严重程度、复现稳定性、业务紧迫性分别覆盖“波及谁、坏到什么程度、能不能确认、急不急”四类信息，大多数缺陷分诊场景都需要这四类判断。迁移时建议保留字段结构，替换取值枚举。例如影响范围可以按用户比例划分，也可以按功能模块划分；严重程度可以分为阻塞、严重、一般、轻微，级数由团队自行确定，关键是每一级都有可核对的描述。
阈值与时限需要按团队规模和服务承诺调整。小团队可能只设两档优先级和两个响应时限，大团队可能需要更细的分档并区分工作日与节假日。调整时应同步修改判定表中的组合规则，避免出现“优先级分了三档、响应时限只写了两档”的缺口。示例中的 4 小时属于演示数值，不能直接当作行业标准引用。
责任人角色可按组织架构替换。有的团队按模块设负责人，有的团队按值班表轮转，有的团队由测试负责人统一分诊后再转研发。表格中保留“责任模块”和“责任人角色”两个字段即可适配这些差异，具体角色名称随组织调整。将判定表落地到缺陷管理工具时，可以把四个判定字段配置为工作项属性，把责任人角色对应到负责人字段，让分诊结果直接体现在工作项上。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。判定表本身仍需团队先定义清楚字段取值与组合规则，工具承载的是填写、分派和统计动作。
规则需要设置定期复核的触发条件，常见的有：模块归属发生调整、服务承诺变更、例外受理比例明显升高、同一字段频繁出现争议取值。出现这些信号时，应回到判定表修订取值枚举或组合规则，而不是在单条缺陷上反复特批。复核周期可以由团队按迭代节奏确定，重点是让规则随组织变化同步更新。
适用边界：这套受理规则管不到的地方
受理规则只回答“收不收、谁接手、多急”，缺陷受理之后的状态流转属于缺陷生命周期管理的范围。新建、已确认、修复中、待验证、关闭等状态如何定义、谁能推进状态、什么条件下可以关闭，需要单独的生命周期规则，不能指望受理判定表一并解决。把两类规则混在一张表里，会让字段含义变得模糊，分诊人也不清楚自己填的是受理判断还是处理进度。
根因规律归缺陷分析与预防。示例中的金额显示异常，最终由什么代码或配置引起、同类问题如何避免，属于分析和改进工作。受理表可以记录缺陷条目并保留统计口径，但不会自动给出根因结论。团队可以在缺陷关闭后另行组织复盘，把重复出现的问题沉淀为检查项或测试用例。
规则无法替代人工判断的例外情形需要提前写明处理方式。例如涉及资金安全、隐私泄露或线上大面积不可用的缺陷，即使复现不稳定，也应由当班负责人直接升级处理；跨模块且归属争议大的缺陷，由分诊负责人裁定主责模块；业务方临时提出的紧急诉求，应走例外受理通道并记录理由。这些例外不否定规则，而是让规则在边界情形下有明确的出口。
规则失效或需要升级处理的信号包括：大量缺陷在受理环节积压、同一优先级对应的响应时限频繁被突破、例外受理占比持续上升、提交人与分诊人对同一字段的理解长期不一致。出现这些情况时，应先检查字段定义和组合规则是否仍匹配当前业务，再决定调整阈值、补充角色还是重新划分模块归属。规则是分诊的共同语言，语言本身需要随团队变化维护。
常见问题
缺陷提交信息不完整、无法判断影响范围时，受理表该怎么填？
这种情况先不要强行给出受理结论，把条目退回提交人补充信息，或标记为待补充状态单独跟踪。可以要求提交人补齐三项最低信息：操作路径、发生环境、实际结果与预期结果的对比。补齐后再进入四个判定字段的填写。若业务方坚持要求先受理，可先按已知信息给出临时结论，并在表中注明“信息待补充”，由分诊负责人在约定时间内复核。
同一缺陷横跨两个模块，责任模块只能填一个吗？
建议在受理时明确一个主责模块，另一个模块作为协作方记录在备注或协作字段中。主责模块的判定依据可以是缺陷表现最直接的归属，也可以是修改成本最集中的位置。若两个模块确实难以区分，由分诊负责人裁定，避免两边互相等待。主责模块确定后，责任人角色随之对应到该模块的当班角色，协作方按需参与，不重复指定第一责任人。
业务紧迫性经常被业务方抬高，导致优先级失真，怎么处理？
把业务紧迫性的取值写成可核对的条件，例如是否临近已排期的上线节点、是否影响合同履约、是否有明确的外部时间承诺，而不是由提出人主观描述“很急”。同时在复核环节统计各优先级的实际占比，若高优先级缺陷长期集中，说明取值标准偏松或业务压力传导过度，应回到判定表收紧条件。例外受理可以保留，但需要记录理由，便于事后回看。
小团队人手少，四个判定字段和分档时限是否过于复杂？
可以简化，但建议保留字段结构。小团队可把影响范围简化为“单用户/多用户”，严重程度只分“阻塞/一般”两档，复现稳定性只记“可复现/不可复现”，业务紧迫性用“本期/下期”表示。响应时限相应合并为两档即可。字段减少后，组合规则也要同步简化，确保每一档都有对应的受理结论和责任人，不出现填了字段却无结论可依的情况。
把受理判定表放进缺陷管理工具时，哪些部分需要团队自己先定好？
工具承载的是字段填写、分派和统计动作，判定逻辑本身仍需团队先定义。需要提前确定的是：四个判定字段各自的取值枚举、组合出受理结论与优先级的规则、责任模块清单与对应角色、各优先级对应的响应时限。这些确定后，再把判定字段配置为工作项属性，把责任人角色对应到负责人字段。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。字段命名与取值仍需按团队实际配置。
