缺陷摘要模板要解决两个常见问题：记录缺项导致缺陷无法复现或分派，以及把根因猜测写成结论。本文提供一张可直接复制的空白表，必填字段覆盖问题现象、影响范围、复现条件、环境与版本、严重程度、根因线索、待确认项和责任人；待确认项单独成列，记录尚未验证的假设、缺失证据和需要回问的对象。缺陷摘要最终通常落到缺陷工作项或知识库文档中流转，ONES 可作为承载这类记录的协作环境之一。
要点总览（TL;DR）
- 缺陷摘要模板以一张空白表为核心，摘要区记录已观察到的事实，待确认区记录尚未验证的内容，两段分开填写。
- 必填字段包括缺陷标题、问题现象、影响范围、复现条件、环境与版本、严重程度和责任人；根因线索与待确认项在对应阶段条件必填。
- 问题现象只写可观察结果，根因线索标明是观察还是推测，待确认项拆成待验证假设、缺失证据、回问对象和确认期限。
- 模板需按缺陷类型裁剪字段，与缺陷单系统字段命名对齐，并记录版本变更、定期复盘字段使用率。
- 缺陷摘要最终落到缺陷工作项或知识库文档中流转，ONES 可作为承载记录并随状态更新的协作环境之一。
可复制空白缺陷摘要模板
下表按“摘要区—待确认区”两段组织。摘要区记录已经观察到的事实，待确认区记录尚未验证的内容。复制到缺陷单、Wiki 页面或需求文档时，保留表头即可，行数按实际条目增减。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 摘要区 | 缺陷标题 | |
| 问题现象 | ||
| 影响范围 | ||
| 复现条件 | ||
| 环境与版本 | ||
| 严重程度 | ||
| 根因线索 | ||
| 责任人 | ||
| 发现时间与来源 | ||
| 待确认区 | 待验证假设 | |
| 缺失证据 | ||
| 回问对象 | ||
| 确认期限 |
如果缺陷单系统本身已有标题、状态、指派人等字段，模板中的“缺陷标题”“责任人”可与系统字段合并，只保留系统未覆盖的摘要内容。待确认区建议始终保留，它是这张模板区别于普通缺陷描述的关键部分。
字段说明与填写口径
同一份模板被不同人填写时，差异往往出在写法上。下面逐字段说明含义、推荐写法和常见错误，团队可据此形成统一的填写口径。
| 字段 | 含义 | 推荐写法 | 常见错误 |
|---|---|---|---|
| 缺陷标题 | 一句话概括问题 | 对象＋异常动作＋结果，如“订单导出超过500条时文件为空” | 只写“导出有问题”，无法区分具体场景 |
| 问题现象 | 可观察到的结果 | 写用户看到什么、系统返回什么，附错误提示原文或截图位置 | 混入原因判断，如“因为缓存没刷新导致报错” |
| 影响范围 | 受影响的用户、模块、数据 | 写清角色、功能模块、数据范围与是否阻断主流程 | 只写“影响较大”，缺少可判断的边界 |
| 复现条件 | 触发问题的前置状态与操作 | 按步骤编号，标注出现频率（必现、偶现及大致比例）和必要的前置数据 | 只写“按正常流程操作”，遗漏账号权限、数据量等前提 |
| 环境与版本 | 问题发生的运行环境 | 记录环境类型、客户端或服务端版本、浏览器或设备、相关配置项 | 只写“测试环境”，无法判断是否与线上一致 |
| 严重程度 | 问题对业务的影响等级 | 按团队既有分级填写，并附一句判断理由 | 按修复难度定级，导致简单但影响大的问题被低估 |
| 根因线索 | 支持定位的观察与推测 | 写日志片段、报错堆栈、可疑变更、最近改动范围，并标明是观察还是推测 | 直接写成“根因是××”，把推测当结论 |
| 责任人 | 当前处理人或待分派对象 | 写具体人员或角色，未确定时写明“待分派”及建议归属 | 留空，导致缺陷长期无人跟进 |
| 待验证假设 | 尚未证实的可能原因 | 每条假设单独一行，写清验证方式 | 与根因线索混写，读者无法区分确定与不确定 |
| 缺失证据 | 判断所需但尚未取得的信息 | 列出缺什么，如完整日志、用户操作录屏、数据库快照 | 只写“信息不足”，未说明缺哪一项 |
| 回问对象 | 需要补充信息的人或团队 | 写具体角色或人员，并注明需要对方提供什么 | 写“相关同事”，无法落实 |
| 确认期限 | 待确认项的关闭时间 | 写日期或相对时限，与缺陷处理节奏匹配 | 不设期限，待确认项长期悬空 |
问题现象与根因线索要分开写，是这张模板最重要的口径。现象只描述“发生了什么”，根因线索描述“可能和什么有关”。待确认项则进一步把“可能”拆成可验证的假设、缺的证据和要问的人，三者各占一行，避免一段话里同时出现事实与猜测。
必填与选填的划分
字段是否必填，取决于缺陷当前处于哪个处理阶段，以及团队对记录完整度的要求。下表给出三档划分和判断依据，团队可在此基础上调整。
| 档位 | 字段 | 判断依据 |
|---|---|---|
| 必填 | 缺陷标题、问题现象、影响范围、复现条件、环境与版本、严重程度、责任人 | 缺少任一项，接手人无法判断问题是什么、影响多大、如何重现、由谁处理 |
| 条件必填 | 根因线索 | 缺陷进入定位或修复阶段时必填；刚提交、尚未分析的缺陷可先留空并注明“待分析” |
| 条件必填 | 待验证假设、缺失证据、回问对象 | 存在未证实判断或信息缺口时必填；问题已定位清楚、证据齐全时可在待确认区写“无” |
| 条件必填 | 确认期限 | 待确认区有内容时填写，用于跟踪关闭 |
| 选填 | 发现时间与来源 | 需要统计缺陷来源分布或做质量复盘时填写，日常流转可省略 |
缺字段时的处理方式建议统一：提交阶段缺必填项，缺陷单退回补充，不进入分派；处理阶段缺根因线索，由责任人在缺陷单中标注“待分析”并给出预计补充时间；待确认区有内容但缺回问对象，视为待确认项未建立，不能据此关闭缺陷。这样处理可以让“缺什么”变成可见的状态，而不是靠口头提醒。
填写示例：一条完整缺陷摘要
以下示例为演示情景，用于说明字段如何落地，不对应真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 缺陷标题 | 订单列表按金额排序后翻页，第二页出现重复订单 |
| 问题现象 | 在订单列表选择“按金额降序”后翻到第二页，页面出现与第一页重复的订单编号；切换回默认排序后重复消失 |
| 影响范围 | 运营角色使用的订单列表页；影响按金额排序的翻页浏览；涉及订单查询结果展示，不影响订单数据本身 |
| 复现条件 | 1. 使用具备订单查看权限的运营账号登录；2. 订单数据量约 2000 条；3. 选择按金额降序；4. 翻至第二页。出现频率：必现 |
| 环境与版本 | 测试环境；Web 端当前迭代版本；Chrome 浏览器；订单服务使用默认分页配置 |
| 严重程度 | 中：影响运营核对订单的效率，不阻断下单与支付主流程 |
| 根因线索 | 观察：接口返回的第二页数据中订单编号与第一页存在重叠；推测：排序字段存在相同值时，分页缺少稳定的次级排序条件 |
| 责任人 | 订单服务开发负责人（待分派至具体人员） |
| 发现时间与来源 | 本轮回归测试中发现 |
| 待验证假设 | 假设一：金额相同的订单在排序中位置不稳定，导致分页边界重复；验证方式为构造金额相同的订单数据后复查分页结果 |
| 缺失证据 | 缺少分页接口的完整请求与响应记录；缺少金额相同订单的实际数据分布 |
| 回问对象 | 订单服务开发负责人：确认当前分页排序是否包含订单编号作为次级排序字段 |
| 确认期限 | 本迭代提测后两个工作日内 |
对比根因线索与结论的写法：本示例写“推测分页缺少稳定次级排序”，并给出验证方式，属于线索；如果写成“分页排序逻辑有缺陷，需修改排序字段”，就是把未验证的判断当成了结论。前者保留在待确认区继续验证，后者容易让修复方向被过早锁定。示例中的字段与第一节空白模板一一对应，团队可直接照此格式填写。
模板的调整与维护方法
模板要长期可用，需要按缺陷类型裁剪字段，并与缺陷单系统保持一致。以下规则可作为维护清单。
- 按缺陷类型增减字段：界面类缺陷强化问题现象与截图位置；性能类缺陷增加数据量、并发条件和耗时数据；数据类缺陷增加数据范围与校验方式；兼容性缺陷细化环境与版本。增减字段时同步更新字段说明表。
- 字段命名与缺陷单系统对齐：模板字段名尽量沿用缺陷单中的字段名，避免同一概念出现两种叫法。系统已有字段在模板中标注“同系统字段”，减少重复填写。
- 版本与变更记录：模板每次调整记录版本号、调整字段、调整原因和生效日期，旧缺陷单保留原模板版本，便于回溯。
- 定期复盘字段使用率：按季度统计各字段的填写率和待确认项的关闭率，长期空置的选填字段考虑删除，频繁补填的字段考虑升级为必填。
- 待确认项的闭环检查：复盘时抽查已关闭缺陷，确认待确认区是否在关闭前完成验证或明确标注“不影响结论”，避免猜测随缺陷关闭被默认成事实。
当缺陷摘要需要在团队内流转时，模板字段与缺陷工作项的字段保持一致会明显减少重复录入。ONES 支持创建缺陷、更新缺陷状态并通知项目负责人，ONES Assistant 可理解项目、工作项、迭代和 Wiki 页面等工作上下文并执行后续操作，缺陷摘要可作为工作项描述或关联文档存放，便于在分派、定位和关闭过程中持续补充待确认项。团队可将模板字段映射到缺陷工作项的对应属性，让摘要区与待确认区随状态流转同步更新。
常见问题
缺陷刚提交、还没开始分析时，根因线索和待确认项怎么填？
提交阶段可以先不写根因线索，在对应位置标注“待分析”并给出预计补充时间。待确认区如果暂时没有明确假设，可先记录缺失证据和回问对象，例如缺少完整日志、需要向提测人确认操作步骤。等缺陷进入定位阶段，再补充待验证假设和确认期限。这样处理能让“还没分析”成为可见状态，接手人知道下一步该补什么。
待确认项和根因线索有什么区别，能不能合并成一栏？
两者记录的内容不同。根因线索是当前已有的观察和推测，例如日志片段、可疑变更、报错堆栈；待确认项是把不确定部分拆成可执行的动作，包括待验证假设、缺失证据、回问对象和确认期限。合并成一栏容易出现一段话里事实与猜测混杂，后续验证时难以逐条关闭。建议保留两栏，根因线索写“可能和什么有关”，待确认项写“怎么验证、缺什么、问谁”。
团队已有缺陷单系统字段，模板里的标题和责任人还要重复填吗？
不需要重复填写。模板字段名尽量沿用缺陷单系统中的字段名，系统已有的标题、状态、指派人等字段在模板中标注“同系统字段”，只保留系统未覆盖的摘要内容。待确认区建议始终保留，因为多数缺陷单系统没有专门记录未验证假设和缺失证据的字段。字段对齐后，摘要内容可以直接映射到缺陷工作项属性，减少二次录入。
不同缺陷类型都要用同一张模板吗？
可以共用一张基础模板，再按缺陷类型增减字段。界面类缺陷强化问题现象和截图位置；性能类缺陷增加数据量、并发条件和耗时数据；数据类缺陷增加数据范围与校验方式；兼容性缺陷细化环境与版本。增减字段时同步更新字段说明表，并记录模板版本与生效日期，旧缺陷单保留原版本便于回溯。
待确认项一直没人跟进，缺陷却关闭了，怎么避免？
在关闭缺陷前增加一道检查：待确认区的内容要么已完成验证并写明结论，要么明确标注“不影响结论”及理由。复盘时抽查已关闭缺陷，统计待确认项的关闭率。如果某类待确认项频繁悬空，可考虑在缺陷工作项中设置必填的确认期限字段，让待确认项随状态流转被持续跟踪，避免猜测随缺陷关闭被默认成事实。
