连续切换之后失去了什么 · 方法
用户连续切换多个节点，最后只记得某一次速度很快。 这类情况看似只有一个结果，背后却可能同时包含设备状态、客户端版本、网络路径和目标服务。先把发生时间、当前网络与实际任务写清楚，后面的比较才不会失去基础。
稳定条件带来的比较基础 · 方法
测试条件频繁变化会失去清楚的比较基础；保留主要条件并分阶段观察，差异才有解释空间。 因此，看到一个错误提示或一次速度变化时，不应马上把原因归到单一节点。把过程拆成可观察阶段，才能知道下一次应该保持什么不变。
探索与验证承担不同任务 · 方法
探索性测试用于快速发现候选，验证性测试用于确认某个改变是否稳定有效。 比较时需要使用相同目标、相近时段和同一设备，并保留原始提示。否则条件变化会被误认为方案本身的差异。
短时结果能够说明多远 · 方法
短时间测试不能代表整天，更不能代表其他地区和其他设备。 网络环境会随地区、运营商、时间和服务状态变化。文章提供的是判断方法，而不是对所有现场作出统一承诺。
五项最小测试记录 · 方法
建议依次完成：确定一个目标任务；固定设备和网络；先记录基准结果；分阶段调整测试条件；重复并写下异常条件。记录不需要复杂，但应让另一位使用者知道你测试了什么、改变了什么，以及结果何时出现。
确定一个目标任务 · 方法
可以补充设备型号、系统版本和当前网络。页面状态写“已打开”或“未打开”即可，不必附上账号内容。
固定设备和网络 · 方法
建议保留客户端版本、文件名称与下载时间。需要说明安全提示时记录原文，不要提交验证码。
先记录基准结果 · 方法
把目标任务写成“打开页面”“下载文件”或“完成会议”，比笼统写“网络不好”更容易比较。
分阶段调整测试条件 · 方法
现场说明只保留必要环境信息。密码、付款资料和完整订阅地址不属于普通问题反馈材料。
重复并写下异常条件 · 方法
完成后写下恢复动作与结果，下一次遇到相似现象时便能直接比较，不必从头回忆。
用完整句子描述结果 · 方法
如果换网络后恢复，也应注明设备和目标没有改变。这样下一次看到相似现象时，记录仍然具有参考价值。
何时应该停止继续尝试 · 方法
回到已知页面核对文件名称、版本和设备条件，通常比连续下载多个相似文件更稳妥。
更新时间也是判断条件 · 方法
记录更新时间与首次出现问题的日期，可以迅速排除一部分不相关信息，也方便找到相应版本说明。
保留一个简单基准 · 方法
有了基准，设备切换或版本更新后的变化会更容易看见；基准本身变化时，则应重新建立比较起点。
现场结果在时间线中的位置 · 方法
时间线不必收集每次普通访问，只保留明显变化、关键更新和恢复动作，便足以支持以后比较。
不要忽略目标服务 · 方法
如果多个无关目标都正常，只有一个服务异常，排查重点就不应继续停留在本地带宽。
让结论保持适当大小 · 方法
把结论写小并不会降低价值，反而能让读者知道它在什么条件下可以复用，又在什么地方需要重新确认。
形成以后仍看得懂的说明 · 方法
清楚的记录能让安装、登录和线路问题进入同一套阅读方式，也能避免把旧版本经验直接套到新的客户端。