【背景】

弱網(wǎng)測試,，屬于健壯性測試的內(nèi)容,。隨著國內(nèi)移動端迅猛發(fā)展，大大增加用戶碎片化使用使用APP的,。想象一下,，用戶在地鐵里，巴士上,，甚至是電梯,，車庫等場景使用APP，我們就需要針對這些場景的弱網(wǎng)環(huán)境下,，驗證出現(xiàn)丟包,、延時軟件的處理機制，避免因用戶體驗不友好造成用戶的流失,。

1.用戶體驗

APP使用過程中,，弱網(wǎng)的高延遲和高丟包，在實時性要求非常高的場景,，容易傷害用戶體驗

2.非正常情況下,，出現(xiàn)bug概率會增加

在解決日常的支持需求中，經(jīng)常會遇到一些用戶反饋一些無法簡單復現(xiàn)的bug,，有很大一部分的bug是由于用戶自身的網(wǎng)絡環(huán)境波動,，或者是本身網(wǎng)絡環(huán)境就較為惡劣，而服務在面對這種惡劣的網(wǎng)絡環(huán)境的健壯性不夠,，導致會出現(xiàn)一些意想不到的bug

【原理】

使用代理捕獲網(wǎng)絡信號進行環(huán)境部署來分析APP的延遲（加載）時間,、內(nèi)容，提出HTTP優(yōu)化建議,，讓開發(fā)者能夠在APP上線前提前預知app在較差網(wǎng)絡環(huán)境下的表現(xiàn),，以便提前發(fā)現(xiàn)問題，進行有針對性優(yōu)化,。讓APP在任何網(wǎng)絡情況下,，都能表現(xiàn)自如，出類拔萃

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

網(wǎng)絡代理原理圖

【模擬方法】

當前模擬惡劣網(wǎng)絡環(huán)境主要可以通過以下這些手段實現(xiàn)：

通過應用層或者傳輸層的代理服務器,，通過在代理服務器上設置一些模擬惡劣網(wǎng)絡環(huán)境的參數(shù),，使得通過這些代理服務器的流量都被轉(zhuǎn)化為惡劣網(wǎng)絡環(huán)境下的流量。如利用Fiddler,，Charles等具有代理服務器功能的網(wǎng)絡流量分析軟件來實現(xiàn),。

通過利用一些更底層的驅(qū)動層面的服務，通過控制網(wǎng)卡的收包發(fā)包的行為,，來模擬惡劣的網(wǎng)絡環(huán)境,。如dummynet的ipfw驅(qū)動等。

通過建立一個可控的網(wǎng)關,，在網(wǎng)關上部署模擬惡劣環(huán)境的相關程序,，所有需要借助該網(wǎng)關進行轉(zhuǎn)發(fā)的流量都會被模擬為惡劣網(wǎng)絡條件。Linux下的netem就提供了這類支持,。

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

【實際操作】具有代理服務器功能的網(wǎng)絡流量分析軟件

一,、Charles

通過抓包工具Charles（如何配置Charles），設置延遲,，進行模擬不同的網(wǎng)絡情況

配置好Charles后,，正常聯(lián)網(wǎng)，選擇throttle settings 設置弱網(wǎng)環(huán)境

Throttle Settings

Throttle preset 選擇弱網(wǎng)環(huán)境目標：2G或者3G

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

二,、Flidder

Fiddler是一個http協(xié)議調(diào)試代理工具，跨瀏覽器,、跨系統(tǒng),、跨平臺的免費Web Debug代理服務器，它能夠記錄并檢查所有你的電腦和互聯(lián)網(wǎng)之間的http通訊,，設置斷點,，查看所有的“進出”Fiddler的數(shù)據(jù)（指cookie,html,js,css等文件，這些都可以讓你胡亂修改的意思）,。Fiddler 是用C#寫出來的,它包含一個簡單卻功能強大的基于JScript .NET 事件腳本子系統(tǒng),，目前無法再mac OS上適用，可以在win上使用,。

Fiddler界面說明

1.抓包

PC端設置網(wǎng)絡—》手機端使用PC端網(wǎng)絡代理

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

2）手機端在設置—》選擇手動代理,，并輸入PC端網(wǎng)絡代理

選擇Fiddler Options

勾選Allow remote computers to connect

3）網(wǎng)絡連接成功,，則在移動端使用目標URL或者使用應用，得到請求和返回信息

4）設置斷點

A fiddler菜單欄->rules->automatic Breakpoints->選擇斷點方式,，這種方式下設定的斷點會對之后的所有HTTP請求有效,。

有兩個斷點位置：

a） before response。也就是發(fā)送請求之后,，但是Fiddler代理中轉(zhuǎn)之前,，這時可以修改請求的數(shù)據(jù)。

b.）after response,。也就是服務器響應之后,，但是在Fiddler將響應中轉(zhuǎn)給客戶端之前。這時可以修改響應的結(jié)果

B  設置響應后斷點（after response breakpoint）,可以通過命令行設置：bpafter localhost

5)修改返回值

觀察inspector,，頁面內(nèi)容出現(xiàn)變化（說明攔截成功）

切換到textView子面板,，選擇需要修改的部分，然后點擊 “run to complete“,，便可回送修改后的響應

ps：終止斷點的方式有：

1> 在rules->auto breakpoint中disabled斷點即可,。

2> 在inspector界面點擊“run complete“即會終止本次HTTP請求的斷點。

3>輸入Go 命令,，也會使得當前的請求跳過斷點

2.模擬弱網(wǎng)

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

選擇Customize Rules

2）Ctrl F組合鍵調(diào)出搜索對話框,，鍵入m_Simulate進行搜索，找到如下代碼框

upload代表 上傳速度

