踩過三輪才敢說：QNET 弱網測試最容易翻車的五個地方

QNET 是什麼，能幹嘛，適合誰

QNET 是騰訊 WeTest 團隊推出的一款弱網模擬工具——說白了就是給手機 App 「人為製造網路惡劣條件」的測試武器。你可以在它裡面設置隨機丟包、延遲、上下行頻寬等參數，讓 App 在 2G、3G、高延遲隧道、電梯瞬間斷網等真實場景下跑起來，然後觀察 App 的反應。適合做移動端效能測試、弱網場景用例驗證、或者做過場視頻、圖片加載在惡劣網路下的表現。Android 端目前功能最完整，獨立 App 形式分發，4.6MB 的體積，不需要 ROOT，也不需要連電腦就能啟動測試，詳細指南見 qnet。

安裝

Android 手機直接 qnet下載 APK 安裝包就行，目前最新版本是 8.9.27，安裝包大小 4.58M，官方應用市場渠道的版本跟這個對得上。安裝本身沒什麼特別的——允許安裝未知來源的 APK、點兩下就裝好了。首次啟動需要登入，支援手 Q 帳號或者騰訊員工的 TAPD 帳號。如果用普通 QQ 帳號登入，還需要先註冊一個 WeTest 平台帳號才能成功登進去，這一步別卡住，註冊完再回來就好。iOS 端的話情況比較特殊，官方一度說要上架 App Store，後來公開渠道主要靠企業簽名安裝包，功能細節可參考 qnet文檔，功能完整度比 Android 端差一截，普通用戶建議優先用 Android 端。

坑一：測試對象選錯了，以為模板沒生效

第一次啟動模板的時候我就懵了——設了一個高丟包率的模板跑起來，打開微信發現視頻照樣秒開，一點變慢的跡象都沒有。以為是模板參數設錯了，反覆調了幾次都沒用。後來才發現問題不在模板，在測試對象的選擇上。

QNET 工作台裡有兩種生效範圍：「全部應用」和「指定應用」。如果我只測單獨一個 App（比如自家的遊戲），就應該點「點擊選擇測試程式」，只勾那一個 App。但我當時直接用了預設的「全部應用」模式，結果微信、系統更新、後台各種服務的流量全都走了弱網——這時候微信視頻照樣能秒開，因為微信本身對弱網有優化。我以為是模板沒生效，其實是選了一個不該選的生效範圍。

還好我後來做了一個小實驗解套：切回「指定應用」，只勾一個自己寫的測試 App，結果它的圖片加載明顯變慢了——這才確認模板是生效的，之前只是微信太強。

解法速記：測單獨 App 就選「指定應用」，測弱網下整机行為才選「全部應用」。多進程應用（比如遊戲＋語音組件）只勾了主包名沒效果的話，改用「全部應用」驗證，因為副進程可能不走 VPN 管控。

坑二：隨機丟包百分比看似溫和，實際殺傷力巨大

設了 2% 隨機丟包的模板，以為這是溫和測試，結果打開頁面的時候發現每張圖片都裂了、請求重傳好幾次才成功。這才意識到我低估了丟包的破壞力。

隨機丟包是「逐包獨立擲骰子」——每一個數據包都有 2% 的概率被丟棄。看起來百分比很小，但 TCP 協議層看到丟包會認為是網路擁塞，立即收縮擁塞視窗，傳輸速度驟降。應用層一個 HTTP 請求丟一個包，整包就要重傳，響應時間翻一倍。更別說一個頁面有幾十個請求，每個都有 2% 的概率丢，整體失敗概率遠比直覺高得多——這就是弱網測試裡那些「偶發問題」的主因。

官方預設模板給的參考是：5% 為輕度丟包、30% 為重度丟包。我從此養成一個習慣，永遠從 5% 檔開始測，觀察自家產品的拐點在哪裡，然後逐檔往上加，不會一上來就設高值。

還有一個容易忽略的細節：上下行丟包是分開設的。上行丟包模擬「用戶發不出去」——表現為提交失敗、發圖卡住；下行丟包模擬「服務器回不來」——表現為加載超時、圖片裂圖。排查用戶投訴時按方向分開設，能快速定位問題在哪一跳。

坑三：自動化腳本忘了寫 stop_service，設備一直泡在弱網裡

寫 adb 自動化腳本的時候，我只寫了啟動指令，以為測試跑完了弱網自然會停。結果下一次測試的時候發現設備還是卡得要死，ping 任何地址都超時——原來弱網一直沒關，影響了後續所有用例。

正確的做法是每個弱網用例都要顯式收尾，執行 stop_service 指令。停止指令的格式是：

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

執行後 VPN 通道拆除、設備網路立即恢復正常、QNET 進程退出。如果會話開啟了抓包或報告，文件也會在停止時落盤。

我現在自動化框架裡加了三條收尾斷言：網路是否恢復、QNET 進程是否退出、報告文件是否生成。任何一條不滿足就標記該輪結果無效。而且在框架的 teardown 裡也兜底加了 stop_service——就算腳本中途崩潰，也不至於讓弱網殘留在設備上。

坑四：iOS 端功能比 Android 少一截，找不到「指定應用」選項

同事拿 iPhone 來測，找不到「點擊選擇測試程式」的入口——整個工作台就沒有這個按鈕。以為是版本問題或者界面位置變了，折騰半天後才知道這不是 bug，是 iOS 端的功能限制。

QNET iOS 端的功能殘缺是結構性的：只支援「全部應用」模式，不能像 Android 那樣指定某個 App 生效。而且也沒有控制懸浮窗和資訊懸浮窗，過程控制能力弱了一個檔次。所以如果團隊主力設備是 iPhone，測單獨 App 的弱網表現就比較頭痛——只能用「全部應用」模式，然後靠鎖後台、關閉系統自動更新等方式減少無關流量的干擾。

這不是我們的問題，是 iOS 企業簽名版本的硬限制。動手前先確認好要用哪個平台測試，別等寫了一堆腳本才發現平台支援不了。

坑五：忘了看 QNET 進程退出與抓包文件落盤的關係

測試報告生成後我想找 pcap 文件，結果報告裡說會有，但我在緩存目錄裡翻了半天什麼都沒找到。以為是抓包功能沒開或者權限問題，最後發現其實是 QNET 還在跑——抓包文件和報告只有在 stop_service 執行後才會落盤，進程還在的時候文件是寫在記憶體裡的。

這個坑其實就是坑三的延伸：沒正確收尾就沒有報告文件。後來我養成一個習慣，每次 adb stop_service 之後都先確認進程退出、再去看文件，不會急著在進程活著的時候去找報告。

五個坑要點速查

• 測什麼選什麼：測單 App 就「指定應用」，測整机才「全部應用」；多進程 App 改用全部應用驗證
• 丟包從低到高試：永遠從 5% 檔開始，觀察拐點再往上加；上下行分開設能快速定位問題
• 自動化必須寫 stop_service：teardown 裡兜底加停止指令，跑完檢查網路恢復、進程退出、文件落盤
• iOS 只有全部應用模式：沒法指定 App，靠鎖後台減少干擾；主力設備是 iPhone 的話提前有心理準備
• 報告文件要等進程退出：stop_service 後 pcap 和報告才落盤，別在進程活著的時候找文件

這些坑繞過之後，QNET 其實是一款很好用的弱網測試工具——參數直觀、預設模板質量高、自動化支援也完整。筆者現在每次上線前都會跑一輪弱網測試，設備泡在 20% 丟包率裡跑半小時，看看有沒有什麼之前沒暴露出來的問題。畢竟真實用戶的網路條件永遠比我們想的更惡劣。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。