如何撰写可复现的浏览器错误报告
用预期行为、最小复现步骤、环境信息和隐私审查，把浏览器故障转成可复核的报告，并帮助团队完成分诊、修复与发布决策。
BotBrowser Team
有用的浏览器错误报告能让他人无需猜测就看到同一故障。它应说明预期、实际、最小复现、环境和可安全分享的证据。这不是根因裁决，也不是收集浏览器私密状态的请求。
预期与实际行为
先写可见契约。“选择保存后出现确认并将焦点移到标题”是预期；“请求完成但没有状态，焦点仍在保存按钮”是实际。没有证据不要断言根因。
一个报告只覆盖一个连贯故障。登录、布局和下载即使属于同一版本，也应有不同步骤和负责人。用公开 id 关联报告，不复制私密追踪。
参考 Chromium 与 Mozilla 的错误报告指南；不需要凭据或完整浏览器转储。
最小复现
逐步删除动作，直到删除某一步会让故障消失。使用自有 fixture、合成数据、准确动作、可见结果和清理步骤。不要测试不属于团队的服务。
标题：保存测试 profile 后没有确认
预期：打开自有 fixture，修改名称，选择保存，看到“已保存”并移动焦点。
实际：请求完成，没有状态，焦点仍在保存按钮。
环境：Chromium 154、Linux、1280x800、键盘和指针、app 2026.10.06、5/5 次复现。
| 状态 | 证据 | 下一步 |
|---|---|---|
| 阻塞且可复现 | 步骤每次失败 | 分配负责人并暂停受影响发布 |
| 可复现但范围有限 | 某路径或环境失败 | 与已知正常单元比较 |
| 间歇性 | 次数和频率明确 | 添加上下文再安全重试 |
| 无法复现 | fixture 与环境完整 | 只请求一个缺失条件 |
| 隐私已删减 | 敏感证据移除 | 使用可见事实或批准渠道 |
环境信息
只保留可能改变结果的浏览器版本、平台、视口、输入方式、应用版本、路径、语言、profile、权限和网络。注明冷/热缓存与可见性。这些标签描述测试条件，不识别个人。
BotBrowser 的受控上下文支持使用已声明的 profile、平台、版本、视口、路径和测试数据，重复执行获得授权的浏览器流程；但它不会推断根因、收集私密日志、暴露凭据、保证修复，也不授权针对第三方服务的复现。
分享前的隐私审查
删除 cookies、令牌、密码、账号标识、私有 URL、查询参数、个人文本、无关标签页和客户文件。使用合成名称。截图只保留失败控件和必要可见状态，隐藏地址和通知。不要把完整 profile、网络捕获或 storage 上传到公开 tracker。
私密证据应放在受控渠道，并注明保留负责人和期限。公开报告只需说明存在已删减附件。
分诊与跟进
当他人能执行步骤、看到差异、识别环境并理解隐私边界时，报告才适合分诊。补充频率、首个失败步骤和可见恢复动作。无法复现时与已知正常路径比较，一次只请求一个条件。
发布流程中将报告关联候选版本、矩阵单元或回归测试。修复应加入回归 fixture。决定可以阻塞、给出有界例外、使用回退或标记为范围外，并保留原始失败与验证修复。
提交前确认测试 fixture 和合成数据仍能被接手团队访问，并写明下一次复现的负责人。若必须固定某个权限、缓存或语言条件，也要在报告中明确标注。
如果结果会随运行次数变化，请保留总次数、失败次数和时间窗口。这样的简短记录能帮助比较修复前后的变化，也避免把一次偶发现象写成确定结论。
提交前检查标题、起始步骤、首次可见差异和负责人的下一步动作，让接手者无需通读长日志即可开始处理。
将浏览器版本与应用版本分开记录。若两者同时变化，应先描述已观察到的组合，不要提前断定根因。
使用可以重置的合成 fixture。需要私密状态时，只在公开报告中说明状态形状，把真实值留在受控渠道。
把修复结果追加到同一报告，注明运行次数和保持不变的条件，为后续版本保留可比较的历史。
每次复现都记录负责人和下一次检查日期，避免已有稳定步骤的故障无人跟进。
同时保留测试 fixture 的链接，方便其他团队按相同步骤复现，而不必重新猜测初始条件。
