本文为基于公开技术资料编写的解释性教程。命令和输出示例不代表已在你的设备上验证；执行前请核对版本、目标设备和数据影响。
好的报告首先限定范围
“后台不稳定”“页面偶尔卡住”表达了感受，却没有限定发生条件。先描述能观察到的行为：屏幕是否熄灭、应用是否在前台、用户等待了多久、网络是否切换、什么动作触发了下一步。
报告不需要把所有环境信息都堆进去，而应留下能改变结果的条件。对于一个布局问题，字体大小可能比网络运营商重要；对于下载问题，网络切换和省电状态则可能更关键。
先写预期，再写实际
预期结果应来源于产品要求或明确的用户操作，而不是测试者的猜测。例如，“点击保存后，重新打开页面仍能看到刚才输入的值”比“保存正常”更容易验证。
实际结果只记录事实：提示成功但数据恢复原值、按钮一直禁用、进程退出，或者超出约定等待时间。不要在实际结果里提前写“数据库锁死”，除非已有证据支持这个判断。
使用一份短而完整的模板
标题：具体操作 + 可观察的失败
构建：versionName / versionCode / 产物摘要
环境：设备、系统、网络与关键设置
前置条件：账号状态、初始数据、权限状态
步骤：1. ... 2. ... 3. ...
预期：可验证的完成条件
实际：看到或记录到的行为
频率：执行次数 / 失败次数
证据：时间、截图、日志片段
范围：已测、未测、受阻的分支模板中的每一项都应该服务于复现。不要填充无意义的“正常”“无异常”；不知道的内容写未确认。测试账号和真实用户信息应使用脱敏标识。
把概率问题变成可比较的实验
偶发问题适合记录每次执行的输入和结果，而不是只记一次成功。比如固定同一条操作路径重复十次，记录失败发生在哪一步；再改变一个可能相关的条件，比较结果。
十次没有复现只能说明在这些条件下没有观察到失败，不能证明错误概率为零。样本规模不足、设备覆盖不足或缺少触发输入时，都应该保留这个边界。
若复现过程很慢，可以先提取最短的失败路径。每次删掉一个步骤，都要重新验证问题是否仍然存在；否则可能把关键前置条件删掉。
验证修复时沿用同一口径
修复后执行原来的复现路径，并检查相邻功能是否受到影响。把修复前后使用的构建、设备和输入放在一起，方便判断改善来自代码，还是来自测试条件变化。
可以把结果标记为通过、失败、受阻或未验证。受阻可能是测试账号不可用、服务不可达或设备限制，不能合并成通过。对于没有复现的偶发问题，保留尝试次数和观察窗口，让后来者知道结论覆盖了多大范围。