弱網：
oSession[“request-trickle-delay”] = “300”; 注釋的也很明白，Delay sends by 300ms per KB uploaded.上傳1KB需要300ms，轉化一下上傳速度：1Kb/0.3s = 10/3(KB/s)
下載1KB需要150ms
設置斷點
A fiddler菜單欄->rules->automatic Breakpoints->選擇斷點方式，這種方式下設定的斷點會對之后的所有HTTP請求有效。
有兩個斷點位置：
a） before response。也就是發送請求之后，但是Fiddler代理中轉之前，這時可以修改請求的數據。
b.）after response。也就是服務器響應之后，但是在Fiddler將響應中轉給客戶端之前。這時可以修改響應的結果
B 設置響應后斷點（after response breakpoint）,可以通過命令行設置：bpafter localhost
5)修改返回值
觀察inspector，頁面內容出現變化（說明攔截成功）
切換到textView子面板，選擇需要修改的部分，然后點擊 “run to complete“，便可回送修改后的響應
ps：終止斷點的方式有：
1> 在rules->auto breakpoint中disabled斷點即可。
2> 在inspector界面點擊“run complete“即會終止本次HTTP請求的斷點。
3>輸入Go 命令，也會使得當前的請求跳過斷點
1、各個網絡下功能測試
- 不同網絡下，檢查基本功能點
- 運營商移動、聯通、電信接入點測試（需要使用實際SIM卡）
- 若有智能DNS功能，還需要關注運營商判斷/歸類
- 高延時、高丟包、無網、假熱點也可歸入弱網測試范疇
2、網絡切換測試
部分APP有智能DNS功能，網絡切換涉及DNS切換。
網絡切換檢測機制：Android可以監聽系統廣播
3、弱網測試
用戶體驗和異常處理是各個網絡場景都需要關注的，只是弱網場景下，需要重點關注。
弱網測試模擬
什么樣的網絡屬於弱網
低於2G速率的時候都屬於弱網，3G也可划分為弱網，一般Wi-Fi不划入弱網測試范疇。
如何進行弱網測試
1、SIM卡的網絡切換
手機-設置-移動網絡設置-網絡類型選擇
3G、4G卡都可以設置關閉3G/4G，只走2G網絡。
2、具體弱網場景測試，常見場景包括：地鐵/巴士、電梯、樓梯間、停車場
3、使用虛擬機模擬網絡速度，如用樹莓派搭建的弱網測試儀
4、使用軟件進行網絡代理，模擬不同的網絡帶寬、延時率、丟包率
網絡測試經典問題分享
場景一：弱網下，頁面加載過程，程序閃退。
原因：webview超時處理未在UI線程。toast、關閉頁面等操作需要在UI線程。
場景二：302跳轉頁面，達到內置超時閥值后，webview自動關閉。
原因：業務有頁面加載超時自動關閉的邏輯，超時機制未考慮302場景。
【弱網環境測試點總結】
1.場景：弱網環境下某個操作響應時間
原因：APP用戶對等待時間容忍度低，若弱網環境loading超過5s，用戶很容易kill應用后再次進入應用
【測試點】性能測試中，加入弱網環境測試點，檢測各個場景網絡請求的 API 消耗時間（此處可以放入性能測試中，做為衡量APP性能好壞的指標）
2.場景：弱網環境下直至超時，UI界面友好度&APP是否穩定
原因：容錯機制主要是考慮弱網情況下帶來的不穩定，常見的問題是：loading超時導致ANR or crash
【測試點】弱網環境直至超時，判定為斷網狀態，UI界面和提示，友好且理解無歧義
3.場景：斷網后環境下，是否自動重發請求
原因：不同模塊，開發對請求處理不同。測試前可了解，代碼是否支持自動重復請求，自動重發請求的頻率是什么？
【測試點】斷網后恢復網絡，是否堆積網絡請求（目前來說 理財模塊 當10s左右無返回 則會重發請求），此時請求和返回正常情況下，是否出現異常情況。比如1次支付操作，斷網后堆積多個支付請求，恢復網絡后因堆積多個支付請求，是否完成多次支付
ps：斷網后恢復網絡，考慮APP進行操作目的是否對傷害用戶體驗，通過哪種手段 可以達到操作目的同時用戶體驗無感或者低傷害
比如，微信希望在線升級某些內容，會自動監聽用戶是否插着電 or 連着wifi，一旦監聽符合上述場景，APP自動升級：
1）插電場景 確保升級過程中，耗電不會導致手機低電量甚至沒電
2）wifi場景，確保升級過程中，流量消耗不會使用用戶話費中流量包，不會導致因消耗話費流量傷害用戶體驗
4.網絡請求中，kill進程 （導致APP登錄態掉線）
登錄同一個賬號成功，應該不繼續相同網絡請求（要和RD確認，程序實際實現）
登錄不同賬號成功，應該不繼續相同網絡請求（要和RD確認，程序實際實現）
三、【常見弱網問題和原因分析】
1.場景：上傳大圖或者多圖時，在弱網絡環境下出現進度條走到一半卡住然后又從頭開始
原因：采用分段上傳方式，直至請求超時，分段傳輸沒有結束，代碼邏輯不對，導致每次重試都重頭上傳，一直循環
2.場景：在弱網絡環境下容易出現登錄不上或者登陸后立即掉線
原因：登錄沒有緩沖機制，而請求超時時間的設置沒有區分同網絡情況
解決方案：建議開發針對wifi、2g、3g、4g設置不同的超時時間
3.場景：弱網絡環境下，請求的數據返回時間較長，等待的過程中，如果頁面上的相關控件仍然可以操作，則容易出現異常現（閃退現象、觸發底部時獲得原頁面請求數據）
原因：依賴數據的控件操作，在數據返回前沒有做兼容處理
4.場景：搜索時輸入關鍵字會連續發請求，停下時，顯示最終的關鍵字搜索結果，但很快又會被前面的關鍵字搜索結果覆蓋了；
原因：中間的請求返回較慢，顯示了最終的結果后，之前的請求返回的數據應不做處理。
