弱网测试没报错，就算通过了吗？

一轮弱网测试跑完，App 没有崩溃，请求最终返回成功，测试报告也是绿色。

看起来可以通过了。

但把过程录屏重新看一遍，会发现页面转了 40 秒。用户在第 8 秒点过返回，后来又重新进入。技术上，那次请求成功了；从用户视角看，他早就放弃了。

只看“成功或失败”，很容易把这种体验算成正常。

成功率只回答了一个问题

成功率告诉我们，有多少请求最后拿到了成功结果。它很有用，却无法说明用户等了多久，也看不出网络恢复后任务有没有继续。

视频通话可以保持连接成功，声音却断断续续；文件也许最终上传完成，中间断线后从头传了两遍。支付接口返回成功，如果页面在结果到达前允许用户再次付款，风险仍然存在。

这些例子并不否定成功率，只是说明它管不了全部体验。弱网测试至少还要看看过程，以及业务结束后状态是不是对的。

同一次测试，可以从四层看结果

把数据分层之后，许多争论会少一点。

层面	它回答什么	常见观察项
网络条件	模拟器实际制造了什么环境	实际吞吐、丢包、延迟、持续时间
连接状态	传输过程是否稳定	超时、重连、重传、连接中断
业务结果	功能最后是否正确	订单状态、消息数量、上传进度
用户体验	用户在等待时看到了什么	首次反馈时间、卡顿时长、恢复时间

这四层没有谁更高级。它们是用来排除不同问题的。

如果目标是 20% 丢包，实际一次包都没丢，业务成功不能说明 App 扛住了弱网；如果网络条件符合预期，订单却创建了两次，问题就在业务层。订单最终只有一份，但页面让用户等了半分钟，也该继续优化反馈和恢复速度。

用户等到什么时候，值得单独记录

总耗时常常会掩盖过程。

例如一次上传用了两分钟。如果页面点击后立刻显示进度，并且断网时明确告诉用户“已暂停”，两分钟未必不可接受。另一个页面同样耗时两分钟，却在前 30 秒没有任何变化，用户很可能以为按钮没点上。

因此可以把时间拆开看：

• 用户操作后，多久看到第一条有效反馈；
• 网络变差后，多久进入降级或暂停状态；
• 网络恢复后，任务多久开始继续；
• 整个业务多久得到最终结果。

这里的“有效反馈”不是让加载动画转起来就算完成。它应该说明当前发生了什么，或者至少让用户确认操作已经被接收。

不同业务对时间的容忍度也不同。刷一条资讯等三秒，用户可能已经划走；上传几百 MB 文件等几分钟很正常，前提是进度可信，还能退到后台继续。

最终成功之前，有没有付出奇怪的代价

有些问题会藏在“成功”后面。

上传一次文件，服务端收到了两份；消息发送成功，列表里出现重复内容；视频恢复播放，却一直停在最低清晰度。只记录最终状态，这些代价很容易漏掉。

测试时可以多问几句：

• 自动重试一共发出了多少次请求？
• 网络恢复后有没有从头重复传输？
• 旧响应是否更新了已经离开的页面？
• 业务成功后，客户端和服务端状态是否一致？

这些问题不需要每次都靠人工盯屏幕。重复次数、恢复时间和最终状态可以进入结构化报告；动画是否突兀、提示是否看得懂，仍然适合通过录屏或人工体验判断。

通过标准要写成可以验证的话

“弱网下体验良好”听起来没毛病，真正执行时却不知道怎么判。

换成具体条件会好很多：

业务场景	可以使用的通过条件
文件上传	断网 5 秒后恢复，10 秒内继续上传，已确认进度不回退
支付	响应丢失时进入结果确认状态，不得自动重复提交
聊天消息	重试后服务端和本地均只保留一条消息
视频播放	网络恢复后自动继续，卡顿结束后允许画质逐步回升
AI 流式回答	中断时给出明确状态，不生成两份互相冲突的回答

数字要结合产品定，不能从别人的报告里随手抄。短视频和网盘对恢复时间的要求不一样，支付对重复操作的容忍度则几乎为零。

先选最影响用户的两三个条件就够了。验收项太多，最后容易变成每项都记录、没有一项真正阻止发布。

比较版本时，先保证大家跑的是同一场考试

旧版本恢复用了 12 秒，新版本只用 6 秒，这个结论很诱人。可如果两次测试的丢包顺序、网络步骤和文件大小不同，数字没法直接比较。

做回归时，最好固定这些条件：

• 相同的场景步骤和持续时间；
• 相同的随机种子；
• 相同的目标 App、协议和网络方向；
• 相同的业务数据及操作时机。

报告还要区分目标参数、实际应用结果和最后观测值。配置写着 10% 丢包，实际只处理了很少几个包，本次结果就不适合拿来做结论。

同样条件多跑几次，比只挑表现最好的一次靠谱。若结果波动很大，也应该把波动留下来，而不是算一个漂亮的平均数把问题盖住。

指标多，不代表报告有用

弱网报告很容易越做越厚：每秒吞吐、每种协议的包数、几十条时间线，再加上一堆统计图。信息都是真的，读完仍然不知道这个版本能不能发。

比较实用的顺序是先写结论，再给证据。

例如：上传在恢复后 7 秒继续，满足 10 秒以内的标准；没有重复文件；实际丢包 19.2%，接近目标的 20%。需要排查时，再打开详细时间线或 PCAP。

这样开发、测试和产品看到的是同一个业务结果。底层数据还在，但不会抢走主角的位置。

报告里的域名、IP、目标应用和抓包内容可能涉及隐私。分享前要做裁剪或脱敏，留存时间也该有限制。为了证明一次测试通过，没有必要把用户访问过的全部地址永久保存下来。

有些事情还是要人来判断

机器可以判断恢复是否超过 10 秒，也能发现消息数量不一致。它很难替用户回答另一些问题：提示文案看不看得懂，画面卡住时是否让人焦虑，操作被禁用后用户知不知道原因。

所以自动指标适合守住明确底线，人工体验负责发现还没被写成规则的问题。两边不用争谁更可靠，它们看的本来就不是同一件事。

发现一个反复出现的问题后，再把它变成新的可测条件。比如用户总在“支付结果确认中”页面重复退出，就可以把退出重进后的订单状态加入下一轮回归。

写在最后

弱网测试没报错，只能说明 App 没在这次测试里直接倒下。它距离“可以通过”还差业务结果、恢复时间和用户反馈。

先把最重要的用户过程写成几条能验证的标准，再用相同场景比较版本。这样报告上的绿色才有明确含义：上传没有重来，支付没有重复，用户也没有被留在一个无限转圈的页面里。