一份合格的缺陷报告，应当让接手的人不用追问就能复现问题、判断影响。本文给出一份字段齐全的填写样例，覆盖标题、环境、复现步骤、实际与期望结果、证据、严重程度与优先级，再逐项解释写法依据，并说明换一种缺陷类型时如何调整。示例为假设情景，用于示范填写方式，不代表任何产品的真实行为或实测结论。示例中的缺陷记录可在ONES Project中承载字段与流转，具体字段以项目实际配置为准。
要点总览（TL;DR）
- 一份可用的缺陷报告示例应覆盖标题、环境、复现步骤、实际与期望结果、证据、严重程度与优先级，目标是让他人无需追问即可复现、判断和交接。
- 标题写“现象＋位置＋触发条件”；复现步骤编号并最小化，前置条件单列；实际结果只写观察到的现象，期望结果写业务上应发生的行为。
- 严重程度描述缺陷本身的破坏力，优先级描述修复顺序，两者依据不同，可以一个高一个中。
- 换缺陷类型时按现象依赖调整详略：依赖操作顺序的补步骤和录屏，依赖数据状态的写细环境和数据条件，难复现的保留复现频率。
- 示例为假设情景，字段名称、必填项与状态取值需按项目实际配置调整，严重程度分级与服务事件受理不在本文展开。
这份缺陷报告示例要解决什么问题
这份示例的目标很具体：示范一条缺陷记录在提交之后，测试、开发、项目负责人拿到它就能各自行动——测试不必再补充说明，开发能按步骤复现，负责人能据此判断排期。缺陷报告的质量不取决于写得多长，而取决于它能否独立完成这三件事：可复现、可判断、可交接。
可复现，指他人按记录中的环境和步骤操作，能得到相同的异常现象；可判断，指记录中写清了实际结果与期望结果的差距，读者能理解“错在哪”；可交接，指记录带有足够的背景与证据，缺陷在测试与开发之间、在迭代之间转手时不丢失信息。
示例覆盖的字段范围如下，这也是多数缺陷跟踪场景中一条记录的基本构成：
- 标题：一句话点明现象与发生位置；
- 环境：产品版本、设备或浏览器、账号与数据条件；
- 复现步骤：带前置条件的编号步骤；
- 实际结果与期望结果：分开陈述；
- 证据：日志、截图或录屏；
- 严重程度与优先级：两个独立取值。
需要说明的是，以下内容全部为假设情景，产品名称、版本号、账号信息均为示意，不对应任何真实系统。读者应把它当作填写格式的参照，而非某个产品的行为描述。
完整示例：一条登录验证码失效缺陷的填写样例
示例背景设定：假设某在线协作产品“示例工作台”v3.2.1，Web端，测试人员在回归测试中发现登录环节的验证码在特定操作顺序下失效。以下为按字段填写的完整缺陷报告。
| 字段 | 填写内容 |
|---|---|
| 标题 | 登录页连续点击“获取验证码”两次后，第二次提示发送成功但验证码输入框校验始终失败 |
| 产品与版本 | 示例工作台 v3.2.1（Web端） |
| 环境 | Chrome 120，Windows 11；测试账号 test_user_01；网络正常；测试环境 staging |
| 前置条件 | 账号已注册且未锁定；登录页可正常访问 |
| 复现步骤 | 1. 打开登录页，输入已注册手机号； 2. 点击“获取验证码”，等待倒计时结束； 3. 再次点击“获取验证码”，页面提示“验证码已发送”； 4. 输入第二次收到的验证码，点击“登录” |
| 实际结果 | 第4步提示“验证码错误”，连续重试3次均失败；使用第一次收到的验证码同样失败 |
| 期望结果 | 第二次获取的验证码在有效期内可正常完成登录 |
| 复现频率 | 3次尝试中3次复现 |
| 证据 | 操作录屏1段（约40秒）；第4步页面提示截图1张；前端控制台日志片段（含验证码校验接口返回码） |
| 严重程度 | 严重：核心登录流程在特定操作下不可用，且用户无自助恢复手段 |
| 优先级 | 高：影响新用户首次登录路径，建议当前迭代内修复 |
| 备注 | 单次获取验证码后登录正常，问题仅在重复获取后出现 |
这份记录的自洽之处在于：标题中的“连续点击两次”与复现步骤第2、3步对应；实际结果中的“两次验证码均失败”与备注中的“单次获取正常”形成对照，帮助开发缩小排查范围；严重程度说明为什么定级为严重，优先级说明为什么建议当前迭代处理，两者各有依据而非重复。
逐项解释：每个字段为什么这样写
下面按字段说明写法依据，并列出常见错误，便于对照自查。
| 字段 | 示例取值要点 | 写法依据与常见错误 |
|---|---|---|
| 标题 | 现象＋位置＋触发条件，一句话读完 | 标题是列表页里唯一可见的信息，应让人不点开就知道大概。常见错误是只写“登录有问题”或把整段步骤塞进标题。 |
| 环境 | 版本、浏览器或设备、账号、环境标识 | 颗粒度以“他人能搭出同样条件”为准。版本和端类型必须写；账号和数据条件按问题相关性取舍。常见错误是只写“测试环境”，无法定位版本差异。 |
| 复现步骤 | 前置条件单列，步骤编号，每步一个动作 | 步骤要最小化：去掉与问题无关的操作，只保留触发路径。常见错误是把多个动作挤在一步，或省略前置条件导致他人从错误起点开始。 |
| 实际结果 | 只写观察到的现象，含频率 | 与期望结果分开写，是为了让“差距”本身成为判断对象。常见错误是在实际结果里夹带推测原因，干扰排查方向。 |
| 期望结果 | 写业务上应发生的行为 | 期望应来自需求或常识约定，而非个人偏好。常见错误是写“应该正常”，没有可对照的具体行为。 |
| 证据 | 录屏＋关键截图＋相关日志片段 | 证据服务于复现和定位：录屏证明操作顺序，截图锁定提示文案，日志提供接口层线索。常见错误是附上整份日志或无关截图，增加阅读成本。 |
| 严重程度 | 按影响面与可恢复性定级，并写明理由 | 严重程度描述缺陷本身的破坏力，与排期无关。常见错误是把“很急”写成严重程度。 |
| 优先级 | 按业务影响与时间窗口给出处理建议 | 优先级描述修复顺序，受发布计划、影响用户范围影响。同一缺陷可以严重程度高而优先级中，例如影响面小但后果重。常见错误是两者填成同一个词。 |
关于严重程度与优先级的区别，可以用示例中的取值体会：严重程度写“严重”是因为登录主流程在特定操作下不可用且用户无法自助恢复；优先级写“高”是因为它落在新用户首次登录路径上，当前迭代有发布计划。若同样的缺陷只影响内部测试账号，严重程度可能不变，优先级则会下调。
可迁移规律：换一个缺陷类型怎么照样填
从上面的示例可以提炼出四条通用规律，适用于大多数缺陷类型：
- 标题写“在哪、什么条件下、出现什么现象”，控制在可一眼读完的长度；
- 环境写到能重建条件的颗粒度，与问题相关的因素优先；
- 步骤最小化并编号，前置条件单独列出；
- 实际与期望分开陈述，证据只保留能支撑复现和定位的部分。
以另一类缺陷“列表排序错误”做简要示范：标题可写为“任务列表按截止日期排序后，无截止日期的任务排在有截止日期任务之前”；环境写版本与浏览器；步骤为“进入任务列表→切换排序方式为截止日期升序→观察列表顺序”；实际结果为“无截止日期任务出现在列表顶部”；期望结果为“无截止日期任务排在列表末尾或单独分组”；证据附列表截图与排序接口返回数据片段；严重程度按是否影响任务查找判断，优先级按使用该排序的用户比例判断。
再以“数据保存失败”为例：这类缺陷的字段详略会向证据倾斜——需要保存操作的录屏、失败提示截图、请求与响应日志，复现步骤则要写清数据内容与保存入口。字段详略的调整原则是：现象越依赖操作顺序，步骤和录屏越要完整；现象越依赖数据状态，环境和数据条件越要写细；现象越难稳定复现，复现频率和尝试记录越要保留。
当缺陷记录需要在团队间流转时，字段的承载方式会影响交接效率。ONES Project 适配缺陷管理等研发场景，支持将 Bug 提交至对应项目或迭代并跟踪修复情况，ONES TestCase 中未通过的用例也可快速创建缺陷任务，使测试与研发围绕同一条记录协作。示例中的环境、步骤、证据等字段可按项目实际配置落到记录中，状态取值以团队流程为准。
适用边界：示例不能直接照搬的地方
这份示例是假设情景，用于示范字段写法，不代表任何产品的真实行为，也不是实测结论。示例中的版本号、账号、日志内容均为示意，读者不应据此推断某个系统存在该缺陷。
字段详略因团队和缺陷类型而异。面向内部的小团队可能省略优先级，由负责人统一排期；面向多端产品的团队可能要求补充设备型号与系统版本；涉及数据一致性的缺陷往往需要更完整的日志与数据快照。示例给出的是下限参考，不是唯一标准。
示例中严重程度与优先级的取值仅示范“如何写理由”，不涉及分级体系本身。严重程度的判定标准与分级规则属于缺陷分类与分级主题，服务事件的受理与升级属于服务事件与问题管理主题，本文均不展开。
落地时还需按项目实际字段与流程调整：字段名称、必填项、状态下拉值、关联的迭代与负责人，都应以团队在缺陷管理工具中的配置为准。建议先用一条真实缺陷按示例格式填写，再与团队评审一次，把共识沉淀为项目的缺陷填写规范。
常见问题
缺陷报告里的严重程度和优先级可以填成同一个等级吗？
可以出现取值相同的情况，但两者依据不同，建议分别写理由。严重程度看缺陷本身的破坏力和可恢复性，例如核心流程不可用且用户无法自助恢复；优先级看修复顺序，受发布计划、影响用户范围和时间窗口影响。同一个缺陷可能严重程度高而优先级中，例如后果重但影响面小、当前版本不发布。填写时各写一句依据，评审时更容易达成一致。
复现步骤写多细才算够？
以“他人从零开始能走到同一现象”为准。前置条件单独列出，步骤按编号每步一个动作，去掉与问题无关的操作。如果问题只在特定数据或特定操作顺序下出现，就把这些条件写进步骤或环境，而不是靠口头补充。步骤过细会拉长阅读成本，过粗会导致他人从错误起点开始，判断标准是能否稳定复现。
缺陷难以稳定复现时，示例格式要怎么调整？
把重点放在复现频率和尝试记录上：写清尝试了几次、成功复现几次、失败时的差异条件，并保留操作录屏和日志片段。环境部分补充与问题相关的变量，例如账号状态、数据量、网络情况。实际结果中只写观察到的现象，推测原因可以放在备注并标明是推测，避免干扰排查方向。
团队字段配置和示例不一致，应该以哪个为准？
以团队在缺陷管理工具中的实际配置为准。示例给出的是字段构成和写法下限，字段名称、必填项、状态下拉值、关联迭代与负责人都应按项目设置调整。建议先用一条真实缺陷按示例格式填写，再与团队评审一次，把共识沉淀为项目内的缺陷填写规范。示例中的缺陷记录可在ONES Project中承载字段与流转，具体字段以项目实际配置为准。
缺陷报告和测试用例之间是什么关系？
测试用例描述预期行为与验证路径，缺陷报告记录实际行为与预期的差距。执行用例时发现不符合预期，就可以基于该用例创建缺陷，保留用例与缺陷的关联，便于回溯验证范围。ONES TestCase中未通过的用例可快速创建缺陷任务，使测试与研发围绕同一条记录协作。
