缺陷提交规范要解决的问题是：让每条缺陷记录都包含足以复现和定位问题的信息，并且让“信息不全就退回补充”成为团队默认动作。本文按文档骨架、字段规则、提交与评审步骤、角色分工、填写示例、检查清单六部分展开，聚焦缺陷记录本身的质量，严重程度判定与服务事件受理只在边界处说明。
要点总览（TL;DR）
- 缺陷提交规范由六部分组成：适用范围、字段清单、填写规则、提交与评审流程、角色分工、检查清单，其中字段清单与填写规则是主体。
- 必填字段以复现必要性划分：标题、环境与版本、复现步骤、预期结果、实际结果、附件证据、影响范围缺一不可，每个字段都要给出合格标准与反例。
- 流程上先自查再提交，评审人判断信息完整、是否重复、是否可分配，不合格记录按具体字段退回补充后重新进入待处理队列。
- 提交人、评审人、缺陷管理维护者、处理人各有交付物；规范维护由新增模块、字段反复不合格、流程状态调整等条件触发。
- 验收分文档级与记录级两级检查，配合固定节奏抽查退回率、退回原因分布和首次评审时长，据此调整字段规则或评审安排。
一份可用的缺陷提交规范包含哪些内容
缺陷提交规范是一份团队文档，读者是提交缺陷的测试人员、处理缺陷的研发人员，以及负责维护缺陷流程的人。它需要回答三个问题：一条缺陷记录必须写什么、由谁在什么时点检查、写到什么程度算合格。围绕这三个问题，规范文档可以固定为六个组成部分。
| 组成部分 | 作用 | 最小内容 |
|---|---|---|
| 适用范围 | 说明规范约束哪些缺陷、哪些团队、从哪个环节开始生效 | 适用产品线或项目范围；适用的缺陷类型；与相邻流程的边界说明 |
| 字段清单 | 规定一条缺陷记录包含哪些字段 | 字段名、是否必填、填写人、字段用途 |
| 填写规则 | 规定每个字段写到什么程度算合格 | 每个必填字段的合格标准、常见不合格写法、示例 |
| 提交与评审流程 | 规定记录从提交到进入待处理要经过哪些动作 | 提交前自查、提交、评审、退回补充、重新进入流程的步骤与完成标志 |
| 角色分工 | 规定谁写、谁评审、谁维护规范 | 角色名称、职责、各环节交付物 |
| 检查清单 | 供提交前自查和规范执行抽查使用 | 文档级检查项、记录级检查项、抽查方式与不通过处理 |
写规范时容易只写一句“描述清楚、步骤完整”，这类要求无法执行，因为不同人对“清楚”的判断不同。把要求拆到字段和检查项层面，规范才具备可核对性。字段清单与填写规则是规范的主体，流程与角色分工保证规则被执行，检查清单用于验收。
需要明确边界：严重程度与优先级的判定标准属于缺陷分类与分级主题，本文只约定在记录中以引用方式选择分级口径，不展开判定规则；服务事件受理与问题管理属于相邻流程，缺陷提交规范只说明缺陷记录进入缺陷流程的起点，不覆盖事件受理环节。这样划分可以避免一份规范承载过多内容，导致每个部分都写不细。
必填字段与填写规则：让缺陷可复现
字段设计的判断依据是复现必要性：缺少后他人无法复现或无法定位问题的字段设为必填，仅起辅助定位作用的字段设为选填。以下字段清单可直接作为规范中的表格使用，合格示例以“订单列表页导出按钮点击无响应”为情景演示。
| 字段 | 是否必填 | 填写规则 | 合格示例 |
|---|---|---|---|
| 标题 | 必填 | 一句话写清“在什么条件下、什么对象、出现什么异常”，不写“有问题”“打不开”这类无法检索的表述 | 订单列表页点击“导出”按钮后无响应，控制台报 500 |
| 环境与版本 | 必填 | 写明测试环境标识、被测版本号或构建号、浏览器或客户端版本、必要的账号角色 | 测试环境 test-03，版本 v2.4.1（构建 20240612），Chrome 125，商家管理员账号 |
| 复现步骤 | 必填 | 按操作顺序编号，每步一个动作，写清入口、输入数据和点击对象；步骤数量以他人能独立走完为准 | 1. 登录商家管理员账号；2. 进入订单管理—订单列表；3. 筛选近 7 天订单；4. 点击右上角“导出”按钮 |
| 预期结果 | 必填 | 写业务上应该发生的结果，不写“正常”“没问题” | 生成导出文件并开始下载，列表数据与筛选条件一致 |
| 实际结果 | 必填 | 写实际观察到的现象，包含报错文案、页面状态、是否可重复 | 按钮点击后无 loading 状态，页面无变化；控制台报 500；重复 3 次均出现 |
| 附件证据 | 必填 | 提供截图、录屏、日志或接口返回，附件需能打开查看且与现象对应 | 操作录屏 1 段（含控制台报错）、接口返回截图 1 张 |
| 影响范围 | 必填 | 说明受影响的用户角色、功能模块、数据范围，以及是否有临时规避方式 | 所有商家角色的订单导出均受影响；可改用逐页复制作为临时规避 |
| 关联需求或用例 | 选填 | 填写对应的需求编号或用例编号，便于追溯 | 需求 REQ-1024，用例 TC-ORDER-088 |
| 发现阶段 | 选填 | 标注在冒烟、回归、验收等哪个阶段发现 | 回归测试第二轮 |
常见不合格写法集中在几处：标题写成“导出有问题”，无法检索也无法判断影响；复现步骤写成“按正常流程操作”，他人无法还原；预期结果与实际结果写成同一句话，评审时无法对照；附件只贴一张截屏，缺少报错上下文。规范中应把这几类写法作为反例列出，比只写正面要求更容易被记住。
严重程度与优先级字段在记录中保留，但填写口径引用缺陷分类与分级文档中的定义，规范只约定“按分级文档选择对应档位，并在影响范围中写明判断依据”。这样字段规则与分级规则各自独立维护，分级标准调整时不需要改动提交规范。
提交、评审与退回的操作步骤
从发现缺陷到记录进入待处理状态，可以拆成五个连续动作，每个动作都有明确的输入、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交前自查 | 已整理的复现过程、截图与日志 | 按记录级检查清单逐项核对字段，补齐缺失信息 | 自查通过的草稿记录 | 检查清单全部勾选，无待补项 |
| 2. 提交 | 自查通过的草稿 | 填写全部必填字段，上传附件，选择所属模块与版本，指定处理团队 | 一条已提交的缺陷记录 | 必填字段无空项，附件可打开，模块与版本已选择 |
| 3. 评审 | 已提交记录 | 评审人核对信息完整性，检索是否与已有记录重复，判断是否可分配 | 评审结论：通过、退回补充或合并到已有记录 | 记录状态变为待处理，或收到明确的退回意见 |
| 4. 退回与补充 | 退回意见 | 提交人按意见补充字段或附件，在记录中说明补充内容 | 补充后的记录 | 退回意见逐条有回应，记录重新提交 |
| 5. 重新进入流程 | 补充后的记录 | 评审人复核补充内容，确认达到可复现标准 | 进入待处理队列的记录 | 记录可被处理人直接接手，无需再次询问背景 |
评审时点需要写进规范：建议在记录提交后的一个工作日内完成首次评审，避免记录长时间停留在待评审状态。评审人优先由模块负责人或熟悉该模块的测试负责人担任，评审动作只判断信息是否完整、是否重复、是否可分配，不在评审环节讨论修复方案。
退回机制是规范能否被执行的关键。退回意见要具体到字段，例如“复现步骤缺少筛选条件”“附件未包含报错日志”，避免只写“信息不全，请补充”。记录被退回后仍保留在原流程中，补充完成即重新进入评审，不要求提交人另开新记录，这样重复记录和沟通成本都能控制住。
缺陷记录需要承载字段、附件和状态流转，工具的选择会影响规范执行的成本。ONES 测试管理资料显示，未通过的测试用例可快速创建缺陷任务，缺陷任务可在测试与研发团队间流转，缺陷可关联至迭代；把提交规范中的必填字段与评审、退回状态配置到工作项中，提交人填写、评审人退回补充、处理人接手都在同一条记录上完成，规范中的步骤就有了对应的承载位置。具体字段配置与状态设置以团队实际使用的产品配置为准。
角色分工与各环节交付物
规范写在文档里没人执行，通常是因为职责没有落到人。以下对照表可作为规范中的角色章节直接使用，团队规模较小时一人可兼多个角色，但每个环节仍需明确交付物。
| 角色 | 职责 | 各环节交付物 |
|---|---|---|
| 提交人（测试或发现缺陷的人员） | 按字段规则完整填写记录，提交前完成自查，按退回意见补充信息 | 自查通过的缺陷记录；退回后的补充说明；附件证据 |
| 模块负责人或评审人 | 在约定时点评审记录，判断信息完整性、是否重复、是否可分配，给出具体退回意见 | 评审结论；退回意见；合并重复记录的处理说明 |
| 缺陷管理维护者 | 维护规范文档与字段清单，统计规范执行情况，组织规范调整 | 规范文档版本；字段调整记录；执行抽查报告 |
| 缺陷处理人（研发） | 接手待处理记录，在记录中反馈定位结论；发现信息不足时提出补充请求 | 处理状态更新；补充信息请求；关闭前的修复说明 |
规范维护需要设定触发条件，避免文档长期不更新。常见触发条件包括：新增产品线或模块需要扩展字段；连续抽查发现同一字段反复不合格，说明填写规则表述不清；缺陷流程状态调整导致评审或退回环节变化。触发后由缺陷管理维护者发起修订，修订内容经模块负责人确认后发布，并在团队内说明变更点。
关闭环节的交付物也应在规范中约定：处理人关闭记录时写明修复版本与验证方式，提交人验证通过后关闭，验证不通过则重新打开并补充新的复现信息。关闭不是流程终点，而是记录信息完整性的最后一次确认。
填写示例：一条合格缺陷记录长什么样
以下示例为演示情景，展示一条合格记录各字段的填写方式，团队可替换为自身业务中的真实模块。
| 字段 | 填写内容 | 为什么这样写 |
|---|---|---|
| 标题 | 订单列表页筛选近 7 天订单后点击“导出”无响应，接口返回 500 | 包含入口、前置条件、操作对象和异常表现，便于检索和判断影响 |
| 环境与版本 | 测试环境 test-03，版本 v2.4.1（构建 20240612），Chrome 125，商家管理员账号 | 环境、版本、浏览器、角色齐全，他人可在相同条件下复现 |
| 复现步骤 | 1. 登录商家管理员账号；2. 进入订单管理—订单列表；3. 筛选近 7 天订单；4. 点击右上角“导出”按钮 | 每步一个动作，入口和数据条件明确，步骤可顺序执行 |
| 预期结果 | 生成导出文件并开始下载，文件数据与筛选条件一致 | 写业务预期，可与实际结果逐条对照 |
| 实际结果 | 按钮点击后无 loading 状态，页面无变化；控制台报 500；重复 3 次均出现 | 包含现象、报错信息和复现稳定性，便于研发定位 |
| 附件证据 | 操作录屏 1 段（含控制台报错）、导出接口返回截图 1 张 | 证据与现象对应，评审人和处理人可直接查看 |
| 影响范围 | 所有商家角色的订单导出均受影响；可改用逐页复制作为临时规避 | 说明受影响角色、功能与规避方式，支撑分级判断 |
对照一条常见的不合格写法：标题写“导出有问题”；复现步骤写“进入订单页导出，报错”；预期结果写“正常导出”；实际结果写“导出失败”；附件只有一张列表页截图。这条记录的问题在于：无法判断是哪个筛选条件触发、报错内容是什么、是否稳定复现，评审人只能退回，处理人也无法直接定位。两者的差别不在文字多少，而在是否包含复现所需的全部条件。
示例可迁移到不同模块的规律是：标题写“条件+对象+异常”，步骤写“入口+数据+动作”，预期与实际各自独立成句，证据覆盖操作过程和报错信息，影响范围写清角色与规避方式。按这个规律替换模块名称和业务对象，即可得到其他模块的合格示例。
完成检查：规范落地后的自查与验收
检查分两级：文档级检查判断规范是否写完，记录级检查判断单条缺陷是否合格。两级检查都通过，才能说明规范既存在又被执行。
文档级检查清单
- 规范包含适用范围、字段清单、填写规则、提交与评审流程、角色分工、检查清单六个部分，无缺项。
- 每个必填字段都有合格标准，并至少配一个合格示例和一个不合格写法。
- 提交、评审、退回、重新进入流程的步骤写明了输入、动作、输出和完成标志。
- 角色分工表覆盖提交人、评审人、缺陷管理维护者、处理人，每个角色有对应交付物。
- 规范注明了与缺陷分类分级、服务事件管理的边界，并写明分级口径的引用方式。
- 规范有版本号和修订记录，最近一次修订说明了变更点。
记录级检查清单（提交前逐项核对）
- 标题能看出条件、对象和异常表现，不含“有问题”“不正常”等模糊表述。
- 环境、版本、浏览器或客户端版本、账号角色已填写。
- 复现步骤按顺序编号，每步一个动作，包含入口和数据条件。
- 预期结果与实际结果分别成句，可逐条对照。
- 附件可打开，包含操作过程与报错信息。
- 影响范围写清受影响角色、功能模块和临时规避方式。
- 严重程度与优先级按分级文档选择，并在影响范围中写明判断依据。
执行情况抽查建议按固定节奏进行：每周抽取一定数量的已提交记录，按记录级清单逐项核对，统计退回率、退回原因分布和首次评审时长。退回率持续偏高且集中在同一字段，说明该字段的填写规则需要改写或补充示例；首次评审时长偏长，说明评审人安排或评审时点需要调整。抽查结果由缺陷管理维护者汇总，在团队例会上说明，并明确整改责任人与完成时间。
不通过时的处理动作要写进规范：文档级检查不通过，由缺陷管理维护者限期补齐并重新发布；记录级检查不通过，按退回流程处理，同一提交人连续多次出现同类问题，由模块负责人与其一起对照示例修改一次记录，把规则落实到具体写法上。检查的目的在于让每条记录达到可复现、可分配的状态，使规范真正进入日常提交动作。
常见问题
团队规模小、一人兼多个角色时，评审环节可以省掉吗？
评审环节可以简化，但不宜整体取消。规模小时可由模块负责人兼任评审人，或由提交人之外的另一名成员做快速核对，重点看三件事：必填字段是否齐全、是否与已有记录重复、是否具备分配条件。若确实无人可评审，可退一步采用抽查制，由缺陷管理维护者按周抽取记录核对，并把发现的问题反馈给提交人。需要留意的是，缺少评审时退回机制也随之失效，信息不全的记录会直接进入处理环节，处理人需要额外沟通补齐背景，这部分成本通常高于一次快速评审。
记录被退回后，是补充原记录还是新开一条？
建议补充原记录，不另开新记录。退回意见应具体到字段，例如“复现步骤缺少筛选条件”“附件未包含报错日志”，提交人逐条回应并在原记录中补充，补充完成后重新提交评审。这样同一条缺陷的讨论、证据和状态变化都留在一条记录上，便于追溯，也避免重复记录干扰查重。只有在原记录描述的现象实际是另一个独立问题时，才拆分为新记录，并在两条记录中互相注明关联关系。
严重程度和优先级由提交人填还是评审人定？
常见做法是提交人先按分级文档选择档位，并在影响范围中写明判断依据，例如受影响的用户角色、功能模块和是否有临时规避方式；评审人或模块负责人在评审时复核，必要时调整。这样分工的原因是提交人最了解发现时的现场情况，而评审人更清楚模块的重要性和当前迭代安排。具体档位定义与判定标准属于缺陷分类与分级的内容，提交规范只约定引用方式，分级文档调整时不需要改动提交规范。
规范已经写好，怎么判断它真的被执行了？
看记录而不是看文档。按固定节奏抽取已提交记录，用记录级检查清单逐项核对，统计三个观察指标：退回率、退回原因分布、首次评审时长。退回率持续偏高且集中在同一字段，说明该字段的填写规则表述不清或缺少示例，应改写规则并补充正反例；首次评审时长偏长，说明评审人安排或评审时点需要调整。抽查结果由缺陷管理维护者汇总并在团队内说明，同时明确整改责任人与完成时间，避免检查停留在统计层面。
缺陷记录放在测试用例工具里还是项目管理工具里，对规范执行有影响吗？
有影响，主要体现在字段填写和状态流转是否在同一条记录上完成。若缺陷记录与用例执行结果分离，提交人需要重复录入环境、版本等信息，退回补充也容易散落在聊天工具里。ONES 测试管理资料显示，未通过的测试用例可快速创建缺陷任务，缺陷任务可在测试与研发团队间流转，缺陷可关联至迭代；把规范中的必填字段和评审、退回状态配置到工作项上，提交、评审、补充可以围绕同一条记录进行。具体字段配置与状态设置以团队实际使用的产品配置为准。
