缺陷工具使用规范要解决的是“同一条缺陷，不同人填出来不一样、流转到不同人手里就卡住”的问题。本文按可直接套用的顺序，交付四部分内容：缺陷类型与字段表、状态流转表、角色职责对照表，以及一份填好的示例和落地检查清单。规范需要工具承载字段、状态与权限，文中会在相应环节说明ONES的适配方式。
要点总览（TL;DR）
- 缺陷工具使用规范的核心是四张可执行的内容：缺陷字段表、状态流转表、角色职责表，以及发布后的执行检查清单。
- 严重程度描述缺陷本身的影响，优先级决定修复顺序，两者分别定义取值并写明换算关系，可以避免提交时混用。
- 状态机控制在八个状态左右，每个流转动作写明执行角色、准入条件和必填信息，退回、拒绝、重新打开要单独约定使用边界。
- 规范发布时同步完成工具配置，让必填字段和状态流转成为提交时的实际约束，再用两到三项指标观察执行情况。
- 规范宜短、可查、可校验，小团队可精简角色与状态，多团队协作时补充归属规则和升级路径。
规范先定什么：缺陷类型、分级与必填字段
规范的第一层内容决定缺陷记录的质量。建议先定三件事：缺陷类型怎么分、严重程度和优先级怎么取值、哪些字段必须填。这三项确定后，提交人照着填表即可，评审人也有统一口径判断记录是否合格。
缺陷类型与判定口径
类型划分宜少不宜多，常见取值包括功能缺陷、性能问题、界面问题、数据问题、兼容性问题和文档问题。每类要写一句判定口径，让提交人能自行归类。例如功能缺陷指“功能结果与需求描述或验收标准不一致”；数据问题指“数据取值、计算、存储或展示结果错误”。类型的作用是分流处理人和统计分布，不宜设置过细的子类，否则提交时反复犹豫，反而降低填写意愿。
严重程度与优先级的区别
这两个字段最容易混用。严重程度描述缺陷本身对业务或系统的影响，由缺陷的性质决定，提交后一般不再随意改动；优先级描述修复顺序，由当前迭代目标、影响范围和资源情况决定，可以随计划调整。规范中应分别给出取值定义，并说明两者的换算关系。例如严重程度为“致命”的缺陷默认优先级为“高”，但优先级为“高”的缺陷不一定是致命缺陷。下表给出一种可直接采用的五级定义。
| 等级 | 严重程度定义 | 优先级定义 |
|---|---|---|
| 致命 | 核心业务中断、数据丢失或存在安全风险，无临时规避方案 | 立即处理，暂停当前迭代其他工作 |
| 严重 | 主要功能不可用或结果明显错误，有临时规避方案 | 当前迭代内必须修复 |
| 一般 | 次要功能异常或体验受损，不影响主流程 | 排入近期迭代，按计划修复 |
| 轻微 | 文案、样式、提示信息等不影响功能使用的问题 | 可合并到后续版本处理 |
| 建议 | 优化建议，当前行为符合预期但可改进 | 进入待评估池，定期评审 |
必填字段表
必填字段的原则是：缺少该字段，处理人无法复现或无法判断。下表可直接作为规范中的字段表使用，填写时点一栏用于约束提交动作发生的顺序。
| 字段名 | 是否必填 | 填写人 | 填写时点 | 填写要求 |
|---|---|---|---|---|
| 标题 | 必填 | 提交人 | 提交时 | 一句话描述“在什么场景下出现什么异常”，不超过40字，不写“有问题”“报错”等笼统表述 |
| 缺陷类型 | 必填 | 提交人 | 提交时 | 从约定类型中选择一项 |
| 严重程度 | 必填 | 提交人 | 提交时 | 按五级定义选择，评审时可调整并注明理由 |
| 优先级 | 必填 | 测试负责人或缺陷管理员 | 确认时 | 结合迭代计划确定，提交人可给出建议值 |
| 复现步骤 | 必填 | 提交人 | 提交时 | 按操作顺序编号，写清前置条件和每一步操作，保证他人可重复执行 |
| 期望结果 | 必填 | 提交人 | 提交时 | 依据需求或验收标准描述正确行为 |
| 实际结果 | 必填 | 提交人 | 提交时 | 描述观察到的现象，附错误提示原文 |
| 环境 | 必填 | 提交人 | 提交时 | 写明测试环境、操作系统、浏览器或设备型号 |
| 版本 | 必填 | 提交人 | 提交时 | 填写发现缺陷的构建版本号或迭代标识 |
| 附件 | 条件必填 | 提交人 | 提交时 | 界面类、数据类缺陷须附截图或录屏；日志类缺陷附关键日志片段 |
| 关联需求 | 必填 | 提交人 | 提交时 | 关联对应需求或用户故事，无法关联时注明原因 |
| 处理人 | 必填 | 测试负责人或缺陷管理员 | 确认时 | 按模块归属指派，跨团队时走升级路径 |
| 修复说明 | 条件必填 | 开发负责人 | 提交验证时 | 说明修改内容、影响范围和自测结论 |
| 关闭理由 | 条件必填 | 关闭操作人 | 关闭时 | 写明验证通过、重复缺陷、非缺陷或延期处理等原因 |
选填字段包括标签、关联测试用例、发现阶段、预计修复时间等。填写时机建议放在确认与处理阶段：关联测试用例由测试负责人在确认时补充，预计修复时间由开发负责人在开始处理时填写。选填字段不宜过多，每增加一个字段都要说明它支撑哪项统计或哪个决策。
状态流转怎么设计：从提交到关闭的规则
状态机的设计目标是让每个流转动作都有明确的触发人、准入条件和必填信息。规范中应给出完整状态集合，再逐个动作写清规则，最后配一张状态流转图。图用于快速理解，表用于逐条校验，两者内容保持一致。
典型状态集合
建议采用以下状态：新建、已确认、处理中、待验证、已关闭、重新打开、挂起、已拒绝。状态数量控制在八个左右，既能区分处理阶段，又不至于让流转路径过于复杂。每个状态要写明含义，例如“待验证”表示开发已完成修改并提交测试验证，此时缺陷的处理责任在测试方。
状态流转表
| 当前状态 | 动作 | 执行角色 | 目标状态 | 准入条件 |
|---|---|---|---|---|
| 新建 | 确认 | 测试负责人或缺陷管理员 | 已确认 | 必填字段完整，复现步骤可执行，类型与严重程度合理 |
| 新建 | 拒绝 | 测试负责人或缺陷管理员 | 已拒绝 | 判定为重复缺陷、非缺陷或信息不足且无法补充，须填写拒绝理由 |
| 已确认 | 开始处理 | 开发负责人 | 处理中 | 已指派处理人，已填写预计修复时间 |
| 已确认 | 挂起 | 开发负责人 | 挂起 | 依赖外部条件暂无法处理，须写明挂起原因和恢复条件 |
| 处理中 | 提交验证 | 开发负责人 | 待验证 | 已填写修复说明，自测通过，代码已合入对应版本 |
| 处理中 | 退回 | 开发负责人 | 已确认 | 信息不足或无法复现，须写明退回理由和需要补充的信息 |
| 待验证 | 验证通过 | 测试负责人 | 已关闭 | 按原复现步骤验证通过，回归测试无新增问题，填写关闭理由 |
| 待验证 | 验证不通过 | 测试负责人 | 重新打开 | 问题仍可复现或修复引入新问题，须附验证记录 |
| 重新打开 | 再次处理 | 开发负责人 | 处理中 | 已确认重新打开理由成立 |
| 挂起 | 恢复 | 缺陷管理员 | 已确认 | 恢复条件已满足，重新指派处理人 |
| 已拒绝 | 申诉 | 提交人 | 新建 | 提交人补充证据后发起，由缺陷管理员复核 |
退回、拒绝与重新打开的使用边界
这三个动作是规范执行中最容易被滥用的地方，需要单独写清边界。退回用于缺陷记录本身不合格，责任在提交方，退回时必须写明缺什么信息；拒绝用于判定该记录不构成缺陷或属于重复记录，须由缺陷管理员或测试负责人执行并留理由；重新打开用于修复未生效或引入新问题，须附验证证据。规范可以约定：同一缺陷被退回超过两次，由缺陷管理员介入协调；重新打开率按月统计，作为修复质量的观察指标。
缺陷与需求、用例、版本的关联
关联关系决定缺陷能否被追溯。规范应要求每条缺陷至少关联一个需求，测试阶段发现的缺陷同时关联对应测试用例，修复后关联目标版本。这样在版本发布前可以按版本汇总未关闭缺陷，在复盘时可以按需求统计缺陷密度。工具层面，ONES Project 支持一键提交 Bug 至对应项目或迭代，并与 TestCase 数据互通，未通过的用例可快速创建缺陷任务，使缺陷、用例与迭代之间保持可追溯的关联。
角色与交付物：谁在哪个环节负责什么
流程写得再细，没有落到人就会停在文档里。角色部分要写清每个角色在缺陷生命周期中承担的动作、交付物和响应约定，避免出现“大家都负责、实际没人管”的环节。
角色职责与交付物对照表
| 角色 | 主要职责 | 关键交付物 | 响应约定 |
|---|---|---|---|
| 提交人 | 按字段表提交缺陷，补充复现信息，配合验证 | 合格的缺陷记录、复现材料 | 被退回后一个工作日内补充信息 |
| 测试负责人 | 确认缺陷、判定类型与严重程度、指派处理人、组织验证 | 确认结论、优先级建议、验证记录 | 新建缺陷在一个工作日内完成确认 |
| 开发负责人 | 评估修复方案、安排修复、提交验证、填写修复说明 | 修复说明、自测结论、合入版本记录 | 致命与严重缺陷当日响应，其余按迭代计划 |
| 缺陷管理员或质量负责人 | 维护规范与字段配置、处理争议、组织评审与清理、输出统计 | 规范版本、评审纪要、缺陷统计报告 | 每周输出一次状态分布，每月组织一次复盘 |
响应时限的约定方式建议写成“按严重程度分档”，而不是统一一个时限。致命缺陷要求当日响应并给出临时方案，严重缺陷在当前迭代内修复，一般及以下缺陷按迭代计划排期。时限写进规范后，应能在工具中通过状态停留时间观察是否被遵守。
缺陷评审与定期清理
建议每周进行一次缺陷评审，参与人包括测试负责人、开发负责人和缺陷管理员，处理结论包括：调整优先级、合并重复缺陷、关闭长期挂起项、升级跨团队问题。每月进行一次复盘，关注缺陷来源分布、重新打开率和平均处理时长。评审要有纪要，结论要回写到缺陷记录中，避免会开完记录仍是原样。
跨团队缺陷的归属与升级
跨团队缺陷先按模块归属判定处理团队，归属不清时由缺陷管理员裁定。升级路径建议设为两级：一级由双方开发负责人协商，二级提交给缺陷管理员或质量负责人协调。升级时要带上缺陷编号、影响范围和建议处理方案，避免只转发一条链接。ONES Project 提供按组织架构、用户组和项目角色分配的多层权限体系，可支撑不同团队在同一项目内按角色分工处理缺陷。
示例：一份可直接套用的缺陷记录与流转
下面用一条演示缺陷说明规范如何落到具体记录上。示例为虚构场景，用于展示字段取值和状态变化，不代表任何真实项目数据。
缺陷记录填写示例
- 标题：订单列表按金额排序后，第二页数据重复显示第一页内容
- 缺陷类型：功能缺陷
- 严重程度：严重；优先级：高（测试负责人确认时设定，理由：影响订单核对主流程）
- 复现步骤：1. 登录测试环境，进入订单列表；2. 选择按金额降序排序；3. 翻至第二页；4. 观察列表内容
- 期望结果：第二页显示第21至40条订单，与第一页无重复
- 实际结果：第二页显示内容与第一页完全相同，共20条重复记录
- 环境：测试环境，Chrome 120，Windows 11；版本：v2.4.0-rc1
- 附件：两页对比截图、接口返回数据片段
- 关联需求：订单列表分页与排序需求
状态变化与理由说明
该缺陷提交后进入新建状态；测试负责人当日确认，字段完整、可复现，设为已确认并指派给订单模块开发负责人。开发负责人开始处理后填写预计修复时间，状态转为处理中；修复完成后填写修复说明“分页参数未随排序条件重置，已修正并补充单元测试”，提交验证，状态转为待验证。测试人员按原步骤验证通过，并回归相邻排序场景，填写关闭理由“验证通过，回归无新增问题”，状态转为已关闭。整个过程在状态表中留下四次流转记录，每次都有执行人和理由。
常见填写错误对照
| 错误类型 | 错误示例 | 规范要求 |
|---|---|---|
| 标题含糊 | “订单页面有问题” | 写清场景、操作与异常现象，便于检索和去重 |
| 复现步骤缺失 | 只写“翻页就出错” | 按编号写清前置条件和每一步操作 |
| 严重程度虚高 | 文案错别字标为致命 | 按五级定义对照影响范围选择，评审时可下调并注明理由 |
| 期望结果写成解决方案 | “应该加个缓存” | 期望结果描述正确行为，修复方案由开发负责人给出 |
按团队规模调整示例
小团队可以精简角色，由测试负责人兼任缺陷管理员，评审频率改为每两周一次，状态集合保留新建、处理中、待验证、已关闭四个即可。多团队协作时，需要补充跨团队归属规则和升级路径，字段表中增加“所属模块”和“责任团队”两个字段，统计口径按团队拆分。调整的原则是保留字段、状态、角色、校验四类内容，按实际协作复杂度增减条目。
规范落地与完成检查
规范发布只是开始，能否被执行取决于工具配置是否同步、指标是否可观察、修订是否有触发条件。这一节给出发布动作、观察指标和一份完成检查清单。
发布、宣导与工具配置同步
发布时同步完成三件事：规范文档定稿并标注版本号和生效日期；在缺陷工具中把必填字段、状态流转和角色权限配置到位，使规范要求成为提交时的实际约束；组织一次宣导，用一条真实缺陷走一遍完整流程。工具配置与文档不一致是规范失效的常见原因，例如文档要求填写环境，工具中该字段却可留空，执行就会打折扣。ONES Project 支持缺陷跟踪管理与质量统计，可统计缺陷状态分布，便于把规范中的状态口径直接对应到统计报表。
可观察的执行指标
指标不宜多，起步阶段选两到三项即可。必填字段完整率反映提交质量，退回率反映记录合格程度，平均处理时长反映流转效率，重新打开率反映修复质量。每项指标要写明统计口径、观察周期和责任人，例如必填字段完整率按周统计，由缺陷管理员在周评审中通报。指标出现持续偏离时，先排查是规范不合理还是执行不到位，再决定修订规范还是加强宣导。
定期复查与修订触发条件
建议每季度复查一次规范，出现以下情况时提前修订：缺陷类型或严重程度定义与实际不符；状态流转频繁出现规范未覆盖的路径；工具配置调整导致字段或状态变化；指标连续两个月明显偏离目标；团队结构或协作方式发生变化。修订时保留版本记录，说明修改内容和原因，避免规范在多次口头调整后失去权威性。
规范落地完成检查清单
- 文档：规范已定稿，包含字段表、状态流转表、角色职责表，标注版本号与生效日期
- 字段：必填字段已在工具中配置为必填，字段定义与文档一致
- 状态：状态集合与流转规则已在工具中配置，每个流转动作有执行角色和准入条件
- 角色：四类角色的职责、交付物和响应约定已明确到人，跨团队升级路径可执行
- 关联：缺陷与需求、测试用例、版本的关联规则已写入规范并在工具中可用
- 指标：已选定两到三项执行指标，明确统计口径、周期和责任人
- 机制：缺陷评审与复盘已排入固定日程，修订触发条件已写明
- 验证：已用一条真实缺陷完整走通提交、确认、修复、验证、关闭全流程
以上八项全部满足，规范即可进入运行状态；后续按指标观察和定期复查持续修订，使规范与团队实际协作方式保持一致。
常见问题
团队规模很小，规范可以精简到什么程度？
小团队可以保留四类核心内容，按实际协作复杂度删减条目。角色上由测试负责人兼任缺陷管理员；状态集合保留新建、处理中、待验证、已关闭四个即可；评审频率改为每两周一次。字段表仍要保留标题、复现步骤、期望结果、实际结果、环境、版本这几项，因为缺少任何一项，处理人都难以复现问题。精简的是角色数量和状态路径，不是记录质量要求。
提交人认为缺陷被误判为重复或非缺陷，怎么处理？
规范中应为“已拒绝”状态设置申诉路径：提交人补充证据后发起申诉，由缺陷管理员复核，复核成立则回到新建状态重新确认。申诉机制的意义在于给判定留一个纠错入口，同时避免提交人与确认人直接争执。复核结论要回写到缺陷记录中，注明维持或撤销拒绝的理由，便于后续统计拒绝判定的准确率。
严重程度提交后还能改吗？由谁改？
可以改，但要限定修改人和理由。严重程度反映缺陷本身的影响，提交人按五级定义选择；确认阶段测试负责人可依据实际影响调整，调整时须注明理由。进入处理中之后，严重程度一般不再变动，避免统计口径反复。优先级则可以随迭代计划调整，由测试负责人或缺陷管理员在评审时统一修改。
规范发布后，怎么判断它真的在被执行？
看两到三项可观察的指标即可，例如必填字段完整率、退回率、平均处理时长和重新打开率。每项指标写明统计口径、观察周期和责任人，由缺陷管理员在周评审中通报。指标持续偏离时，先判断是规范本身不合理还是执行不到位，再决定修订规范还是加强宣导。此外，发布时用一条真实缺陷完整走通提交到关闭的流程，是最直接的验证方式。
规范需要多久修订一次，什么情况下提前修订？
建议每季度复查一次。出现以下情况时提前修订：缺陷类型或严重程度定义与实际不符；状态流转频繁出现规范未覆盖的路径；工具配置调整导致字段或状态变化；指标连续两个月明显偏离目标；团队结构或协作方式发生变化。修订时保留版本记录，说明修改内容和原因，避免规范在多次口头调整后失去约束力。
