缺陷工具使用规范要能落地，关键是把“谁在什么状态下填什么字段、按什么规则流转”写清楚，让成员照着做、管理者照着查。下面以一份虚构研发团队的规范为样本，完整展示字段定义、状态流转、分级规则、提交与关闭要求，再逐项解释设计意图，并给出换团队后可直接套用的改写规律。示例为演示情景，不代表任何真实客户实践。
要点总览（TL;DR）
- 一份可执行的缺陷工具使用规范，核心是把字段、状态、分级、职责四类内容写清楚，每条要求都能对应到工具里的字段、状态或动作。
- 示例把必填字段限定在标题、模块、复现步骤、实际与期望结果、严重程度、环境几项，判断标准是缺少这条信息修复人是否必须回头问提交人。
- 严重程度描述问题有多坏、由提交人按现象判定，优先级描述什么时候修、由开发负责人结合排期判定，两者分开可减少分级与排期争议。
- 状态流转为每个状态写明进入条件，等于设置检查点，避免没修完就进入待验证、没验证就关闭。
- 换团队改写时按先定角色再定字段、字段数量匹配团队规模、分级用可观察现象、状态数量可控、规范与工具配置同步维护的顺序调整。
这份示例要解决什么问题
很多团队的缺陷规范停留在“及时提交、认真修复、及时关闭”这类口号上，成员看完仍不知道具体该填什么、什么时候能改状态。这份示例的目标，是把规范写成一份可执行、可检查的文档：每条要求都能对应到工具里的一个字段、一个状态或一个动作，出现争议时可以拿规范原文对照。
示例覆盖四类内容。第一类是字段，规定提交缺陷时必须填写哪些信息、每项怎么写。第二类是状态，规定缺陷从提交到关闭经过哪些状态、进入和退出各自需要满足什么条件。第三类是分级，规定严重程度和优先级如何判定。第四类是职责，规定提交人、开发负责人、修复人、验证人各自能做什么、不能做什么。四类内容互相咬合：字段支撑分级判断，分级影响流转顺序，职责决定谁有权操作。
示例的假设前提需要先说明。团队为虚构的十人左右研发小组，使用一款通用的缺陷管理工具，规范正文只描述管理要求，不涉及具体产品的菜单路径和配置步骤。读者拿到这份示例后，可以保留结构、替换角色名称和分级阈值，改写成自己团队的版本。
完整示例：某研发团队的缺陷工具使用规范
适用范围与角色定义
本规范适用于本团队所有在缺陷工具中登记的产品缺陷，包括测试阶段发现的问题和线上反馈的问题。需求变更、体验优化建议不按缺陷登记，走需求流程。角色定义如下：
- 提交人：发现并登记缺陷的测试、研发或运营人员，负责把现象写清楚，并在修复后参与验证。
- 开发负责人：按模块接收新缺陷，判定优先级并指派修复人。
- 修复人：被指派的开发人员，负责定位、修复并填写修复说明。
- 验证人：通常为提交人或同模块测试人员，负责确认修复结果并决定关闭或退回。
- 质量负责人：每周查看缺陷状态分布，处理超期和争议。
必填字段清单及填写要求
| 字段 | 是否必填 | 填写要求 |
|---|---|---|
| 标题 | 必填 | 一句话描述“在什么场景下出现什么异常”，不超过40字，不写“有问题”“报错”这类无信息标题 |
| 所属模块 | 必填 | 从工具预设的模块列表中选择，选不到时先联系开发负责人补充模块 |
| 复现步骤 | 必填 | 按操作顺序编号写出，包含前置条件和测试数据，保证他人可重复操作 |
| 实际结果与期望结果 | 必填 | 分别写清现在发生了什么、按设计应该发生什么 |
| 严重程度 | 必填 | 按本规范分级表选择，提交人初判，开发负责人可复核调整 |
| 优先级 | 必填 | 由开发负责人指派时填写，提交人可给出建议 |
| 发现环境 | 必填 | 注明测试环境、预发布环境或线上，线上问题须附影响范围 |
| 附件 | 选填 | 截图、日志、录屏，涉及敏感信息时先脱敏 |
严重程度与优先级分级规则
严重程度描述缺陷本身对产品的影响，由提交人依据可观察现象判定；优先级描述修复的排期顺序，由开发负责人结合版本计划判定。两者分开填写，避免“影响大就必须马上修”的简单对应。
| 严重程度 | 判定现象 | 典型示例 |
|---|---|---|
| 致命 | 核心流程完全不可用，或造成数据丢失、资金错误 | 登录后主页面白屏；订单金额计算错误 |
| 严重 | 主要功能不可用，存在可绕过的替代路径 | 导出功能报错，但可逐条复制 |
| 一般 | 次要功能异常或显示错误，不影响主流程 | 列表分页数字显示错误 |
| 轻微 | 文案、样式、提示语等不影响功能使用的问题 | 按钮文字与设计稿不一致 |
优先级分为三级：P0 为当版必须修复，P1 为当前迭代内修复，P2 为排入后续版本。线上致命缺陷默认 P0，测试环境的一般缺陷默认 P1，轻微缺陷默认 P2。开发负责人调整优先级时须在缺陷中写明理由。
状态流转与各状态的进入/退出条件
| 状态 | 进入条件 | 退出条件与去向 |
|---|---|---|
| 新建 | 提交人完成必填字段并保存 | 开发负责人完成指派后进入“已指派” |
| 已指派 | 已指定修复人并填写优先级 | 修复人开始处理时改为“修复中”；判定为非缺陷时改为“已拒绝”并写明理由 |
| 修复中 | 修复人确认接手 | 修复完成并填写修复说明、影响范围后改为“待验证” |
| 待验证 | 修复说明完整，且已在对应环境部署 | 验证通过改为“已关闭”；未通过退回“修复中”并补充复现信息 |
| 已关闭 | 验证人确认修复结果符合期望 | 问题复现时重新打开，回到“修复中” |
| 已拒绝 | 开发负责人判定为设计如此、无法复现或重复缺陷 | 提交人有异议时提交质量负责人仲裁，仲裁为缺陷则回到“已指派” |
提交、指派、修复、验证、关闭的操作要求
- 提交：提交前先按标题关键词搜索是否已有同类缺陷，重复的补充信息到原缺陷，不另开新单。线上问题在提交后同步在团队沟通群说明影响范围。
- 指派：开发负责人应在工作日内完成新缺陷的指派，无法判断归属时先指派给模块负责人。
- 修复：修复说明须写明原因、修改范围和验证建议，涉及配置或数据变更的注明回滚方式。
- 验证：验证人按原复现步骤操作，并检查修复说明中提到的关联功能，验证结论写入缺陷记录。
- 关闭：只有验证人可以关闭缺陷；提交人长期无法验证时，由质量负责人确认后关闭并注明原因。
超期与退回的处理约定
P0 缺陷超过一个工作日未进入“修复中”、P1 缺陷超过三个工作日未修复的，由质量负责人在周会上通报，并记录阻塞原因。退回次数达到两次的缺陷，修复人与验证人共同复现一次，确认是描述不清还是修复不完整，结论写入缺陷记录。超期通报针对的是阻塞原因的处理，通报后须明确下一步责任人和时间，避免只催不解决。
逐项解释：每条规则为什么这样写
必填字段为什么限定在少数几个
必填字段的作用是保证缺陷可被他人接手处理，判断标准是“缺少这条信息，修复人是否必须回头问提交人”。标题、模块、复现步骤、实际与期望结果、严重程度、环境满足这个标准，因此设为必填。附件、关联需求等信息对部分缺陷有用、对另一部分无意义，设为选填可以降低提交负担。字段过多会让人为了提交而随意填写，反而降低数据质量。
严重程度与优先级分开定义的理由
严重程度回答“问题有多坏”，依据是产品现象，提交人现场就能判断；优先级回答“什么时候修”，依据是版本计划、影响用户范围和修复成本，需要开发负责人掌握排期信息后才能决定。两者合并成一个字段，会出现提交人替开发排期、或开发为赶进度压低严重程度的情况。分开之后，争议可以分别讨论：现象判断错了改严重程度，排期有变化改优先级。
状态流转为何要设进入条件而非只设状态名
只列状态名，成员只能凭感觉切换，常见结果是缺陷没修完就进入“待验证”，或验证没做就关闭。为每个状态写明进入条件，等于给流转设了检查点：进入“待验证”要求修复说明完整且已部署，进入“已关闭”要求验证人确认结果。条件写在规范里，评审和周会检查时就有统一依据，而不是靠个人记忆。
关闭权限与验证动作的分配逻辑
关闭权限交给验证人，是因为关闭意味着“问题已确认解决”，这个判断需要实际执行验证动作的人做出。修复人自修自关会失去独立确认环节；提交人随意关闭则可能漏掉关联功能检查。提交人长期无法验证时保留质量负责人确认关闭的通道，是为了避免缺陷因人员变动永久挂起。
超期规则如何避免变成形式化催办
超期规则如果只写“超期通报”，执行几次后就会变成例行点名。示例要求通报时记录阻塞原因并明确下一步责任人和时间，把催办转成对阻塞的处理：是等待环境、等待产品确认，还是排期冲突。退回两次要求双方共同复现，也是同样的思路，把反复拉扯变成一次面对面的问题定位。
这些规则要真正约束行为，需要工具层面能承载字段必填和状态流转。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布；同时支持自定义状态与多种属性，以及按组织架构、用户组、项目角色分配的多层权限。团队可以把示例中的状态和字段落到工作项配置上，用权限区分修复人与验证人的操作范围。字段是否可设为必填、流转是否可加前置条件，需以实际产品配置为准。
可迁移规律：换团队后怎么改这份规范
示例的价值在结构，不在具体条款。换到自己的团队，按下面的顺序改写，能减少返工。
- 先定角色，再定字段：先写清谁提交、谁指派、谁修复、谁验证，再决定每个角色在哪个环节必须填什么。角色不清时定出的字段往往无人负责维护。
- 字段数量与团队规模匹配：人数少、沟通靠当面同步的团队，必填字段可以更精简；跨团队协作、交接频繁时，才需要补充关联需求、影响范围等字段。每增加一个必填字段，都要能回答“谁会用它做判断”。
- 分级标准用可观察现象描述：把“严重影响用户体验”换成“核心流程不可用且无替代路径”这类可现场核对的现象，减少分级争议。阈值和示例按自己产品的核心流程重新列举。
- 状态数量控制在可维护范围：状态越多，进入条件越难写清，成员越容易跳步。中小团队保留新建、处理中、待验证、已关闭四到五个状态通常够用，需要区分拒绝和挂起时再增加。
- 规范与工具配置同步维护：规范改了字段或状态，工具里的选项和权限要同步调整，否则规范与实际操作脱节。建议指定一人负责对照检查，并在每次规范修订后做一次抽查。
如果团队使用 ONES，可结合 ONES TestCase 的能力把验证环节接上：未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并可为不同用户组、用例库和测试计划分别配置权限。这样“验证人关闭缺陷”的规则就有了对应的操作入口。
适用边界：哪些情况需要调整这套写法
这套写法适合缺陷类型相对统一、团队规模中等、以迭代方式交付的研发团队。以下情形需要调整，不能直接照搬。
- 示例为虚构情景：文中的团队、角色、阈值均为演示写法而设，不代表任何真实客户实践，也不附带效果数据。读者应把它当作模板骨架使用。
- 强监管或安全类缺陷：涉及资金、隐私、合规的缺陷，通常需要额外的定级审批、修复复核和留痕字段，关闭前可能要求多人确认。这类缺陷建议单独设流程，不与普通功能缺陷共用一套状态。
- 多团队共用一套工具：字段和状态由多个团队共用时，容易出现某团队需要的必填字段对另一团队是负担。可行做法是保留一套公共必填字段，各团队通过项目级配置增加自己的字段，公共部分变更需共同评审。
- 依赖工具支持：字段必填、状态流转约束、权限区分需要工具具备相应配置能力。工具只能记录而不能约束时，规范要靠评审和抽查补位，执行成本会上升。
- 规范需要定期评审：版本节奏、团队分工、产品形态变化后，分级阈值和状态条件可能失效。建议每季度或每个大版本结束后评审一次，删掉无人使用的字段，修正与实际不符的条款。
规范写完后，先用一个迭代试运行，收集提交人和修复人的实际填写反馈，再定稿。能被执行、能被检查的规范，比条款齐全但无人对照的文档更有价值。
常见问题
团队规模很小，还需要把严重程度和优先级分开填吗？
建议保留两个字段，但可以简化取值。人数少、沟通靠当面同步时，严重程度仍由提交人按现象初判，优先级由负责排期的人确认，哪怕只有两三级也够用。两个字段分开的价值在于争议可以分开讨论：现象判断错了改严重程度，排期有变化改优先级，不会因为一个字段同时承担两种含义而反复拉扯。
规范里的必填字段，工具里设不了必填怎么办？
先确认工具是否支持字段必填与状态流转约束，这决定了规范能靠系统约束还是靠人工检查落地。工具只能记录而不能约束时，规范要靠提交后评审、周会抽查补位，执行成本会上升。此时可以把必填项压缩到最少的几项，并在提交环节安排一次快速检查，等工具配置能力具备后再逐步加严。
多个团队共用一套缺陷工具，字段和状态怎么协调？
可行做法是保留一套公共必填字段，各团队通过项目级配置增加自己的字段，公共部分的变更需共同评审。状态也按同样思路处理：公共状态覆盖从提交到关闭的主干，个别团队需要的挂起、待产品确认等状态放在项目级。这样既保证跨团队统计口径一致，又不让某个团队的必填要求变成其他团队的负担。
规范写完后多久评审一次比较合适？
建议每季度或每个大版本结束后评审一次。评审时重点看三件事：有没有字段长期无人使用、分级阈值是否与当前产品形态相符、状态条件是否被频繁绕过。规范落地初期可以先用一个迭代试运行，收集提交人和修复人的实际填写反馈再定稿，之后按固定周期修订，避免一次写完长期不变。
线上缺陷和测试阶段缺陷要用同一套流程吗？
可以共用主干状态，但线上缺陷需要补充影响范围、回滚方式等信息，并在提交后同步通知相关人。涉及资金、隐私、合规的缺陷通常还需要额外的定级审批和修复复核，建议单独设流程，不与普通功能缺陷共用一套状态。普通线上问题仍走新建、已指派、修复中、待验证、已关闭的主干，只是响应时限更紧。
