【弱網測試的背景】
對於某些問題的定位可以使用抓包來看數據。
弱網測試，屬於健壯性測試的內容。
1.用戶體驗
APP使用過程中，弱網的高延遲和高丟包，在實時性要求非常高的場景下，用戶體驗容易減弱
2.非正常情況下，出現bug概率會增加
在日常的需求中，經常會遇到用戶反饋並且無法簡單復現的問題，有很大一部分的問題是由於用戶自身網絡環境的波動，或者本身網絡環境就比較惡劣，導致會出現一些意想不到的bug。
【弱網測試的原理】
使用代理捕捉網絡信號進行環境部署來分析APP的延遲（加載）時間，內容，提出HTTP優化建議，讓開發者能夠在APP上線前提前預知APP在較差網絡環境下的表現，以便提前發現問題，進行有針對性優化。讓APP在任何網絡情況下，都能表現自如。
核心流程 網絡請求》代理proxy》進行目標操作（修改返回值&延遲&丟包等）》返回給移動端
【模擬方法】
1.通過應用層或者傳輸層的代理服務器，在代理服務器上設置一些模擬惡劣網絡環境的參數，使得通過這些代理服務器的流量都被轉化為弱網下的流量。如利用fiddler，Charles等具有代理服務器功能的網絡流量分析軟件來實現。
2.通過利用一些更底層的驅動層面的服務，通過控制網卡收包和發包的行為，來模擬弱網環境。如dummynet的ipfw驅動等。
3.通過建立一個可控的網關，在網關上部署弱網的相關程序。
【實際操作】具有代理服務器功能的網絡流量分析軟件
一，Charles
通過抓包工具Charles（如何配置Charles），設置延遲，進行模擬不同的網絡情況
配置好Charles后，選擇throttle setting設置弱網環境
Throttle settings
Throttle preset選擇弱網環境目標：2G和3G
注意：也可以在Bandwidth（帶寬）中選擇上傳，下載數值
二，Fiddler
Fiddler是一個HTTP協議調試代理工具，跨瀏覽器，跨系統，跨平台的免費webdebug代理服務器，它能夠記錄並檢查所有你的電腦和互聯網之間的HTTP通訊，設置斷點，查看所有的“進出”Fiddler的數據（指html,cookie,js,css等文件）。Fiddler是用C#寫出來的，它包含一個簡單卻功能強大的基於Jscrip .net事件腳本子系統，目前無法在mac ,os上適用，可以在win上適用。
Fiddler 界面說明
1.抓包
PC端設置網絡——》手機端使用PC端網絡代理
1）查找本機PC端網絡地址——》fiddler options 選擇connections設置端口信息&勾選allow remote computers to connect
2）手機端再設置———》選擇手動代理，並輸入PC端網絡代理
選擇fiddler options
勾選allow remote computers to connect
3）網絡連接成功·，則在移動端使用目標URL或者應用，得到請求和返回信息
4）設置斷點
fiddler菜單欄——》rules——》automatic Breakpoints->選擇斷點方式，這種方式下設置的斷點會對之后所有http請求有效。
有兩個斷點位置：
a.before response 。也就是發送請求之后，fiddler代理中轉之前，這時可以修改請求的數據。
b.after response。也就是服務器響應之后，在fiddler將響應中轉給客戶端之前，這時可以修改響應的結果。
設置響應后斷點，可以通過命令進行設置，bpafter localhost
5）修改返回值
觀察inspector，頁面內容出現變化（說明攔截成功）
切換到textView子面板，選擇需要修改的部分，然后點擊“run to complete” ,便可回送修改后的響應
PS：終止斷點的方式有
1>在rules——》auto breakpoint 中disabled斷點即可；
2>在inspector界面點擊“run complete”即可終止本次AHTTP請求的斷點
3>輸入Go命令，也會使得當前的請求跳過斷點
2.模擬弱網
1）rules——》customer rules（或者Ctrl+r）
選擇Customize Rules
2）Ctrl+F組合鍵調出搜索對話框，輸入m_Simulate進行搜索，找到如下代碼框
upload 代表上傳速度
download 代表下載速度
完成設置——》保存——》點擊Perfermance——》點擊Simulate Modem Speeds ，完成弱網模擬功能的打開
m_SimulateModem
完成弱網工具環境搭建，來梳理下弱網測試場景和測試點。
一，【弱網測試場景】
既然APP弱網測試中，異常測試屬於必須考慮的測試項，哪些業務適合驗證，哪些業務不需要驗證呢？
1.結合APP本身屬性
比如社交類APP（聊天，搶紅包）對網絡環境依賴信大且用戶關注度高，弱網環境下需要重點關注。
結合互聯網金融APP，申購流程中創建訂單后是否支付成功，用戶關注度最高（涉及扣費）。例如弱網環境，創建訂單失敗，用戶關注是否被扣費；創建訂單成功后，支付失敗，再次支付是否重復扣費。
2.使用頻率&易遇到弱網的場景
比如微博APP【觀看小視頻】，用戶在碎片時間極易【觀看小視屏】（APP用戶喜歡使用碎片化時間進行娛樂操作），同時增加了【刷微博】（微博小視頻和刷微博 操作場景重合），此處就需要加強弱網環境測試。
比如金融APP ，用戶在碎片化時間使用金融APP，領取獎品，查看理財類新聞，查看收益
好的例子：微信的升級就會監聽用戶是否插着電，連着WiFi，一旦監聽到了，就馬上告訴你，現場可以升級。
二，【弱網環境測試點總結】
1.場景：弱網環境下某個操作，響應時間
原因：APP用戶等待時間容忍度低，弱網環境loading超過5S,用戶很容易kill應用后再進入應用
【測試點】性能測試中，加入弱網環境測試點，檢測各個場景網絡請求的API消耗時間（此處可以放入性能測試中，作為衡量APP性能好壞的指標）
2.場景：弱網環境下直至超時（UI界面友好度&APP是否穩定）
原因：容錯機制主要是考慮弱網情況下帶來的不穩定，常見的問題是：loading超時導致ANR或者crash
【測試點】弱網環境直至超時，判斷為斷網狀態，UI界面和提示，友好且理解無歧義
3.場景：斷網后情況下，是否自動重發請求
原因：不同模塊，開發對請求處理不同。測試前可了解，代碼是否支持自動重復請求，自動重發的頻率是什么？
【測試點】：斷網后恢復網絡，是否堆積網絡請求（目前來說，理財模塊，當10S左右無反應，將會重發請求），此時請求和返回正常情況下，是否出現異常情況。比如一次支付操作，斷網后堆積多個支付請求，恢復網絡后因堆積多個支付請求，是否完成多次支付。
PS：斷網后恢復網絡，考慮APP進行操作目的是否傷害用戶體驗，通過哪種手段可以達到操作目的同時用戶體驗無感或者降低傷害
比如，微信希望在線升級某些內容，會自動監聽用戶是否插着電或者連着WIFi，一旦檢測到，APP自動升級。
1）插電場景，確保升級過程中，耗電不會導致手機低電量甚至沒電
2）WiFi場景，確保升級過程中，流量消耗不會使用用戶話費中流量包，不會導致因消耗話費流量影響用戶體驗
4.網絡請求中，kill進程（導致APP登錄狀態下掉線）
登錄同一賬號成功，應該不繼續相同網絡請求（要和RD確認，程序實際實現）
登錄不同賬號成功，應該不繼續相同網絡請求（要和RD確認，程序實際實現）
三，【常見弱網問題和原因分析】
1.場景：上傳大圖或者多圖時，在弱網環境下出現進度條走到一半卡住，然后又從頭開始
原因：采用分段上傳的方式，直至請求超時，分段請求沒有結束，代碼邏輯不對，導致每次重試都從頭上傳，一直循環。
2.場景：在弱網環境下容易出現登錄不上或者登陸后立即掉線
原因：登錄沒有緩沖機制，而請求超時時間的設置沒有區分網絡情況。
解決方案：建議開發針對WiFi，2g，3G，4G設置不同的超時時間
3.場景：弱網環境下，請求的數據返回時間較長，等待過程中，如果頁面上其它的控件仍可以操作，則容易出現異常情況（閃退，觸發底部時獲得原頁面請求數據）
原因：依賴數據的控件操作，在數據返回前沒有做兼容處理。
4.場景：搜索時輸入關鍵字會連續發請求，停下時，顯示最終的關鍵字搜索結果，但很快又會被前面的關鍵字搜索結果覆蓋了；
原因：中間的返回請求較慢，顯示了最終的結果后，之前的請求返回的數據應不做處理。