缺陷摘要模板的必填字段通常包括问题现象、影响范围和复现条件三项，根因线索与待确认项按掌握程度填写。待确认项需要写明待确认内容、确认人和确认时点，把已确认结论与待核实线索分开，避免摘要把猜测写成结论。以下提供一份可直接复制的空白表格，并逐字段说明填写口径、必填判定和完整示例。
要点总览（TL;DR）
- 缺陷摘要模板以问题现象、影响范围、复现条件三组为必填，缺少任一项他人难以判断缺陷是否成立、影响多大或能否复现。
- 根因线索按掌握程度填写，只写怀疑方向与依据并注明是否已验证，根因结论留到验证完成后写入处理记录。
- 待确认项一条一行，必须同时写明待确认内容、确认人和确认时点，内容写成可回答的问题，确认人落到能拍板的角色。
- 空缺统一用“未知”“待确认”“不适用”三种写法区分含义，避免评审者误判缺陷成熟度。
- 模板可按项目类型增删辅助字段，核心三组保持稳定；变更记录版本号并同步更新字段说明与示例。
可复制空白缺陷摘要模板
下表可直接复制到文档、缺陷单描述或测试记录中填写。五组字段按“先描述事实、再给线索、最后列待确认”的顺序排列，待确认项单独成列，便于评审时逐条核对。
| 字段组 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 缺陷编号 | |
| 基本信息 | 缺陷标题 | |
| 基本信息 | 发现人 / 发现时间 | |
| 基本信息 | 所属模块 / 版本 | |
| 问题现象 | 实际表现 | |
| 问题现象 | 预期表现 | |
| 影响范围 | 受影响用户 / 角色 | |
| 影响范围 | 受影响功能 / 数据 | |
| 影响范围 | 严重程度判断 | |
| 复现条件 | 环境 | |
| 复现条件 | 前置数据 / 状态 | |
| 复现条件 | 操作步骤 | |
| 复现条件 | 复现概率 | |
| 根因线索 | 线索描述 | |
| 根因线索 | 线索来源 | |
| 待确认项 | 待确认内容 | |
| 待确认项 | 确认人 | |
| 待确认项 | 确认时点 | |
| 待确认项 | 当前状态 |
待确认项一行对应一个待核实问题。存在多个待确认问题时，复制该组行继续填写，不要在一格内堆叠多条内容，否则确认人难以逐条关闭。
字段说明：每个字段写什么、写到什么颗粒度
缺陷摘要的作用是让未参与测试的人快速判断“出了什么问题、影响多大、能否复现、可能原因是什么、还有哪些没核实”。字段填写围绕这五个问题展开，描述事实与推测时使用不同字段承载。
| 字段 | 写什么 | 颗粒度与边界 |
|---|---|---|
| 实际表现 | 用户看到的错误结果、报错信息或异常状态 | 写可观察到的现象，如“提交订单后页面停留在加载状态，控制台报 500”；不写“系统有问题”这类无法验证的描述 |
| 预期表现 | 按需求或常识应当出现的结果 | 一句话说明正确行为，便于对照判断 |
| 受影响用户 / 角色 | 哪些角色会遇到该问题 | 写角色或用户群体，如“使用批量导入的运营人员”；范围不明时写“待确认”并列入待确认项 |
| 受影响功能 / 数据 | 涉及的功能模块和数据对象 | 写到模块和数据级别，如“订单导出功能，近 7 天订单数据” |
| 严重程度判断 | 对业务的影响程度及判断依据 | 给出等级和理由，如“严重：核心流程阻断，无临时绕过方式” |
| 环境 | 操作系统、浏览器、设备、测试环境或版本 | 写到能据此搭建相同环境的程度 |
| 前置数据 / 状态 | 复现前需要准备的账号、数据或系统状态 | 列出关键前置条件，避免他人因数据差异无法复现 |
| 操作步骤 | 从起点到出现问题的操作序列 | 按顺序编号，每步一个动作，包含关键输入值 |
| 复现概率 | 尝试次数与出现次数 | 写“5 次出现 3 次”这类可核对的比例；仅出现一次时注明 |
| 线索描述 | 日志、报错堆栈、代码位置、近期变更等指向性信息 | 写线索及其指向，不写成定论；无法确认时说明线索强度 |
| 线索来源 | 线索来自日志、监控、代码审查还是他人反馈 | 便于后续核实和追溯 |
| 待确认内容 | 尚未核实、需要他人判断的问题 | 一条一行，写成可回答的问题，如“该报错是否由昨日发布的缓存配置变更引起” |
| 确认人 | 负责给出结论的人 | 写具体角色或姓名，如“后端负责人”“产品经理” |
| 确认时点 | 期望确认的时间或触发节点 | 写日期或节点，如“修复排期评审前”“本周五前” |
| 当前状态 | 待确认项的进展 | 用“待确认 / 已确认 / 已排除”等有限状态，便于汇总 |
根因线索与根因结论的区别在于确定性。线索字段记录“怀疑与什么有关、依据是什么”，例如“错误集中在调用库存接口之后，怀疑与库存服务超时有关，尚未验证”。根因结论应在验证完成后写入缺陷处理记录或关闭说明，摘要中保留线索原文即可，避免后续读者把推测当成事实。
待确认项的写法要满足三个条件：内容可回答、确认人明确、时点可执行。“待确认内容”避免写“再看看”“原因不明”，应写成具体问题；“确认人”避免写“相关同事”，应落到能拍板的角色；“确认时点”避免空缺，至少给出相对节点。
必填与选填：哪些字段不能空
必填字段的选择标准是：缺少该信息，其他人无法判断缺陷是否成立、影响多大或能否复现。按此标准划分如下。
| 类别 | 字段 | 空缺时的处理 |
|---|---|---|
| 必填 | 缺陷标题、实际表现、预期表现、受影响功能 / 数据、环境、操作步骤、复现概率 | 不允许留空；确实无法获取时填写“未知”并说明原因，同时列入待确认项 |
| 条件必填 | 前置数据 / 状态、受影响用户 / 角色、严重程度判断 | 复现依赖特定数据时必须填写前置条件；影响面涉及多角色时填写用户范围；进入排期前必须给出严重程度 |
| 选填 | 根因线索、线索来源、缺陷编号、发现人 / 发现时间、所属模块 / 版本 | 无线索时留空或写“暂无”；编号和时间通常由工具自动生成 |
| 按需填写 | 待确认项各列 | 没有待确认问题时整组留空；一旦填写，待确认内容、确认人、确认时点三列必须同时填写 |
空缺标注建议统一用“未知”“待确认”“不适用”三种写法，并区分含义：“未知”表示信息尚未获取，“待确认”表示已有疑问等待核实，“不适用”表示该字段在当前缺陷中确实不需要。三种写法混用会让评审者误判缺陷成熟度，团队应在模板说明中固定用法。
缺陷摘要填写完成后，通常会进入缺陷单流转：测试人员提交，开发人员确认复现并补充根因线索，产品人员判断影响范围，待确认项随状态变化逐条关闭。在 ONES 中，缺陷可以作为工作项承载这些字段，待确认项通过状态和负责人跟踪，ONES Assistant 智能助手能够理解项目、工作项和迭代等真实工作上下文，基于相关项目数据回答问题并执行后续操作，便于在缺陷评审时快速调取上下文。围绕缺陷分布，ONES Assistant 还可生成进展分析和根因判断，供管理者在排期和资源安排时参考。
填写示例：一条缺陷摘要的完整填写
以下示例为演示情景，展示各字段在模板、说明与示例中保持一致。示例中的系统名称和数据均为虚构。
| 字段 | 填写内容 |
|---|---|
| 缺陷标题 | 批量导入订单时超过 500 条记录导入中断且无错误提示 |
| 实际表现 | 在订单管理页使用批量导入，选择包含 600 条记录的表格后点击导入，进度条停在 60% 左右不再变化，页面无报错提示，导入结果列表为空 |
| 预期表现 | 600 条记录全部导入成功，或明确提示失败条数与原因 |
| 受影响用户 / 角色 | 使用批量导入功能的运营人员 |
| 受影响功能 / 数据 | 订单管理模块的批量导入功能，单次超过 500 条的订单数据 |
| 严重程度判断 | 严重：大批量订单无法导入，运营需拆分为多次小批量操作，属于有临时绕过方式的核心功能受阻 |
| 环境 | 测试环境，Chrome 最新稳定版，Windows 11 |
| 前置数据 / 状态 | 测试账号具备订单导入权限；准备 600 条格式正确的订单表格 |
| 操作步骤 | 1. 登录测试账号，进入订单管理页；2. 点击“批量导入”；3. 上传 600 条记录的表格；4. 点击“开始导入”；5. 观察进度与结果 |
| 复现概率 | 尝试 5 次，出现 5 次；将记录数降到 400 条时导入正常 |
| 线索描述 | 导入中断时浏览器网络面板显示导入接口返回 504，怀疑与单次请求数据量超过服务端处理时限有关，尚未验证 |
| 线索来源 | 浏览器网络面板与测试人员观察 |
| 待确认内容 | 服务端导入接口的单次数据量上限是多少，超过上限时应返回什么提示 |
| 确认人 | 订单服务后端负责人 |
| 确认时点 | 本周四修复排期评审前 |
| 当前状态 | 待确认 |
示例中“怀疑与单次请求数据量超过服务端处理时限有关”写在根因线索中，并注明“尚未验证”；对应的核实动作放入待确认项，由后端负责人在评审前给出结论。这样处理使摘要既保留了排查方向，又不把推测写成定论。若后续确认接口上限为 500 条，可将结论补充到缺陷处理记录，并将待确认项状态改为“已确认”。
调整与维护：按团队情况增删字段
模板需要随项目类型和缺陷等级调整，但调整应遵循“字段含义稳定、增删有记录”的原则，避免同一团队出现多个互不兼容的版本。
可增删的字段主要集中在辅助信息。移动端项目可增加“设备型号”“系统版本”字段；涉及接口的项目可增加“请求参数”“响应码”；安全类缺陷可增加“风险等级”“受影响数据范围”。基本信息中的编号、发现时间若由缺陷管理工具自动生成，可从模板中移除，减少重复填写。问题现象、影响范围、复现条件三组核心字段建议保持稳定，它们是判断缺陷成立与否的基础。
字段与缺陷等级可以建立对应关系。轻微缺陷允许复现条件写得简略，但实际表现和预期表现仍需填写；严重及以上缺陷要求前置数据、复现概率和影响范围完整，并至少给出一条根因线索或说明暂无线索。这种分级要求写入模板说明，由提交人在填写时自行对照，评审时按等级检查。
版本维护建议指定一名模板负责人，变更时记录版本号、变更字段、生效日期和原因，并在团队文档中保留旧版本供历史缺陷对照。模板变更后，同步更新字段说明和填写示例，确保三处一致；示例过期是模板失效的常见原因。
模板落地到缺陷管理工具时，需要做字段映射：把必填字段配置为工作项的必填项，把待确认项拆成独立字段或子任务，把状态映射为工作项状态流转。ONES 支持将缺陷作为工作项管理，ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，把自然语言指令转化为可追踪的工作，并基于权限体系执行知识问答和任务执行，输出过程可追踪、结果可审计。团队可据此把摘要模板中的待确认项转为可跟踪的工作项，在评审时逐条核对确认人和时点。具体字段配置方式以团队实际使用的产品版本为准。
常见问题
缺陷摘要里的根因线索和根因结论怎么区分，什么时候写结论？
根因线索记录的是排查方向与依据，例如“错误集中在调用库存接口之后，怀疑与库存服务超时有关，尚未验证”，读者能据此判断线索强度和后续核实方向。根因结论是验证完成后的确定判断，写入缺陷处理记录或关闭说明，摘要中保留线索原文即可。
如果验证后确认了原因，可把结论补充到处理记录，并把对应待确认项状态改为“已确认”。这样摘要始终反映提交时的信息状态，后续读者不会把推测当成事实。
待确认项由谁确认，确认人写角色还是写姓名？
确认人应落到能对该问题拍板的角色或具体人员，例如“订单服务后端负责人”“产品经理”，避免写“相关同事”这类无法追责的表述。写角色便于人员变动时交接，写姓名便于直接跟进，团队可按规模选择，关键是每条待确认项都有明确的责任人。
确认时点同样要可执行，写具体日期或触发节点，如“本周四修复排期评审前”。内容、确认人、时点三项缺一，待确认项就容易长期挂起。
缺陷等级不同，模板的填写要求需要区别对待吗？
可以建立分级要求。轻微缺陷允许复现条件写得简略，但实际表现和预期表现仍需填写；严重及以上缺陷要求前置数据、复现概率和影响范围完整，并至少给出一条根因线索或说明暂无线索。
分级要求应写入模板说明，由提交人填写时自行对照，评审时按等级检查。这样既避免轻微缺陷填写负担过重，也保证高等级缺陷的信息足够支撑排期判断。
模板字段和缺陷管理工具里的字段对不上怎么办？
落地到工具时需要做字段映射：把必填字段配置为工作项的必填项，把待确认项拆成独立字段或子任务，把状态映射为工作项状态流转。ONES 支持将缺陷作为工作项管理，团队可把摘要模板中的待确认项转为可跟踪的工作项，在评审时逐条核对确认人和时点。
映射后若工具字段与模板不完全一致，以工具实际可配置的字段为准调整模板，并在版本记录中注明差异，避免文档模板与系统字段长期脱节。具体字段配置方式以团队实际使用的产品版本为准。
模板改版后，历史缺陷的摘要要不要回填？
通常不回填。历史缺陷保留原摘要，用于对照当时的判断依据；模板变更时记录版本号、变更字段、生效日期和原因，并在团队文档中保留旧版本。新提交的缺陷按新版本填写即可。
如果变更涉及必填字段调整，需要在模板说明中标注生效范围，避免评审时用新标准要求旧缺陷，造成不必要的返工。
