缺陷提交的目标是让接手的人能复现问题、定位原因并判断影响。做法是把标题写成“对象+异常现象”，正文按环境、前置条件、复现步骤、实际结果、期望结果、影响范围、证据附件的顺序填写，提交前自查可复现性与信息完整性，再由测试或缺陷管理负责人做受理确认。本文聚焦缺陷记录的内容标准与提交动作，严重程度判定和修复回归流程不在讨论范围内。
要点总览（TL;DR）
- 缺陷提交按“环境、前置条件、复现步骤、实际结果、期望结果、影响范围、证据附件”的顺序填写，标题写成“对象+异常现象”，让接手人能复现、能定位、能判断影响。
- 提交前先做最小化复现，把路径压到最少步骤并连续执行两次以上确认现象一致，再收集环境信息与截图、录屏、日志等证据。
- 提交人负责信息完整与可复现，测试或缺陷管理负责人负责重复检索与受理判断，开发退回时说明具体缺什么，避免信息缺口在角色间往返。
- 提交前用检查清单逐项确认可复现性、步骤完整性、环境与证据、标题只写现象、重复检索和模块归属，不通过先补齐再提交。
- 缺陷记录以工作项形式管理时，提交、受理、退回体现为状态变化，提交人可直接在记录上补充说明和附件，缩短受理周期。
一条合格缺陷记录应包含哪些字段
缺陷记录的质量取决于字段是否填得具体。字段设计要服务于三个后续动作：开发能否照着步骤复现、负责人能否据此分级、验证人能否判断修复是否到位。下表给出可直接套用的字段清单，其中必填项是受理的最低门槛，选填项按缺陷复杂度补充。
| 字段 | 填写要求 | 必填/选填 | 用途 |
|---|---|---|---|
| 标题 | 写成“功能对象+异常现象”，一句话可辨识，避免“有问题”“报错”这类笼统表述 | 必填 | 列表检索与快速识别，也是重复缺陷判断的第一依据 |
| 所属模块 | 选到能负责该功能的最小模块或组件 | 必填 | 决定提交对象与分派路径 |
| 环境 | 记录设备型号、操作系统与版本、浏览器或客户端版本、服务端环境（测试/预发/生产）、账号角色 | 必填 | 排除环境差异导致的不可复现 |
| 前置条件 | 写清复现前必须存在的状态，如已登录某角色、已有某类数据、已开启某开关 | 必填 | 让复现从同一起点开始 |
| 复现步骤 | 按操作顺序编号，一步一个动作，写清输入值和点击位置 | 必填 | 开发复现与定位的主要依据 |
| 实际结果 | 只描述观察到的现象，包括报错文案、页面表现、数据值 | 必填 | 与期望结果形成对照，界定问题 |
| 期望结果 | 写清按需求或常识应出现的结果，有需求文档时注明出处 | 必填 | 判断是否为缺陷、修复到什么程度算完成 |
| 影响范围 | 说明受影响的用户角色、业务环节、数据量级，是否阻断主流程 | 必填 | 支撑分级与排期判断 |
| 证据附件 | 截图、录屏、日志片段、接口请求与响应记录，标注采集时间 | 必填（至少一项） | 加速定位，减少来回沟通 |
| 复现概率 | 如“5次出现3次”，说明是否稳定复现 | 选填 | 辅助判断偶现问题的排查优先级 |
| 关联需求或用例 | 关联对应需求条目或测试用例编号 | 选填 | 便于追溯需求实现情况与回归范围 |
| 发现版本 | 记录出现问题的构建或发布版本号 | 选填 | 辅助判断是否为版本引入问题 |
字段之间是相互支撑的关系：环境与前置条件保证复现起点一致，步骤与实际结果构成可执行路径，影响范围决定分级输入，证据附件缩短定位时间。缺少任何一项，接手人都需要回头找提交人补问，受理周期随之拉长。
缺陷提交的操作步骤
从发现异常到提交受理，可以拆成五步。每一步都有明确的输入、动作、输出和完成标志，做到完成标志即可进入下一步，不必反复打磨措辞。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 初步确认与最小化复现 | 发现的异常现象 | 换账号、换环境、清缓存再试一次，剔除操作失误和环境干扰；把复现路径压缩到最少步骤 | 一条稳定的最短复现路径 | 按该路径连续执行两次以上，现象一致 |
| 2. 收集环境与证据 | 复现过程 | 记录设备、系统、版本、账号角色；截取关键界面、录制操作过程、导出相关日志与请求记录 | 环境信息与证据文件 | 证据能对应到复现步骤中的具体环节 |
| 3. 按字段清单填写并自检 | 复现路径、环境信息、证据 | 逐项填写必填字段，实际结果只写现象，期望结果注明依据 | 一份完整草稿 | 必填字段无空缺，步骤可被他人照做 |
| 4. 选择模块与提交对象 | 草稿与模块划分 | 选定所属模块，确认提交到对应项目或迭代，指定处理人 | 已提交的缺陷记录 | 记录进入待受理状态，处理人可见 |
| 5. 跟踪受理并补充信息 | 受理反馈 | 查看是否被受理、合并或退回；被退回时按意见补充证据或细化步骤 | 受理结论或补充后的记录 | 状态变为已受理，或退回意见已闭环 |
第1步最容易被跳过。很多“提交后被判无法复现”的记录，问题出在提交前没有做最小化：步骤里混入了无关操作，或者现象只在特定账号权限下出现却没有记录。花几分钟把路径压短，比事后反复沟通更省时间。
第5步常被当作流程终点之外的事。提交人跟踪受理状态，能及时发现信息缺口并补齐，避免记录在待受理队列里停留过久。在缺陷记录以工作项形式管理的团队里，提交、受理、退回都体现为状态变化，提交人可以直接在记录上补充说明和附件。以 ONES 为例，未通过的测试用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；缺陷也可一键提交至对应项目或迭代，记录和跟踪修复情况。具体字段与流转配置以团队实际部署为准。
提交人、测试负责人与开发角色如何分工
缺陷提交环节的返工，多数来自角色责任不清：提交人认为“写个大概就行”，受理人认为“信息不全不该收”，开发认为“复现不了就退回”。把三方的交付物定清楚，信息缺口就有明确的补位人。
| 角色 | 核心职责 | 交付物 | 交接完成标志 |
|---|---|---|---|
| 提交人（测试或发现问题的成员） | 保证信息完整与可复现，按字段清单填写，附上证据 | 一条字段齐全、步骤可执行的缺陷记录 | 记录提交后进入待受理状态 |
| 测试或缺陷管理负责人 | 受理判断：检索是否重复、检查必填信息是否齐全、确认模块归属是否正确 | 受理、合并重复、退回补充的结论 | 记录状态明确，重复项已关联 |
| 开发 | 按记录复现；信息不足时说明缺什么、需要哪类证据，而不是简单退回 | 复现结论或具体的补充要求 | 开发确认可复现，或提交人已按补充要求更新记录 |
开发退回时给出具体缺口，是减少往返的关键。“无法复现”这类退回意见对提交人没有指导价值；写成“缺少该账号的角色权限说明，请补充登录账号类型和操作前的数据状态”，提交人就能一次补齐。受理负责人则承担重复缺陷的把关：同一现象已有记录时，把新记录关联到原记录并补充差异信息，避免同一问题分散在多条记录里。
角色权限也会影响分工落地。团队可按用户组配置不同权限，让提交、受理、处理各自在授权范围内操作，减少误改他人记录的情况。ONES TestCase 支持为不同用户组配置不同权限，并支持为用例库、测试计划单独配置权限；缺陷工作项本身的权限范围以实际配置为准。
完整示例：一条可复现的缺陷记录怎么写
以下为演示情景，用于说明写法，非真实项目案例。
标题：订单列表页按“待发货”筛选后，分页切换回第一页并显示全部状态订单
所属模块：订单管理-订单列表
环境：测试环境；Chrome 120；Windows 11；账号角色为商家管理员；测试数据为 120 条订单，其中待发货 18 条。
前置条件：已登录商家管理员账号，订单列表存在待发货与其他状态混合的数据。
复现步骤：
- 进入订单管理-订单列表页；
- 在状态筛选框选择“待发货”，点击查询，列表显示 18 条；
- 点击底部分页第 2 页；
- 点击分页第 1 页返回。
实际结果：返回第 1 页后，状态筛选框仍显示“待发货”，但列表展示全部状态的 120 条订单，筛选条件未生效。
期望结果：返回第 1 页后列表仍只显示待发货订单，筛选条件在分页切换后保持。
影响范围：所有使用订单列表筛选的商家账号；影响订单核对效率，不阻断下单主流程。
证据附件：操作录屏 1 段（含筛选与分页全过程）、第 1 页返回后的列表截图 1 张、筛选请求与返回记录 1 份。
复现概率：5 次操作出现 5 次。
逐项看写法取舍：标题把“筛选条件”和“分页返回后失效”两个要素写全，检索时能直接命中；环境里写清数据量级，是因为筛选失效在数据量少时可能看不出来；步骤只保留四次点击，去掉了登录、打开浏览器等无关动作；实际结果只写观察到的列表条数和筛选框状态，没有写“应该是前端状态没保存”这类推测；影响范围说明不阻断主流程，为分级提供依据。
常见写法问题可以对照修正：
- 步骤笼统，如“测试订单筛选功能，发现有问题”，改为编号的具体点击路径；
- 缺环境，如只写“浏览器里复现”，补上浏览器版本、账号角色与数据条件；
- 用结论代替现象，如“分页组件有 bug”，改为描述列表实际展示的内容；
- 期望结果空泛，如“应该正常”，改为写明筛选条件应保持的具体表现。
提交前的完成检查
提交前用下面这份清单逐项过一遍，全部通过再提交。任何一项不通过，先补齐再提交，不要指望受理环节兜底。
| 检查项 | 通过标准 | 阻断条件 |
|---|---|---|
| 可复现性 | 按记录步骤连续执行两次以上，现象一致；偶现问题已注明出现次数比例 | 步骤无法照做，或现象无法再次出现且未说明概率 |
| 步骤完整性 | 每步一个动作，含必要输入值，无“等等”“相关操作”这类省略 | 存在需要读者猜测的操作 |
| 环境信息 | 设备、系统与版本、账号角色、服务端环境齐全 | 缺少任一项且该差异可能影响结果 |
| 证据完整性 | 至少一项证据能对应到具体步骤环节，日志含时间点 | 仅有文字描述，无截图、录屏或日志 |
| 标题与描述 | 只写对象与现象，实际结果不含原因推测 | 标题或正文以推测结论代替现象描述 |
| 重复检索 | 已按关键词和模块检索，确认无相同或高度相似的未关闭记录 | 存在相同记录却未关联，造成重复提交 |
| 模块与提交对象 | 模块选择到可负责的最小范围，提交至正确项目或迭代 | 模块归属明显错误，处理人无法对应 |
检查不通过时的处理方式按缺口类型区分：步骤或环境缺失，回到复现环节补做并更新记录；证据不足，补采集后再提交；检索到重复记录，改为在原记录下补充差异信息并关联，不再新建；模块归属不确定，先与测试负责人确认再提交。把这些动作做在提交之前，缺陷记录进入受理环节时就是可用的，后续定位与验证也有了可靠起点。
常见问题
偶现缺陷（不是每次都能复现）该怎么提交？
偶现缺陷同样可以提交，重点是把出现条件写清楚。记录出现次数与尝试次数的比例，例如“10 次操作出现 3 次”；写明出现时的账号、环境、数据状态和操作路径；附上出现时的日志与录屏，标注时间点。步骤部分按最接近复现的路径写，并注明“偶现，非每次触发”。这样开发可以据此判断是并发、时序还是数据相关的问题，而不是简单以“无法复现”退回。
提交后发现信息写错了或漏了，还能改吗？
可以补充和修正，越早越好。记录进入待受理状态后，提交人应主动在记录上补充遗漏的环境信息、证据或步骤细节，并在说明中写清补充内容。若受理人已按原信息做出判断，补充后应提醒其重新确认。把补充动作放在受理之前，能减少退回和重复沟通；已经受理的记录补充信息时，注明变更点，便于开发对照最新内容复现。
检索到相似记录，是新建还是补充到原记录？
先判断是否为同一问题。现象、触发路径和影响对象一致时，补充到原记录下，写清本次出现的环境差异、复现概率和新增证据，并关联原记录，不再新建。若现象相似但触发条件明显不同，例如不同模块或不同操作路径导致，可新建记录并在描述中关联原记录，说明差异点。判断不确定时，先与测试或缺陷管理负责人确认归属，避免同一问题分散在多条记录里。
开发以“无法复现”退回时，提交人下一步做什么？
先看退回意见是否指出了具体缺口。若意见笼统，请开发说明在哪一步、哪个环境、缺少哪类信息，把退回变成可执行的补充要求。提交人按缺口补做：环境差异导致无法复现的，补充账号角色与数据条件；步骤有歧义的，细化到具体点击位置和输入值；偶现问题，补充出现比例与日志时间点。补充完成后更新记录并通知开发重新确认，形成闭环。
团队用缺陷管理工具时，提交环节要注意什么？
工具承担的是记录承载与流转，填写标准仍由团队约定。提交时确认所属模块选到能负责的最小范围、提交到正确的项目或迭代、处理人可见；必填字段按团队规范填全，附件上传到对应记录。以 ONES 为例，未通过的测试用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷也可一键提交至对应项目或迭代，记录和跟踪修复情况；具体字段与流转配置以团队实际部署为准。
