缺陷证据 · 实用指南
提交能复现的缺陷证据：让问题更快被定位
缺陷报告的作用是帮助另一个人重现同一种失败。清楚的起点、动作和结果，通常比一句“系统有问题”更有价值。
先留下现场，再尝试恢复
下面是一个虚构案例：活动报名表单填写了姓名和场次，点击提交后仍停在原页，没有成功提示。先记下发生时间、页面名称和可见提示，再决定是否刷新。若提交可能创建订单、报名或扣费，不要连续重复点击；先查看是否已经产生记录，避免制造重复操作。
按照六个步骤收集信息
- 确定起点：说明是否登录、从哪个入口进入、此前是否已有记录。起点不同，看似相同的操作可能走向不同分支。
- 列出动作：每一步只写一个操作，并记录关键输入。本例使用测试姓名“示例甲”、场次“周六上午”，不使用真实报名者资料。
- 写出预期：例如“显示报名成功，并出现一条报名记录”。预期应来自约定或页面说明；不确定时标为待确认。
- 记录实际：例如“按钮恢复可点击，页面没有提示，报名列表也没有新增记录”。把看到的现象与自己的原因猜测分开。
- 描述环境：记录设备、浏览器、页面版本标识和发生时间。没有版本标识就明确写未知，不用猜测。
- 补充证据：附局部截图、简短录屏或请求编号。给每个附件写一句说明，使接手的人知道它证明哪一步。
错误示范与改进
错误示范：“报名又坏了，赶紧修，截图看附件。”
改进为：“活动报名页提交后无结果。进入周六上午场次，填写示例甲，勾选说明，点击一次提交。预期显示成功；实际按钮短暂禁用后恢复，页面无提示。截图一是提交前输入，截图二是提交后的页面。测试账号下观察到一次，尚未确认其他场次。”这样的报告既具体，也没有把一次观察夸大为所有用户的问题。
缩小范围，不急着下结论
确认重复操作安全后，可以一次只改变一个条件：换场次、清空可选备注，或在另一个浏览器尝试。分别记录成功与失败，保留原来的失败条件。如果问题暂时消失，写“本次未复现”，不要直接写“已经修复”。请求返回成功也不必然说明业务记录正确，仍要核对页面或约定的最终状态。
分享之前做一次脱敏
截取与问题相关的区域，遮盖姓名、手机号、地址以及账号信息。日志和请求内容还可能包含令牌、会话标识或内部地址，不应整包公开。保留字段结构和稳定的测试编号，能帮助关联证据，又避免把无关数据带进报告。
这套方法的适用边界
普通界面错误可以按以上步骤整理。如果出现异常扣费、权限泄漏或数据丢失，应停止可能扩大影响的尝试，优先联系维护者并保存必要现场。报告越完整，定位越有依据；它仍不能保证问题一定能复现，也不能代替最终修复后的验证。