报故障时，一张截图之外还要补什么

先做一个小而完整的尝试

• 补充时间、页面地址、使用角色、操作顺序和报错文字。

• 分别写预期与实际结果。

• 说明每次是否都发生。

• 记录临时处理方式。

• 隐藏个人信息后再提供截图。

容易忽略的地方

不要求非技术人员先判断根因，也不要把密码或验证码作为定位材料发送。排查中不要反复对正式数据做破坏性试验。

做完以后，看什么

请处理人员反馈已确认的范围和下一步资料需求，恢复后由业务使用者重复原任务确认。

验收时别漏掉边界

报告里分清“页面卡住”“按钮无反应”和“返回错误提示”，这三种现象需要的证据不同。能读取到错误文字时照原样记录，并保留发生时间；不确定的原因写成猜测。技术人员请求进一步日志时，再按约定范围提供脱敏信息。

把下一步写到纸上

收到修正后按同一设备、入口和步骤复测，再补一个相邻操作确认没有新的阻断。把结果回写原问题单，便于看到修正前后差异。如果换了浏览器才正常，也说明实际变化，不能把替代使用办法写成原问题已经解决。

准备前自查

截图之外，先记下访问入口、操作顺序、发生时间和预期结果。给每一步编号，使用脱敏关键词或测试记录复现；如果只在某台设备发生，再补浏览器版本和网络场景。不要把密码、验证码或完整客户资料放进问题单。

三个值得问清的问题

按写出的步骤自己重走一次，检查有没有漏掉前置条件，例如需要先选某个频道。偶发问题标注发生频率，不声称每次必现；录屏前关闭通知，保证画面展示的是实际触发过程，而不是事后重新摆出的示意界面。

继续了解

问题反馈这样写，技术人员才能少来回问

软件上线不是交付终点：这六项要有人接手

定制软件报价之前，把需求写成一次真实操作