缺陷报告模板的作用，是让提交人按固定字段把“在哪、什么条件下、发生了什么、期望是什么、影响多大、证据在哪”写清楚，使记录可定位、可复现、可判断。本文提供一份可直接复制到缺陷系统或文档中的空白表格，并逐字段说明填写口径、划分必填与选填，最后用一条登录失败缺陷演示完整填写方式。
要点总览（TL;DR）
- 缺陷报告模板的核心字段分六区：表头、环境、复现步骤、结果、影响与分级、证据与关联，复制空白表格即可开始填写。
- 标题按“模块+条件+现象”写，复现步骤逐条编号并交代前置条件，实际结果只写现象、期望结果引用需求或验收标准。
- 必填项以“能定位、能复现、能判断”为标准，通常包括标题、所属模块、版本、复现步骤、实际结果、期望结果和严重程度；其余按缺陷类型选填。
- 一条登录失败缺陷的完整示例演示了各字段的落地写法，附件文件名对应步骤序号、日志标注关键请求，便于处理人快速核对。
- 模板需定期维护：长期空置的字段合并或删除，枚举选项与团队分级标准保持一致，并记录版本与变更说明。
可复制空白缺陷报告模板
下面这份表格可以整体复制到缺陷管理工具的自定义字段、在线文档或邮件中。字段留空，按分区填写。如果所用工具字段数量有限，优先保留表头、环境、复现步骤、结果四个区中的核心字段。
| 分区 | 字段 | 填写内容 |
|---|---|---|
| 表头信息 | 缺陷编号 | |
| 标题 | ||
| 提交人 | ||
| 提交日期 | ||
| 所属模块 | ||
| 环境信息 | 版本 | |
| 操作系统 / 浏览器 | ||
| 设备 | ||
| 测试数据 | ||
| 复现步骤 | 前置条件 | |
| 步骤列表 | ||
| 复现频率 | ||
| 结果 | 实际结果 | |
| 期望结果 | ||
| 影响与分级 | 严重程度 | |
| 优先级 | ||
| 影响范围 | ||
| 证据与关联 | 附件 | |
| 日志 | ||
| 关联需求 / 用例 | ||
| 备注 |
复制时建议保留分区名称，它提示填写人按“先定位、再复现、后判断”的顺序组织信息，避免只写一句现象就提交。
每个字段该填什么：字段说明与填写规范
字段名称相同，写法差异往往决定缺陷能否被快速处理。下表给出每个字段的含义、填写规范和常见错误写法，可作为团队内部的填表参照。
| 字段 | 含义 | 填写规范 | 常见错误写法 |
|---|---|---|---|
| 缺陷编号 | 系统或文档中的唯一标识 | 由工具自动生成则留空；手工登记时按团队规则编号 | 手工编号与工具编号重复 |
| 标题 | 一句话概括缺陷 | 模块 + 触发条件 + 现象，控制在可检索的长度 | “登录有问题”“页面报错” |
| 提交人 / 日期 | 责任人与时间 | 工具自动记录时无需重复填写 | 只写昵称，无法对应到人 |
| 所属模块 | 缺陷所在功能区域 | 使用团队既有的模块名称，与需求或用例的归属一致 | 填“前端”“后端”这类技术层，无法定位功能 |
| 版本 | 出现缺陷的构建或发布版本 | 写到可区分的版本号，含热修复标识 | “最新版”“测试环境” |
| 操作系统 / 浏览器 | 运行环境 | 写到可复现的粒度，含版本号 | “Windows”“Chrome” |
| 设备 | 硬件或终端信息 | 机型、屏幕规格或模拟器信息，Web 端可填“不适用” | 留空或只写“手机” |
| 测试数据 | 触发缺陷所用的账号、数据 | 说明数据特征，敏感信息做脱敏 | 直接贴真实手机号、密码 |
| 前置条件 | 复现前需具备的状态 | 写清账号状态、数据准备、权限配置 | 省略，导致他人无法进入同一起点 |
| 步骤列表 | 操作路径 | 编号逐条写，一步一个动作，可照着走一遍 | 把多个动作挤在一段话里 |
| 复现频率 | 缺陷出现概率 | 写“必现”“偶现（约几次中出现几次）”并注明尝试次数 | 只写“有时出现” |
| 实际结果 | 系统真实表现 | 描述看到的现象，含提示文案、状态变化 | 与实际结果混入期望内容 |
| 期望结果 | 按需求应有的表现 | 引用需求或原型中的预期行为 | 写“应该正常”这类无法判断的表述 |
| 严重程度 | 缺陷对功能的影响程度 | 按团队分级标准选择，描述影响而非修复紧迫性 | 与优先级混用同一套判断 |
| 优先级 | 修复排期的先后 | 结合影响范围与版本计划确定 | 所有缺陷都填“高” |
| 影响范围 | 受影响的用户、功能或数据 | 说明涉及的角色、模块或数据量级 | 只写“影响较大” |
| 附件 | 截图、录屏等佐证 | 用于佐证描述，文件名体现步骤序号 | 只发截图不写文字描述 |
| 日志 | 错误日志或请求信息 | 截取相关时间段，标注关键行 | 粘贴整份日志无定位信息 |
| 关联需求 / 用例 | 缺陷对应的需求或测试用例 | 填写编号或标题，便于回溯验收标准 | 留空导致无法判断期望结果来源 |
| 备注 | 补充说明 | 写临时规避方式、历史排查线索 | 把复现步骤重复写进备注 |
标题和复现步骤是最容易写空的两项。标题按“模块 + 条件 + 现象”组织，例如“登录页 + 密码错误连续 5 次 + 未出现锁定提示”，检索时输入模块名或现象词都能命中。复现步骤按编号逐条写，每一步只包含一个动作，并在第一步之前交代前置条件，让他人从同一起点开始操作。
实际结果与期望结果分开写，是判断缺陷是否成立的基础。实际结果只描述观察到的现象，期望结果引用需求、原型或验收标准中的预期行为。两者混写会让处理人无法区分“现在怎样”和“应该怎样”。附件和日志承担佐证作用，文字描述仍需完整，避免只发一张截图就提交。
严重程度与优先级回答两个不同问题：严重程度看缺陷对功能、数据、用户的影响，优先级看在当前版本计划中的修复顺序。一个影响面小但阻塞发布的问题，可能严重程度中等而优先级高。具体分级标准由团队另行约定，本模板只要求两个字段分别填写并给出依据。
当缺陷记录需要进入流转，ONES 的缺陷工作项可以承载上述字段：标题、所属模块、版本、严重程度、优先级作为工作项属性，复现步骤与结果写在描述区，附件与关联需求挂在同一条记录上，提交后按状态推进处理。字段配置可按团队模板统一，减少每次手工补栏。
必填与选填怎么划分
必填字段的目标是保证三条：能定位到功能与版本、能照着复现、能判断是否成立。满足这三条的字段进入必填，其余按场景选填。必填项过多会拉长提交时间，降低提交意愿，划分时需要取舍。
| 字段 | 建议 | 理由 |
|---|---|---|
| 标题 | 必填 | 检索与分派的第一入口 |
| 所属模块 | 必填 | 决定由谁处理 |
| 版本 | 必填 | 判断是否为已知问题、是否已修复 |
| 复现步骤 | 必填 | 他人能独立重现 |
| 实际结果 | 必填 | 描述缺陷本身 |
| 期望结果 | 必填 | 提供判断依据 |
| 操作系统 / 浏览器 | 必填（客户端类缺陷） | 环境差异常是根因 |
| 严重程度 | 必填 | 支撑分级统计与处理排序 |
| 设备 | 选填 | 移动端、特定硬件相关时填写 |
| 测试数据 | 选填 | 依赖特定数据才能复现时填写 |
| 复现频率 | 选填 | 偶现缺陷建议填写，必现可省略 |
| 优先级 | 选填 | 可由处理人或版本负责人在分派时确定 |
| 影响范围 | 选填 | 影响面大或涉及数据时补充 |
| 附件 / 日志 | 选填 | 界面类缺陷建议附截图，接口类附日志 |
| 关联需求 / 用例 | 选填 | 有明确需求来源时填写，便于回溯 |
| 备注 | 选填 | 补充规避方式或排查线索 |
按缺陷类型调整必填项是常见做法。界面展示类缺陷把附件设为必填，接口与数据类缺陷把日志设为必填，兼容性缺陷把设备与系统版本设为必填。调整时以“缺少该字段是否会导致无法处理”为判断标准，而不是把所有可能有用的字段都设为必填。
如果团队发现提交量偏低，先检查必填项是否包含需要额外操作才能获得的信息，例如完整日志或录屏。可以把这类字段改为选填，并在处理人需要时再补充，保证最小可提交集合足够轻。
完整填写示例：一条登录失败缺陷
以下示例为演示情景，用于说明各字段如何落地，字段与前面的空白模板一一对应。
| 字段 | 填写内容 |
|---|---|
| 缺陷编号 | 由系统生成，留空 |
| 标题 | 登录页 + 密码连续输错 5 次 + 未出现账号锁定提示，仍可继续尝试 |
| 提交人 | 测试人员 A |
| 提交日期 | 2025-03-12 |
| 所属模块 | 账号与登录 |
| 版本 | v3.4.1（测试环境构建 20250310） |
| 操作系统 / 浏览器 | Windows 11 / Chrome 122.0 |
| 设备 | 桌面端，不适用 |
| 测试数据 | 测试账号 test_user_01，已激活状态 |
| 前置条件 | 账号 test_user_01 处于正常状态，未处于锁定或冻结中；登录页可正常访问 |
| 步骤列表 | 1. 打开登录页；2. 输入账号 test_user_01；3. 输入错误密码，点击登录；4. 重复步骤 3 共 5 次；5. 观察页面提示与账号状态 |
| 复现频率 | 必现，连续 3 轮均出现 |
| 实际结果 | 第 5 次输错密码后，页面仅提示“账号或密码错误”，未出现锁定提示，第 6 次仍可提交登录请求 |
| 期望结果 | 按需求文档“登录安全策略”第 2 条，连续输错 5 次后应提示账号已临时锁定，并禁止继续提交登录请求 |
| 严重程度 | 中：影响账号安全策略生效，不阻塞其他功能使用 |
| 优先级 | 高：涉及安全策略，计划在本版本修复 |
| 影响范围 | 所有使用账号密码登录的用户 |
| 附件 | step5-锁定提示缺失.png（第 5 次提交后的页面截图） |
| 日志 | 截取 10:21:03–10:21:47 登录接口返回，标注第 5、6 次请求均为 200 |
| 关联需求 / 用例 | 需求“登录安全策略”第 2 条；用例 LOGIN-014 |
| 备注 | 清除缓存后重试仍复现；其他测试账号表现一致 |
这条示例体现了几个规范要点：标题包含模块、条件和现象，可直接检索；前置条件交代了账号状态，使他人从同一起点复现；步骤逐条编号，第 5 步明确观察对象；实际结果只写看到的现象，期望结果引用需求条款，两者分开；严重程度描述影响，优先级说明排期理由；附件文件名对应步骤序号，日志标注了关键请求；关联需求与用例让处理人能回溯验收标准。
模板的调整与长期维护方法
模板需要随产品和团队变化调整，判断依据是字段是否仍在支撑定位、复现和判断。出现以下情况时考虑调整：某字段长期为空或填写内容重复，考虑合并或删除；同类信息分散在多个字段，考虑合并；新业务带来新的环境维度，考虑新增字段并设为条件必填。
- 新增字段：先确认缺少它会实际导致缺陷无法处理，再新增，并同步更新字段说明。
- 合并字段：两个字段的填写内容高度重叠时合并，保留信息量更大的名称。
- 删除字段：连续一个季度几乎无人填写且不影响处理的字段，可以删除或转为备注。
字段命名和选项值需要统一维护。严重程度、优先级、所属模块这类带枚举的字段，选项值应与团队的分级标准和模块划分保持一致，避免出现“高”“紧急”“P0”混用。选项调整时保留历史记录的映射关系，防止统计口径断裂。
模板本身建议记录版本与变更说明，写清每次调整的字段、原因和生效时间，方便提交人对照。定期回看缺陷记录质量可以用简单做法：抽取一批已关闭缺陷，检查标题是否可检索、复现步骤能否照着走通、实际结果与期望结果是否分开，统计缺失率高的字段，作为下一轮调整依据。
模板的边界也需要明确。缺陷报告模板负责单条缺陷的记录规范；缺陷分类与分级标准、服务事件的受理与处理流程、修复流程与版本发布管理属于其他主题，模板只保留相应字段入口，不在此展开判定细则。这样模板保持轻量，配套规范各自维护，字段之间通过关联项衔接。
常见问题
缺陷报告里实际结果和期望结果能不能写在同一栏？
建议分开写。实际结果只描述观察到的现象，例如提示文案、状态变化；期望结果引用需求文档、原型或验收标准中的预期行为。两者混写会让处理人难以区分“现在怎样”和“应该怎样”，也无法判断缺陷是否成立。如果所用工具只有一个描述字段，可以用小标题分段，先写实际结果，再写期望结果，并注明依据来源。
偶现缺陷的复现频率怎么写才有参考价值？
写清尝试次数和出现次数，例如“尝试 10 次出现 3 次”，比“有时出现”更有参考价值。同时补充出现时的环境、操作节奏或数据特征，帮助处理人判断是否与并发、缓存或特定数据有关。偶现缺陷建议把复现频率设为必填，并在备注中记录已尝试过的排查动作，避免重复劳动。
团队提交缺陷不积极，是不是必填项设太多了？
这是常见原因之一。先检查必填项里是否包含需要额外操作才能获得的信息，例如完整日志、录屏或特定测试数据。这类字段可以改为选填，由处理人在需要时再补充，保证最小可提交集合足够轻。同时确认必填字段在提交界面是否容易找到、是否有默认值可减少输入。调整后观察一段时间的提交量和记录质量，再决定是否继续精简。
不同缺陷类型要用同一套必填项吗？
可以共用一份基础模板，再按类型调整条件必填。界面展示类缺陷把附件设为必填，接口与数据类缺陷把日志设为必填，兼容性缺陷把设备与系统版本设为必填。判断标准是“缺少该字段是否会导致无法处理”，避免把所有可能有用的字段都设为必填。条件必填规则应写进字段说明，让提交人知道什么情况下必须补哪一项。
模板里的严重程度和优先级由提交人填还是处理人填？
两种做法都有团队采用。提交人填写时，严重程度按影响描述、优先级给出排期建议，处理人可在分派时复核调整；处理人填写时，提交人只需提供影响范围等事实信息。无论哪种分工，两个字段要分别给出依据：严重程度说明对功能、数据、用户的影响，优先级说明在当前版本计划中的修复顺序。具体分级标准由团队另行约定，模板只保留字段入口。
