缺陷报告最常见的返工，是提交人只写了一句“某功能报错”，测试、开发和产品随后在群里来回追问环境、步骤和影响。一份结构清楚的缺陷报告模板，能让提交人一次写清“在哪、做了什么、期望什么、实际什么、影响多大、怎么复现”。下面给出一张可直接复制到文档或缺陷系统的空白表，逐字段说明填写口径，区分必填与选填，并用一条完整示例示范如何从空白填到可用。
要点总览（TL;DR）
- 缺陷报告模板按基本信息、环境、复现步骤、期望与实际、影响与附件五组组织，复制到文档或缺陷系统即可使用。
- 默认必填集合覆盖标题、模块、版本、运行环境、复现步骤、期望结果、实际结果、严重程度和报告人，保证缺陷能被独立理解和复现。
- 填写口径围绕可观察、可复现、可定位：标题写清模块与现象，步骤编号并带输入数据，期望结果引用需求条款，实际结果记录可观察现象。
- 必填项可按缺陷类型和阶段调整，界面类问题可要求附件，系统测试与回归阶段应收紧，调整后记录生效时间。
- 模板维护靠变更判断条件与版本记录，定期抽查填写质量并把高频返工点写回模板提示语。
可复制缺陷报告空白模板
下表按“基本信息、环境、复现步骤、期望与实际、影响与附件”五组排列，复制到 Word、在线文档或缺陷系统的新建表单中即可使用。表格中的提示语是填写引导，正式提交时可删除。
| 分组 | 字段 | 填写内容（示例提示） |
|---|---|---|
| 基本信息 | 缺陷标题 | 用“模块 + 操作 + 异常现象”概括，一句话说清问题 |
| 缺陷编号 | 由缺陷系统自动生成，手工表可留空或按团队规则编号 | |
| 所属模块/功能 | 填写出问题的页面、接口或业务模块名称 | |
| 报告人 / 发现日期 | 提交人姓名与发现问题的日期时间 | |
| 缺陷类型 | 功能错误、界面问题、数据问题、性能问题、兼容性问题等 | |
| 环境 | 软件版本 / 构建号 | 被测系统的版本号或构建标识 |
| 运行环境 | 操作系统、浏览器及版本、App 版本、设备型号 | |
| 测试环境地址 | 测试、预发或生产环境，附访问地址或账号说明 | |
| 前置条件 | 复现前需要满足的数据、权限、配置状态 | |
| 复现步骤 | 操作步骤 | 按 1、2、3 编号，每步一个动作，写清输入的数据 |
| 复现频率 | 必现、偶现（约几次出现几次）、仅出现一次 | |
| 期望与实际 | 期望结果 | 按需求文档或业务规则应出现的结果 |
| 实际结果 | 实际观察到的现象，含报错文案、错误数据或界面表现 | |
| 影响与附件 | 严重程度 | 按团队分级口径填写，说明对业务或用户的影响 |
| 优先级 | 按团队约定填写期望的处理顺序 | |
| 附件 | 截图、录屏、日志片段、请求响应、测试数据文件 | |
| 关联需求 / 备注 | 关联的需求单号、同类缺陷编号或补充说明 |
如果团队使用缺陷管理系统，可以把这张表当作字段清单，在系统中建立同名自定义字段；ONES 工作项支持自定义字段与附件，可作为缺陷报告的承载载体，字段名称与上表保持一致即可减少迁移成本。
每个字段写什么：字段说明与填写口径
同一字段在不同人手里写出不同内容，是缺陷报告质量波动的主要原因。下面逐项说明含义和写法要求，核心标准是三条：可观察、可复现、可定位。
基本信息类字段
- 缺陷标题：写“在哪个模块、做了什么操作、出现什么异常”，例如“订单列表按日期筛选后分页跳回第一页”。标题里放结论，细节留给正文，避免只写“有 bug”“页面异常”。
- 所属模块/功能：写到能定位责任范围的粒度，如“订单管理-订单列表”，便于分派和统计。
- 缺陷类型：按团队已有分类选择，用于后续归类分析；分类标准本身由团队统一维护。
- 报告人 / 发现日期：记录提交人和首次发现时间，便于追溯问题出现的时间窗口。
环境类字段
- 软件版本 / 构建号：写明具体版本，避免“最新版”这类无法核对的描述。
- 运行环境：操作系统、浏览器及版本、设备型号、App 版本等，凡与问题相关的都写。
- 测试环境地址：区分测试、预发、生产环境，生产环境问题需注明影响范围。
- 前置条件：复现前必须满足的状态，如“账号已开通退款权限”“购物车中已有 3 件商品”。前置条件写清楚，能显著减少“我这边复现不了”的情况。
复现步骤与结果类字段
- 操作步骤：编号书写，每步一个动作，包含输入的具体数据。步骤要能让没参与测试的人照着走一遍。
- 复现频率：区分必现与偶现，偶现问题注明尝试次数和出现次数，帮助判断是否与数据或时序有关。
- 期望结果：引用需求文档条款或业务规则，说明“应该是什么样”，而不是简单写“应该正常”。
- 实际结果：描述观察到的现象，附报错原文、错误数据截图或日志片段，避免主观评价词。
影响与附件类字段
- 严重程度：填写口径是“描述该缺陷对业务、数据或用户的实际影响”，例如是否阻断主流程、是否造成数据错误。具体分级标准由团队另行约定，本文不展开判定方法。
- 优先级：填写口径是“结合影响与当前迭代安排，给出期望的处理顺序”，由提交人与负责人协商确定。
- 附件：截图标注关键位置，录屏控制在能说明问题的长度，日志截取相关时间段。
- 关联需求 / 备注：填写需求单号、同类缺陷编号或补充背景，方便后续合并与追踪。
必填与选填怎么划分
必填字段的作用是保证缺陷能被独立理解和复现，选填字段用于补充定位信息。默认建议如下表，团队可直接采用，再按项目情况微调。
| 字段 | 默认设置 | 理由 / 适用场景 |
|---|---|---|
| 缺陷标题 | 必填 | 决定缺陷能否被快速识别和检索 |
| 所属模块/功能 | 必填 | 分派与统计的基础 |
| 软件版本 / 构建号 | 必填 | 没有版本信息无法判断问题是否已修复 |
| 运行环境 | 必填 | 环境差异是常见诱因 |
| 复现步骤 | 必填 | 缺陷可复现的核心依据 |
| 期望结果 | 必填 | 明确判断标准，减少争议 |
| 实际结果 | 必填 | 问题现象的直接记录 |
| 严重程度 | 必填 | 影响处理排序与资源投入 |
| 报告人 / 发现日期 | 必填 | 追溯与沟通需要 |
| 前置条件 | 选填 | 步骤本身已包含前置状态时可省略 |
| 复现频率 | 选填 | 偶现问题建议填写，必现问题可省略 |
| 优先级 | 选填 | 由负责人评估时可不要求提交人填写 |
| 附件 | 选填 | 界面、数据类问题建议附截图；纯文案问题可省略 |
| 缺陷类型 | 选填 | 需要按类型统计时设为必填 |
| 关联需求 / 备注 | 选填 | 有明确需求来源时填写 |
按缺陷类型调整时，界面与兼容性问题可把“附件”设为必填，数据问题可把“前置条件”和“测试数据”设为必填。按阶段调整时，需求评审或开发自测阶段可放宽必填项，系统测试与上线前回归阶段应收紧，保证缺陷记录完整可查。调整后要在模板变更记录中注明生效时间。
完整填写示例：一条缺陷报告从空白到可用
下面用一条订单模块的缺陷示范填写，覆盖上表全部必填字段，写法与字段说明逐项对应。
| 字段 | 填写内容 |
|---|---|
| 缺陷标题 | 订单列表按日期筛选后翻页，页码跳回第一页 |
| 缺陷编号 | BUG-20240612-0031（系统生成） |
| 所属模块/功能 | 订单管理-订单列表 |
| 报告人 / 发现日期 | 李敏 / 2024-06-12 10:20 |
| 缺陷类型 | 功能错误 |
| 软件版本 / 构建号 | v3.8.2（构建 20240610-1） |
| 运行环境 | Windows 11、Chrome 125；测试环境 test.example.com |
| 前置条件 | 测试账号已登录，订单列表中存在 120 条以上订单数据 |
| 操作步骤 | 1. 进入“订单管理-订单列表”；2. 在日期筛选中选择“2024-06-01 至 2024-06-10”，点击查询；3. 在结果列表底部点击“第 2 页”；4. 观察页码与筛选条件 |
| 复现频率 | 必现，连续操作 3 次均出现 |
| 期望结果 | 翻到第 2 页后仍保留日期筛选条件，列表展示筛选结果的第 2 页数据（需求文档 ORD-112 第 4.3 节） |
| 实际结果 | 点击第 2 页后，日期筛选条件被清空，列表跳回第 1 页并展示全部订单，页码显示为 1 |
| 严重程度 | 影响订单查询效率，筛选结果无法翻页查看，主流程可用但数据查看受阻 |
| 优先级 | 建议本迭代内修复 |
| 附件 | 操作录屏 1 段（约 20 秒）、第 2 页筛选条件清空后的截图 1 张 |
| 关联需求 / 备注 | 关联需求 ORD-112；同类问题见 BUG-20240528-0017 |
这条示例的可用之处在于：开发人员按步骤能独立复现，期望结果有需求条款支撑，实际结果描述了可观察现象，附件补充了动态过程。提交前可以自查一遍：标题能否独立看懂、步骤能否照着走通、期望与实际是否形成对照、影响是否写清。
模板的调整与维护方法
模板上线后容易走向两个极端：字段越加越多，提交人开始敷衍填写；或者长期不更新，字段与实际业务脱节。维护的关键是给变更设定判断条件，并留下记录。
新增字段的判断条件
满足以下任一条件时考虑新增字段：同类信息在备注或聊天中反复出现，且影响分派或复现；团队需要按该维度做统计；外部流程（如客户支持、合规审计）要求单独记录。新增前先确认现有字段无法承载，避免同一信息出现两个入口。
字段合并与删除的时机
连续两个统计周期内某字段填写率很低，或填写内容与另一字段高度重复，可以合并或删除。删除前先导出历史数据或保留字段说明，避免旧缺陷记录失去上下文。合并时在变更记录中写明“原字段 A 并入字段 B”。
模板版本与变更记录
建议用一张简单的变更记录表管理模板版本：
| 版本 | 变更日期 | 变更内容 | 生效范围 | 负责人 |
|---|---|---|---|---|
| v1.0 | 2024-06-01 | 初始版本，确定必填字段集合 | 全部项目 | 测试负责人 |
| v1.1 | 2024-07-15 | 界面类缺陷将“附件”设为必填 | 客户端项目 | 测试负责人 |
| v1.2 | 2024-09-02 | “复现频率”并入“复现步骤”说明 | 全部项目 | 质量负责人 |
在缺陷系统中维护模板时，可以把字段调整与版本记录同步到工作项配置中。ONES 工作项支持自定义字段与状态流转，字段变更后新提交的缺陷按新模板填写，历史缺陷保留原记录，便于对照。
定期回看填写质量
每月抽取一批缺陷报告，检查必填字段是否完整、复现步骤能否照着走通、期望与实际是否成对出现。把返工较多的字段整理成填写提示，放回模板的提示语中。回看结果不必做成复杂报表，一张抽查清单加几条改进动作即可，重点是让模板持续贴合实际提交习惯。
常见问题
缺陷报告里严重程度和优先级都由提交人填吗？
不一定。严重程度通常要求提交人描述缺陷对业务、数据或用户的实际影响，作为分级依据；优先级可以只由提交人给出建议，最终由开发负责人或产品负责人结合迭代安排确定。团队可以在模板中把优先级设为选填，避免提交人因不了解排期而随意填写。具体分级标准属于缺陷分类与分级主题，本文只保留填写口径。
偶现缺陷按模板填了步骤还是复现不了，怎么办？
先在“复现频率”中写清尝试次数与出现次数，例如“操作 10 次出现 2 次”，并在附件中补充录屏或日志时间段。前置条件也要写细，包括账号权限、数据状态和操作时序。若仍无法稳定复现，可以在备注中记录出现时的环境与时间点，便于开发结合日志排查。模板的作用是把已知信息写全，偶现问题本身需要后续跟踪补充。
团队已经有缺陷系统，还需要单独维护这张空白表吗？
可以把空白表当作字段清单使用：在系统中建立同名自定义字段，字段名称与表格保持一致，模板就变成填写规范的说明文档。ONES 工作项支持自定义字段与附件，可作为缺陷报告的承载载体。系统表单负责录入和流转，空白表负责说明每个字段写什么，两者配合能减少新成员上手时的理解成本。
模板字段加得越多，缺陷报告质量会越高吗？
字段数量与报告质量没有必然关系。字段过多会增加提交负担，导致敷衍填写或大量留空。新增字段前先确认现有字段无法承载该信息，并判断它是否影响分派、复现或统计。连续两个统计周期填写率很低的字段，可以考虑合并或删除，删除前保留历史数据与字段说明。
不同项目能用同一套必填规则吗？
可以先用默认必填集合作为基线，再按项目类型调整。客户端项目可把附件设为必填，数据类项目可要求填写前置条件和测试数据；开发自测阶段可放宽，系统测试与上线前回归阶段应收紧。每次调整在变更记录中注明生效范围和生效时间，避免新旧项目填写口径混用。
