开发总回“无法复现”?这份缺陷报告模板把证据一次写全

测试实战 · 缺陷报告模板

开发总回“无法复现”？这份缺陷报告模板把证据一次写全

让问题可复现 · 让判断有依据 · 让修复可验证

刚提交 Bug，开发回复一句“无法复现”；产品又追问“到底影响谁”。这时继续补一句“我这里真的有问题”，通常只会让沟通再绕一圈。

缺陷报告的任务不是证明测试“发现得对”，而是让接手的人能够复现、判断影响并开始修复。本文交付三样东西：一份五段式缺陷报告模板、一个脱敏教学示例，以及提交前检查表。

1. 场景与环境：问题在什么条件下发生。
2. 复现步骤：别人如何独立走到问题现场。
3. 预期结果：正确行为的依据是什么。
4. 实际结果：系统真实发生了什么。
5. 影响与证据：为什么值得处理，用什么证明。

五段不要求写得很长，但每一段都要回答一个不同的决策问题。缺一段，接手的人就需要再问一轮。

这份模板的重点不是字段越多越专业，而是把“复现、判断、修复”需要的信息放在同一处。团队已有缺陷系统时，可以把这些字段映射到现有表单，不必另造一套流程。

1. 场景与环境：写复现前提

“测试环境有问题”没有提供可操作信息。至少写清账号角色、入口、数据状态、版本和终端条件。例如同一个支付问题，普通用户与管理员、首次支付与重复支付、网页端与 APP 端，触发链路可能完全不同。

偶发问题还要补复现比例。与其写“偶尔出现”，不如写“同一数据重复操作 10 次，出现 3 次；切换网络后未出现”。这不是为了显得精确，而是帮助开发判断是否与并发、缓存、网络或数据状态有关。

2. 复现步骤：一次只写一个动作

步骤要让没有参与测试的人也能照着操作。每一步包含动作、输入和落点：进入哪个页面，使用什么数据，点击什么按钮，在哪个节点观察。

不要把“登录后下单支付再返回查看订单”挤在一句话里。链路越长，越需要编号；关键输入可给脱敏示例，不能把真实手机号、身份证、Token 或支付信息贴进缺陷单。

3. 预期结果：给出判断依据

“应该正常”不是预期。预期要写系统应该产生的可观察状态，并指出依据来自需求、交互稿、接口契约，还是产品已经确认的规则。

如果依据本身不明确，不要先把个人理解包装成确定结论。可以标记“规则待产品确认”，将问题转为需求澄清；否则开发修完后，测试仍然无法判断是否通过。

4. 实际结果：只写观察到的事实

实际结果不要写“功能不可用”“接口有问题”或“页面不对”。记录页面文案、HTTP 状态、业务错误码、关键响应字段、日志关键词或数据状态变化。

截图适合证明界面现象，录屏适合证明操作链路，请求响应适合证明接口行为，日志和数据库前后对比适合证明状态变化。证据不是越多越好，能支撑判断的最短组合就够了。

5. 影响与证据：说明为什么要处理

影响要连接到真实业务动作，例如用户无法完成支付、订单状态不一致、库存被重复扣减，或仅有局部文案错误。不要只写“影响严重”。

严重程度和优先级最好按团队规则填写。测试可以提供影响范围、发生概率、是否有绕行方案和证据，但不要用情绪替代团队的优先级标准。

下面是教学演示，账号、订单号、版本号和响应内容均为占位示例，不代表真实项目数据。

标题： [支付结果页] 回调成功后订单仍显示“待支付”，刷新页面后恢复

1. 场景与环境

预发布环境，Web 端，普通用户账号；订单初始状态为“待支付”；浏览器和构建版本记录在附件中。相同数据操作 5 次，出现 5 次。

2. 复现步骤

1. 创建一笔测试订单并进入收银台；
2. 使用沙箱渠道完成支付；
3. 等待支付成功提示后返回订单详情；
4. 观察订单状态，再手动刷新页面。

3. 预期结果

支付回调处理成功后，订单详情应展示“已支付”。依据为已确认的订单状态流转规则。

4. 实际结果

首次返回详情页仍显示“待支付”；手动刷新后变为“已支付”。附件包含页面录屏、脱敏后的查询响应和对应时间点日志摘要。

5. 影响与证据

用户可能误以为支付失败并重复操作；当前存在“刷新页面”的绕行方式。影响等级由团队根据发生范围和重复支付防护共同判断。

这个示例没有直接断言根因是缓存或前端刷新，因为缺陷报告应先固定事实。根因需要结合代码、日志和链路继续定位。

回复“无法复现”：先检查环境、账号角色、数据状态和复现比例是否齐全，再补最短录屏或请求链路。不要只重复“我这里可以”。

回复“这不是 Bug”：补预期依据。如果需求存在歧义，转为规则确认，并记录最终结论；不要把争论留在口头聊天里。

回复“影响不清楚”：补用户动作、数据后果、发生范围和绕行方案。影响很小也可以如实写，准确比夸大更有用。

• 标题能否看出模块、现象和触发条件？
• 另一个人能否按步骤独立复现？
• 环境、版本、角色和数据状态是否齐全？
• 预期是否有可追溯依据？
• 实际结果是否包含可观察事实？
• 影响是否落到用户、业务或数据？
• 证据是否够用，并且已经脱敏？
• 优先级是否遵循团队规则，而不是个人情绪？

一条高质量缺陷报告，本质上是一份最小协作文档：让问题可复现，让判断有依据，让修复结果可验证。