如何模擬弱網測試

來源：https://www.jianshu.com/p/06be11140413

淺談弱網測試

 

siyu8023 關注

2016.12.07 20:38* 字數 2970 閱讀 7994評論 3喜歡 20

【背景】

弱網測試，屬於健壯性測試的內容。隨着國內移動端迅猛發展，大大增長用戶碎片化使用移動端的機率。想象一下，用戶在地鐵裏，巴士上，甚至是電梯，車庫等場景使用APP，咱們就須要針對這些場景的弱網環境下，驗證出現丟包、延時軟件的處理機制，避免因用戶體驗不友好形成用戶的流失。

1.用戶體驗

APP使用過程當中，弱網的高延遲和高丟包，在實時性要求很是高的場景，容易傷害用戶體驗

2.非正常狀況下，出現bug機率會增長

在解決平常的支持需求中，常常會遇到一些用戶反饋一些沒法簡單復現的bug，有很大一部分的bug是因爲用戶自身的網絡環境波動，或者是自己網絡環境就較爲惡劣，而服務在面對這種惡劣的網絡環境的健壯性不夠，致使會出現一些意想不到的bug

【原理】

使用代理捕獲網絡信號進行環境部署來分析APP的延遲（加載）時間、內容，提出HTTP優化建議，讓開發者可以在APP上線前提早預知app在較差網絡環境下的表現，以便提早發現問題，進行有針對性優化。讓APP在任何網絡狀況下，都能表現自如，出類拔萃

核心流程 網絡請求—》代理proxy—》進行目標操做（修改返回值&延遲&丟包等）—》返回給移動端（見下圖）

 

 

網絡代理原理圖

【模擬方法】

當前模擬惡劣網絡環境主要能夠經過如下這些手段實現：

經過應用層或者傳輸層的代理服務器，經過在代理服務器上設置一些模擬惡劣網絡環境的參數，使得經過這些代理服務器的流量都被轉化爲惡劣網絡環境下的流量。如利用Fiddler，Charles等具備代理服務器功能的網絡流量分析軟件來實現。

經過利用一些更底層的驅動層面的服務，經過控制網卡的收包發包的行爲，來模擬惡劣的網絡環境。如dummynet的ipfw驅動等。

經過創建一個可控的網關，在網關上部署模擬惡劣環境的相關程序，全部須要藉助該網關進行轉發的流量都會被模擬爲惡劣網絡條件。Linux下的netem就提供了這類支持。

ps：實際生活中,電梯裏 or 地鐵裏 模擬用戶體驗測試是個不錯的選擇~~~O(∩_∩)O~~

【實際操做】具備代理服務器功能的網絡流量分析軟件

1、Charles

經過抓包工具Charles（如何配置Charles），設置延遲，進行模擬不一樣的網絡狀況

配置好Charles後，正常聯網，選擇throttle settings 設置弱網環境

 

 

Throttle Settings

Throttle preset 選擇弱網環境目標：2G或者3G

ps：也可在在Bandwidth（帶寬）中選擇上傳、下載數值

2、Fiddler

Fiddler是一個http協議調試代理工具，跨瀏覽器、跨系統、跨平臺的免費Web Debug代理服務器，它可以記錄並檢查全部你的電腦和互聯網之間的http通信，設置斷點，查看全部的「進出」Fiddler的數據（指cookie,html,js,css等文件，這些均可以讓你胡亂修改的意思）。Fiddler 是用C#寫出來的,它包含一個簡單卻功能強大的基於JScript .NET 事件腳本子系統，目前沒法再mac OS上適用，能夠在win上使用。

 

 

Fiddler界面說明

 

1.抓包

PC端設置網絡—》手機端使用PC端網絡代理

1）查找本機PC端網絡地址—》fidder options選擇connections 設置端口信息&勾選allow remote computers to connect

2）手機端在設置—》選擇手動代理，並輸入PC端網絡代理

 

 

選擇Fiddler Options

 

 

勾選Allow remote computers to connect

 

3）網絡鏈接成功，則在移動端使用目標URL或者使用應用，獲得請求和返回信息

4）設置斷點

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 命令，也會使得當前的請求跳過斷點

2.模擬弱網

1）Rules—》customer rules（或者ctrl+r）

 

 

選擇Customize Rules

2）Ctrl+F組合鍵調出搜索對話框，鍵入m_Simulate進行搜索，找到以下代碼框

upload表明 上傳速度

download表明下載速度

完成設置—》保存—》點擊Performance-->點擊Simulate Modem Speeds，完成弱網模擬功能的打開

 

m_SimulateModem

完成弱網工具環境搭建，來梳理下弱網測試場景和測試點。

1、【弱網測試場景】

既然APP異常測試中，弱網測試屬於必須考慮的測試項，哪些業務適合驗證，哪些不須要驗證呢？如下是我的淺見，歡迎拋磚引玉：

1.結合APP自己屬性

好比社交類APP（聊天、搶紅包）對網絡環境依賴性大且用戶關注度高，弱網環境下須要重點關注。

結合互聯網金融APP，申購流程中建立訂單後是否支付成功，用戶關注度最高（涉及扣費）。例如 弱網環境，建立訂單失敗，用戶關注是否被扣費；建立訂單成功後支付失敗，再次支付是否重複扣費等

2.使用頻率&易遇到弱網的場景

好比微博APP【觀看小視頻】，用戶在碎片時間極易【觀看小視頻】（APP用戶喜歡使用碎片化時間進行娛樂操做），同時增長了【刷微博】（微博小視頻和刷微博 操做場景重合）此處就須要增強弱網環境測試

好比金融APP，用戶在碎片化時間使用金融APP，領取獎品、查看理財類新聞、查看收益

好的例子：據我所知，微信的升級就會監聽用戶是否插着電，連着wifi，一旦監聽到了，就立刻告訴你，現場能夠升級

2、【弱網環境測試點總結】

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確認，程序實際實現）

3、【常見弱網問題和緣由分析】

1.場景：上傳大圖或者多圖時，在弱網絡環境下出現進度條走到一半卡住而後又從頭開始

緣由：採用分段上傳方式，直至請求超時，分段傳輸沒有結束，代碼邏輯不對，致使每次重試都重頭上傳，一直循環

2.場景：在弱網絡環境下容易出現登陸不上或者登錄後當即掉線

緣由：登陸沒有緩衝機制，而請求超時時間的設置沒有區分同網絡狀況

解決方案：建議開發針對wifi、2g、3g、4g設置不一樣的超時時間

3.場景：弱網絡環境下，請求的數據返回時間較長，等待的過程當中，若是頁面上的相關控件仍然能夠操做，則容易出現異常現（閃退現象、觸發底部時得到原頁面請求數據）

緣由：依賴數據的控件操做，在數據返回前沒有作兼容處理

4.場景：搜索時輸入關鍵字會連續發請求，停下時，顯示最終的關鍵字搜索結果，但很快又會被前面的關鍵字搜索結果覆蓋了；

緣由：中間的請求返回較慢，顯示了最終的結果後，以前的請求返回的數據應不作處理。