稳定性应先定义成能够观察的结果：任务是否完成、多久出现中断、失败后多久恢复。不要先给品牌一个综合分数，再反过来挑数据支持它。本站的方法重在保留条件和失败记录，便于自己复盘。
为任务选择指标
网页浏览、会议和上传关注的结果不同。会议需要连续性，文件任务需要最终完成，偶尔备用则需要故障时可恢复。延迟、吞吐与失败率可以同时记录，但不能互相替代。测量应说明方法和样本范围，相关基础可参考RFC 2330。
| 字段 | 记录示例的类型 | 为什么需要 |
|---|---|---|
| 环境 | 时间、运营商、设备、客户端版本 | 确认是否处于可比条件 |
| 对象 | 节点、协议、目标与任务 | 避免混入其他场景 |
| 结果 | 成功、失败、错误提示、持续时间 | 不只保留最好的一次 |
| 恢复 | 首次异常、操作及任务恢复时间 | 区分短暂提示和实际影响 |
| 干扰 | Wi-Fi变化、更新、目标故障 | 解释无法控制的变量 |
成功率必须带上分母
虚构示例：按同一方法安排20次任务，其中18次完成，样本成功比例为90%。应同时写出20次、观察日期、失败定义与方法，而不是只写“稳定率90%”。这也不等于整月可用率90%；没有观察的时间不能默认正常或异常。
如果连续10分钟进行多次请求，它们可能受到同一场拥塞影响，不能把数量多理解成覆盖面广。应按任务需要覆盖不同日期与时段，同时保留每组样本，不能把不同节点和最好日期拼成全品牌结论。
先写采样计划，再开始观察
在自己的使用时段选择有限窗口，写明每次要做的任务、超时或失败定义，以及中断后怎样确认恢复。计划未执行的窗口记未测，不能算成功；客户端已连接但任务未恢复时，仍保留任务失败状态。
假设20:00任务失败、20:02切换配置、20:04任务首次成功，应将三项分开记录。恢复用时与原因判断不同，不能因为切换后成功，就把原故障根因确定为某个节点。后续再观察连续性，避免刚恢复就写彻底解决。
失败后按什么规则处理
第一次异常时记录时间和准确提示，先确认本地接入是否正常，再按预先确定的顺序排查。切换节点、协议或网络后作为新的状态保存；任务恢复时间应以真正恢复为准，不以按钮显示已连接为准。需要排除某条记录时写明理由，原始信息仍保留。
公开结论时限制到已有证据
可以写“在本设备、运营商和这些日期内完成了多少任务”，不能由此保证所有地区、所有套餐或未来月份。原始记录应脱敏，不公开订阅、账号、个人请求内容与密钥。截图只是记录的一部分，不等于跨日稳定性报告。
继续看观察分母、恢复时间起点和测试日志格式。需要实际操作时，再按同条件测试教程建立自己的记录。
继续阅读：可用率数字为什么离不开观察分母、测五秒与测五分钟，结论为什么不同、故障恢复时间应该从哪一刻开始计算、一个地区的测试能代表全国用户吗。
来源与核验范围
以下为参考原始资料。品牌价格和功能应以资料库对应字段为准；本文不包含品牌测速或使用体验。内容由站点维护者使用 AI 辅助整理，尚不构成独立实测。