缺陷报告的价值在于让没参与测试的人也能独立复现、定位并判断优先级。编写时先写清环境与前置条件，再给出最小复现步骤、实际结果与预期结果，附上可核查的证据，最后说明影响范围与记录状态。本文按字段骨架、写作规则、标题与影响范围、角色分工、完整示例和提交前检查的顺序展开，适合测试、开发和业务提交人共同使用。
要点总览（TL;DR）
- 缺陷报告按八项字段组织：标题、环境与版本、前置条件、复现步骤、实际结果、预期结果、证据、影响范围，填写顺序是先写可复现、再写可判断、最后补证据。
- 复现步骤用编号书写并做最小化，每步一个可观察动作；实际结果与预期结果成对描述，落到可观察现象上。
- 标题按对象、动作、异常现象、条件四要素组合，影响范围从受影响功能、用户范围、数据后果三个维度说明，严重程度交给分级流程判定。
- 提交人、评审人、开发处理人、验证人各管一段，退回补全要有时点，避免报告长期停在待补充状态。
- 提交前按可复现性、字段完整性、证据可访问性逐项核对，关键字段缺失即退回。
一份缺陷报告先写哪几块
缺陷报告的字段骨架可以概括为八项：标题、环境与版本、前置条件、复现步骤、实际结果、预期结果、证据、影响范围。填写顺序建议按“先写可复现、再写可判断、最后补证据”推进：先记录出问题的环境和版本，写清操作起点，再按顺序列出复现步骤，成对写出实际结果与预期结果，随后补充截图、日志等证据，最后描述影响范围并拟定标题。标题放在最后拟定，是因为此时对异常现象和触发条件已有完整认识，更容易写准。
字段的紧迫程度不同。环境与版本、复现步骤、实际结果、预期结果属于缺失即退回的核心字段，缺少任何一项，接手人都无法独立判断问题是否存在。证据和影响范围可以在提交后短时间内补齐，但应在评审前完成。前置条件在步骤本身已能说明起点时可以简写，涉及特定账号、数据状态或配置时则必须写全。
| 字段 | 填写要求 | 示例值 |
|---|---|---|
| 标题 | 对象、动作、异常现象、条件四要素齐全，一句话可读 | 订单列表按金额排序后，第二页数据重复显示 |
| 环境与版本 | 记录应用版本、操作系统、浏览器或设备、测试环境标识 | v3.2.1，测试环境，Chrome 120，Windows 11 |
| 前置条件 | 写清操作起点所需的账号、数据、配置状态 | 使用普通用户账号，账号下已有 30 条以上订单 |
| 复现步骤 | 编号书写，每步一个可观察动作，做最小化处理 | 1. 登录并进入订单列表；2. 点击金额列排序；3. 翻至第二页 |
| 实际结果 | 描述可观察到的现象，避免“不正常”“报错”等笼统词 | 第二页前 5 条与第一页末尾 5 条重复 |
| 预期结果 | 写出符合业务规则的正确表现 | 第二页从第 21 条订单开始，无重复记录 |
| 证据 | 截图标注关键位置，日志截取相关时间段，录屏覆盖完整路径 | 截图 2 张，标注重复行；接口日志 1 段 |
| 影响范围 | 说明受影响功能、用户范围、数据后果 | 订单列表分页功能，影响全部用户，暂无数据错误写入 |
复现步骤与证据怎么写才可核查
复现步骤的目标是让另一个人从同样的起点出发，得到同样的现象。写法上采用编号，每一步只包含一个可观察动作，例如“点击金额列排序”“翻至第二页”，避免把多个操作塞进一句。步骤要做最小化：从初始状态出发，删去与触发异常无关的浏览、切换和重复操作，只保留必要路径。步骤写完可以自问一句：换一个人按这几步操作，能否稳定到达异常现场。
实际结果与预期结果要成对书写，并且都落到可观察的现象上。反例是“实际结果：排序有问题；预期结果：排序正常”，正例是“实际结果：第二页前 5 条与第一页末尾 5 条重复；预期结果：第二页从第 21 条订单开始连续显示”。预期结果应引用业务规则或需求说明，而不是凭个人偏好判断。
证据选取以能支撑结论为准。截图标注关键位置，日志截取异常发生前后的相关时间段，录屏覆盖完整复现路径。文件命名包含缺陷编号与内容说明，例如“BUG-1024_订单列表第二页重复截图”，便于评审时快速对应。偶现问题要记录出现频率与尝试次数，例如“10 次尝试出现 3 次”，并注明是否与特定环境、账号或数据相关，帮助开发缩小排查范围。
- 步骤编号连续，每步一个动作，不合并操作。
- 步骤前写清起点状态，涉及特定数据时说明数据特征。
- 实际结果与预期结果一一对应，使用同一描述口径。
- 证据文件命名可追溯，截图带标注，日志带时间范围。
- 偶现问题写频率、尝试次数和可能的关联条件。
标题与影响范围如何写得可判断
标题承担的是“一眼判断这是什么问题”的任务。推荐按“对象、动作、异常现象、条件”四要素组合：对象是出问题的功能或页面，动作是用户执行的操作，异常现象是可观察的结果，条件是触发时的特定环境或数据。例如“订单列表按金额排序后，第二页数据重复显示”，对象、动作、现象、条件都在一句话内。标题不写“有 bug”“异常”这类无法区分的词，也不把修复建议塞进标题。
影响范围从三个维度描述：受影响功能，说明哪些页面、接口或流程受影响；用户范围，说明是全部用户、特定角色还是特定数据条件下的用户；数据后果，说明是否造成数据错误、丢失或仅影响展示。三个维度写清后，评审者才能判断这件事该多快处理。严重程度与优先级由团队的分级流程判定，报告只提供判断依据，不在报告内自行定级，避免提交人凭感受抬高或压低级别。
| 写法 | 示例 | 问题 |
|---|---|---|
| 笼统标题 | 订单页面有 bug | 无法区分对象、动作和现象 |
| 推荐标题 | 订单列表按金额排序后，第二页数据重复显示 | 四要素齐全，可直接判断 |
| 含糊影响 | 影响比较大 | 无法支撑分级 |
| 推荐影响 | 影响订单列表分页展示，全部用户可见，未造成数据写入错误 | 功能、用户、数据三个维度清楚 |
谁在什么时点写、审、改
缺陷报告从提交到关闭涉及四类角色。提交人负责把异常写成字段完整、可复现的记录，提交时完成核心字段并附上已有证据。评审人在提交后的首个工作时段内完成初审，判断字段是否齐全、步骤是否可复现，不满足时退回补全并说明缺什么。开发处理人接手后更新定位信息、修复方案和修复版本，把状态推进到待验证。验证人按原步骤复测，更新验证结论和最终状态。
状态流转中，每个角色只更新自己负责的字段，避免多人同时改同一份记录造成信息冲突。退回补全应有明确时点，例如评审当日退回、提交人次日补齐，避免报告长期停在待补充状态。缺陷记录需要承载字段、状态和评审流转时，可以放在工作项中管理。ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通，可一键提 Bug，并支持一键提交至对应项目或迭代，记录和跟踪修复情况；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转。具体字段配置与状态流转以团队实际配置为准。
| 角色 | 主要动作 | 交付物 | 时点 |
|---|---|---|---|
| 提交人 | 填写核心字段、附证据、响应退回 | 可复现的缺陷记录 | 发现异常后尽快提交 |
| 评审人 | 检查完整性与可复现性，退回或通过 | 评审结论与退回说明 | 提交后首个工作时段 |
| 开发处理人 | 更新定位、修复方案、修复版本 | 修复说明与待验证状态 | 接手后至修复完成 |
| 验证人 | 按原步骤复测，更新验证结论 | 验证结果与关闭或重开决定 | 修复版本可测后 |
完整示例：从异常现象到可处理报告
以下为演示情景，用于说明字段如何组合，不代表真实项目数据。原始现象来自一次测试：测试人员在订单列表翻页时发现数据重复，最初描述为“订单列表翻页有问题，第二页有重复数据”。这条描述缺少环境、步骤和预期，无法直接处理。
按字段逐项填写后形成如下报告：
- 标题：订单列表按金额排序后，第二页数据重复显示
- 环境与版本：v3.2.1，测试环境，Chrome 120，Windows 11
- 前置条件：普通用户账号，账号下已有 30 条以上订单，订单金额存在相同值
- 复现步骤：1. 登录并进入订单列表；2. 点击金额列排序；3. 翻至第二页；4. 对比第一页末尾与第二页开头记录
- 实际结果：第二页前 5 条与第一页末尾 5 条重复
- 预期结果：第二页从第 21 条订单开始连续显示，无重复记录
- 证据：截图 2 张，标注重复行；排序接口日志 1 段，时间范围 14:20 至 14:22
- 影响范围：影响订单列表分页展示，全部用户可见，未造成数据写入错误
这份报告的关键写法有三处。步骤做了最小化，只保留进入列表、排序、翻页和对比四步，去掉了登录前的其他操作。实际结果与预期结果使用同一口径描述“第二页开头与第一页末尾”的对应关系，评审者可以直接对照。影响范围明确区分了展示问题和数据写入问题，为后续分级提供了依据，报告本身没有自行判定严重程度。
提交前的完成检查
提交前按清单逐项核对，可以把大部分退回挡在评审之前。检查围绕三类标准展开：可复现性、字段完整性、证据可访问性。任何一项阻断条件不满足，报告应留在草稿状态补齐后再提交。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 复现步骤完整 | 从写明的起点出发，按步骤可稳定到达异常现象 | 是 |
| 步骤已最小化 | 无与触发异常无关的操作 | 否 |
| 环境与版本齐全 | 应用版本、系统或设备、环境标识均有记录 | 是 |
| 结果成对书写 | 实际结果与预期结果一一对应且可观察 | 是 |
| 证据可访问 | 截图、日志或录屏可打开，命名可对应缺陷 | 是 |
| 影响范围可判断 | 功能、用户范围、数据后果三个维度有说明 | 否，评审前补齐 |
| 偶现问题有频率 | 写明尝试次数与出现次数 | 是，仅限偶现问题 |
评审通过的标准是：评审人无需追问即可按报告复现问题，并能据此判断影响范围。评审负责人对退回和通过结论负责，提交人对补齐内容负责。团队可以把这份清单固化为提交模板或评审检查项，让每次提交都按同一口径完成。
常见问题
偶现缺陷怎么写才能让开发愿意接手排查？
偶现问题的关键是把不确定性写清楚，而不是等它稳定复现再提交。记录尝试次数与出现次数，例如“10 次尝试出现 3 次”，并注明是否与特定环境、账号、数据状态或操作顺序相关。复现步骤仍按编号写，同时说明哪一步之后现象开始出现、哪一步有时不出现。
证据上尽量保留异常发生时的日志时间段和录屏，录屏比截图更能反映操作节奏。如果多次尝试都无法复现，可以在报告中写明已尝试的条件组合，让开发知道哪些方向已经排除。
缺陷报告提交后被打回，通常缺在哪几处？
退回最集中的原因有三类：环境与版本没写全，接手人无法还原现场；复现步骤把多个操作合并成一句，或者缺少起点状态；实际结果写成“不正常”“报错”这类笼统描述，与预期结果对不上。
处理方式是按退回说明逐项补齐，补齐后重新走评审，不必另开一条新记录。团队可以把高频退回原因整理成提交模板的提示项，减少重复沟通。
报告里要不要自己判定严重程度和优先级？
建议把定级交给团队的分级流程，报告只提供判断依据。提交人最了解现场，但容易只看到自己这一条路径，定级偏高或偏低都会影响排期判断。
报告需要做的是把影响范围写实：哪些功能受影响、影响全部用户还是特定角色、是否造成数据错误或丢失。评审者依据这些事实和分级规则判定级别，结论更稳定，也便于后续复盘。
用工作项管理缺陷时，字段和流转要注意什么？
把缺陷报告放进工作项管理，重点是把核心字段固化为必填项，让缺失字段在提交环节就被拦住，而不是等到评审才发现。状态流转上明确每个角色只更新自己负责的字段，退回时写清缺什么、何时补齐。
ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通，可一键提 Bug，并支持一键提交至对应项目或迭代，记录和跟踪修复情况；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转。具体字段配置与状态流转以团队实际配置为准。
缺陷报告和缺陷分级、服务事件受理是什么关系？
缺陷报告解决的是记录质量问题：把一次异常写成他人能独立复现和判断的记录。严重程度与优先级的判定规则属于缺陷分级流程，报告提供影响范围等依据，不承担定级职责。
服务事件的受理与处理是另一条流程，面向用户侧问题的接收与响应。两者在团队里可能衔接，但写作要求不同，缺陷报告不必套用服务事件的受理字段。