download代表下載速度

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

m_SimulateModem

完成弱網(wǎng)工具環(huán)境搭建,，來梳理下弱網(wǎng)測試場景和測試點。

一,、【弱網(wǎng)測試場景】

既然APP異常測試中,，弱網(wǎng)測試屬于必須考慮的測試項，哪些業(yè)務適合驗證,，哪些不需要驗證呢,？以下是個人淺見，歡迎拋磚引玉：

1.結(jié)合APP本身屬性

比如社交類APP（聊天,、搶紅包）對網(wǎng)絡環(huán)境依賴性大且用戶關注度高,，弱網(wǎng)環(huán)境下需要重點關注。

結(jié)合互聯(lián)網(wǎng)金融APP,，申購流程中創(chuàng)建訂單后是否支付成功,，用戶關注度最高（涉及扣費）。例如 弱網(wǎng)環(huán)境,，創(chuàng)建訂單失敗,，用戶關注是否被扣費；創(chuàng)建訂單成功后支付失敗,，再次支付是否重復扣費等

2.使用頻率&易遇到弱網(wǎng)的場景

比如微博APP【觀看小視頻】,，用戶在碎片時間極易【觀看小視頻】（APP用戶喜歡使用碎片化時間進行娛樂操作）,，同時增加了【刷微博】（微博小視頻和刷微博 操作場景重合）此處就需要加強弱網(wǎng)環(huán)境測試

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

好的例子：據(jù)我所知,，微信的升級就會監(jiān)聽用戶是否插著電，連著wifi,，一旦監(jiān)聽到了,，就馬上告訴你，現(xiàn)場可以升級

二,、【弱網(wǎng)環(huán)境測試點總結(jié)】

1.場景：弱網(wǎng)環(huán)境下某個操作響應時間

原因：APP用戶對等待時間容忍度低,，若弱網(wǎng)環(huán)境loading超過5s，用戶很容易kill應用后再次進入應用

【測試點】性能測試中,，加入弱網(wǎng)環(huán)境測試點,，檢測各個場景網(wǎng)絡請求的 API 消耗時間（此處可以放入性能測試中，做為衡量APP性能好壞的指標）

2.場景：弱網(wǎng)環(huán)境下直至超時,，UI界面友好度&APP是否穩(wěn)定

原因：容錯機制主要是考慮弱網(wǎng)情況下帶來的不穩(wěn)定,，常見的問題是：loading超時導致ANR or crash

【測試點】弱網(wǎng)環(huán)境直至超時，判定為斷網(wǎng)狀態(tài),，UI界面和提示,，友好且理解無歧義

3.場景：斷網(wǎng)后環(huán)境下，是否自動重發(fā)請求

原因：不同模塊,，開發(fā)對請求處理不同,。測試前可了解，代碼是否支持自動重復請求,，自動重發(fā)請求的頻率是什么,？

【測試點】斷網(wǎng)后恢復網(wǎng)絡，是否堆積網(wǎng)絡請求（目前來說 理財模塊 當10s左右無返回 則會重發(fā)請求）,，此時請求和返回正常情況下,，是否出現(xiàn)異常情況。比如1次支付操作,，斷網(wǎng)后堆積多個支付請求,，恢復網(wǎng)絡后因堆積多個支付請求，是否完成多次支付

ps：斷網(wǎng)后恢復網(wǎng)絡,，考慮APP進行操作目的是否對傷害用戶體驗,，通過哪種手段 可以達到操作目的同時用戶體驗無感或者低傷害

比如，微信希望在線升級某些內(nèi)容,，會自動監(jiān)聽用戶是否插著電 or 連著wifi,，一旦監(jiān)聽符合上述場景,，APP自動升級：

1）插電場景 確保升級過程中，耗電不會導致手機低電量甚至沒電

2）wifi場景,，確保升級過程中,，流量消耗不會使用用戶話費中流量包，不會導致因消耗話費流量傷害用戶體驗

4.網(wǎng)絡請求中,，kill進程 （導致APP登錄態(tài)掉線）

登錄同一個賬號成功,，應該不繼續(xù)相同網(wǎng)絡請求（要和RD確認，程序?qū)嶋H實現(xiàn)）

登錄不同賬號成功,，應該不繼續(xù)相同網(wǎng)絡請求（要和RD確認,，程序?qū)嶋H實現(xiàn)）

三、【常見弱網(wǎng)問題和原因分析】

1.場景：上傳大圖或者多圖時,，在弱網(wǎng)絡環(huán)境下出現(xiàn)進度條走到一半卡住然后又從頭開始

原因：采用分段上傳方式,，直至請求超時，分段傳輸沒有結(jié)束,，代碼邏輯不對,，導致每次重試都重頭上傳，一直循環(huán)

2.場景：在弱網(wǎng)絡環(huán)境下容易出現(xiàn)登錄不上或者登陸后立即掉線

原因：登錄沒有緩沖機制,，而請求超時時間的設置沒有區(qū)分同網(wǎng)絡情況

解決方案：建議開發(fā)針對wifi,、2g、3g,、4g設置不同的超時時間

3.場景：弱網(wǎng)絡環(huán)境下,，請求的數(shù)據(jù)返回時間較長，等待的過程中,，如果頁面上的相關控件仍然可以操作,，則容易出現(xiàn)異常現(xiàn)（閃退現(xiàn)象,、觸發(fā)底部時獲得原頁面請求數(shù)據(jù)）

原因：依賴數(shù)據(jù)的控件操作,，在數(shù)據(jù)返回前沒有做兼容處理

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

原因：中間的請求返回較慢,，顯示了最終的結(jié)果后,，之前的請求返回的數(shù)據(jù)應不做處理。