adb 自动化实战：从终端脚本到被测 App 的完整闭环

三条指令背熟之后，值得看一次完整运行的样子。官方演示过的实战形态是：终端里跑一个 Python 脚本逐条下发 adb 指令，旁边被测 App 的界面实时画出延迟曲线。

实战脚本的任务单

示例会话完成四件事：

启动全局弱网（拉起 QNET 进程）；
设置上行延时 100ms，保持 10 秒；
动态更新参数，再切下一档；
关闭弱网并退出进程。

终端逐条下发 adb 指令，右侧被测 App 同步显示延迟波形 — 弱网自动化实测：终端指令与被测应用曲线

对应的指令序列

# 1. 启动全局弱网
adb shell am start com.tencent.qnet/.Component.AdbStartActivity

# 2. 设置上行延时 100ms（全量语义，只关心延时就只写延时）
adb shell am broadcast -a "qnet.boradcast.drive" --include-stopped-packages --es "command" "update" --ei "out_delay" 100 com.tencent.qnet

# （保持 10 秒，期间被测 App 曲线抬升到 100ms 档位）

# 3. 切换下一档：300ms 延迟 + 20% 下行丢包
adb shell am broadcast -a "qnet.boradcast.drive" --include-stopped-packages --es "command" "update" --ei "out_delay" 300 --ei "in_rate" 20 com.tencent.qnet

# 4. 收尾
adb shell am broadcast -a "qnet.boradcast.drive" --include-stopped-packages --es "command" "stop_service" com.tencent.qnet

截图里的终端逐条打出了 Broadcasting: Intent ... Broadcast completed: result=0 回执——每条广播送达后弱网立即按新参数执行，右侧被测应用的延迟曲线随之从低位台阶式抬升，这正是全量更新逐档生效的直观证据。

把示例扩成用例框架的四个要素

参数矩阵：把档位定义成数据（延迟/丢包/带宽组合），循环驱动，见adb 参数速查表；
状态校验：每档切换后探测弱网是否真的生效（悬浮窗读数截图或网络探测）；
业务断言：弱网生效期间执行业务操作并断言预期行为（超时文案、重试、降级）；
teardown 兜底：无论用例成败，最后必发 stop_service，见adb 结束弱网。

排障速记

广播无回执 → 进程不在了，先 am start；
参数没生效 → 检查全量更新语义是否冲掉了配置，见动态更新弱网参数；
曲线纹丝不动 → 弱网没套上，回查生效范围与授权，见选择被测应用。

跑通这一轮，弱网就正式成为回归资产；下一步按业务场景挑档位，见实战场景应用。