在移動互聯網時代,作為軟件測試工程師,fiddler絕對是值得掌握並添加進技術棧里的工具之一。
那么,fiddler在日常的測試工作中,一般都有哪些常見的應用場景呢?
根據以往工作經驗,大概有如下4類應用場景:
-
輔助定位bug;
-
構建模擬測試場景;
-
APP弱網模擬測試;
-
前端性能分析及優化;
1、輔助定位bug
合格的軟件測試工程師,不僅僅需要能夠發現bug,還需要能透過bug表象,分析出問題根本原因,從而提升bug的解決效率,突顯bige。
通過fiddler可以抓取request和response,通過對參數進行分析,可以定位是前端問題還是后台問題。
例如:在APP界面輸入數據,點擊下一步時,提示錯誤;這時候不能判斷問題的根本原因在哪里,是前端頁面作限制導致?還是前端request的參數問題,又或者是后台程序掛了?

這個時候就可以通過fiddler抓包,分析request、response來判斷問題根本原因所在。
(往往有些測試就是直接把APP頁面報錯信息截個圖就提缺陷了,而沒有去作bug定位,這樣的缺陷又往往被開發人員所抱怨)
1.1、實例--APP抓包
前提:APP、fiddler在同一局域網
1.1.1、fiddler設置
Tools>Options>Connections,勾選Allow remote computers to connect,同時記住fiddler listen on port的端口號。

1.1.2、獲取pc端ip
開始菜單>cmd>ipconfig

1.1.3、手機WiFi設置代理
設置>WLAN>進入WiFi頁面>代理>手動,填寫主機名(pc端ip)、端口(fiddler listen on port的端口),保存即可進行抓包操作了。

PS:若APP的請求是https協議,則還需要一個下載證書操作:
手機瀏覽器打開:http://ip:port,點擊fiddler certficate字樣下載安裝證書即可。(ip為pc端ip,port為fiddler listen on port的端口)
;
同時,在fiddler,Tools>Options>HTTPS,勾選capture https connects。
1.1.4、過濾請求
fiddler抓包時會把手機上所有的請求都鋪抓,這時就需要進行過濾。
fiddler右邊有個Filters,打開該頁面后,勾選use Filters,然后根據需要設置過濾規則,再點擊actions>run filterset now即可實現過濾。

PS:測試完成后,記得把WiFi代理恢復原樣,不然手機無法正常上網。
2、構建模擬測試場景(mock)
在測試過程中,為了測試覆蓋率,往往需要執行很多場景的用例來驗證某一功能在各種場景下的業務處理能力,包括正常、異常的場景;
而僅僅通過頁面端來發起交易,往往是不能夠模擬所有場景的;
例如:常見的登錄功能,輸入超出長度的的賬號、密碼,一般都是在前端就提示錯誤了,這樣就不能夠測試服務端接收到超出長度的請求時的處理場景了。

又例如:天氣預報,測試時只能根據當前的城市、天氣情況來測試,如何快速的將全部天氣信息匹配的icon和出行提示驗證完畢,這就可以通過修改response數據來實現測試場景。
利用fiddler的Breakpoints、AutoResponsder等功能,可以通過修改request或者response的參數,來實現構建模擬測試場景。
2.1、實例--修改request參數
fiddler中選中Rules->Automatic Breakpoints->Before Requests;
頁面進行業務操作,此時在fiddler頁面可以看見對應的請求圖標會有個紅色通行標示,表示請求過程中設置了斷點,客戶端發出的請求被fiddler攔截了,如下圖所示:

在左側點擊這個請求,在右側Inspectors->TextView或WebForms等界面下會看到請求發送的具體內容,直接修改需要模擬的測試場景數據,再點擊右下頁面的run to complete按鈕即可。

2.2、實例--修改response參數
fiddler中選中Rules->Automatic Breakpoints->After Requests;
頁面進行業務操作,此時在fiddler頁面可以看見對應的請求圖標會有個紅色禁行標示,表示響應過程中設置了斷點,客戶端發出的請求被fiddler攔截了。
在右下頁面的響應tab頁中,修改需要模擬的響應測試場景數據,再點擊run to complete按鈕即可。
PS:還可以通過命令行bpu的方式來實現斷點功能。
3、APP弱網模擬測試
移動端測試區別於PC端測試的一點就是網絡的多變性;不同的網絡環境和網絡制式的差異,都會對用戶使用app造成一定影響。
例如:進地鐵、上公交、進電梯等,如果app沒有對各種網絡異常進行兼容處理,那么用戶可能在日常生活中遇到APP閃退、ANR、數據丟失等問題。因此,app網絡測試,特別是弱網測試顯得尤為重要。

利用fiddler的Simulate Modem Speeds功能,可以通過設置網絡的上傳、下載的網絡流量大小來達到模擬弱網環境,從而實現弱網模擬測試,即通過延遲發送數據或接收的數據的時間來限制網絡的下載速度和 上傳速度,從而達到限速的效果。
3.1、實例--APP弱網測試
fiddler中選中Rules->Cutomize Rules,在文件中搜索關鍵字:m_SimulateModem;
修改m_SimulateModem值為true,即開啟網絡模擬:
var m_SimulateModem: boolean = false;
修改uploaded、downloaded的數據來模擬不同的弱網場景:
if (m_SimulateModem) {
// Delay sends by 300ms per KB uploaded.
oSession["request-trickle-delay"] = "384";
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = "2560";
}
上傳1KB需要300ms,轉化一下上傳速度:1Kb/0.3s = 10/3(KB/s),如果想設置上傳的速度為50KB/s,你則需要設置Delay 時間為 20ms;(=1000/50)
PS:設置之后可以通過http://www.speedtest.cn/在線測試網速,看是否生效;
2G一般上行/下行速率約為:2.7、9.6kbs,模擬設置為:uploaded 約 2962 ms,downloaded 約 833 ms;(弱網一般指2G網絡)
3G一般上行/下行速率約為:384、2560kbs,設置為:uploaded 約 2.6 ms,downloaded 約 0.39 ms;
PS:弱網模擬還可以通過其它工具實現,比如360WiFi的限速設置等;
3.2、擴展弱網絡規則
可能在測試中不會想要一個同樣虛弱的網絡環境,而是隨機強弱的網絡,這樣比較貼切真實情況,那么可以修改上述代碼為:
static function randInt(min, max) {
return Math.round(Math.random()*(max-min)+min);
}
if (m_SimulateModem) {
// Delay sends by 300ms per KB uploaded.
oSession["request-trickle-delay"] = ""+randInt(1,2000);
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = ""+randInt(1,2000);
}
這里的randInt(1,2000)應該很好理解,代表1-2000中的一個隨機整數,這樣就會出現偶爾有延遲偶爾網絡又良好的情況。
4、前端性能分析及優化
前端性能在一定程度可以提升用戶體驗,而前端的性能數據可以通過fiddler的Statistics和Timeline來獲取,從而為性能分析及優化提供依據。
4.1、實例--前端性能數據獲取分析
通過陳列出所有的HTTP通信量,Fiddler可以很容易的向您展示哪些文件生成了您當前請求的頁面。使用Statistics頁簽,用戶可以通過選擇多個會話來得來這幾個會話的總的信息統計,比如多個請求和傳輸的字節數。
選擇第一個請求和最后一個請求,可獲得整個頁面加載所消耗的總體時間。從條形圖表中還可以分別出哪些請求耗時最多,從而對頁面的訪問進行訪問速度優化。

同時,還可以通過Timeline分析資源加載時序圖,可以很直觀地看到頁面上各個資源加載過程所需要的時間和先后順序,有利於找出加載過程中比較耗時的文件資源,幫助我們有針對性地進行性能優化。


5、小結
總的來說,fiddler是移動互聯網測試的利器,除以上介紹的這些常見的日用場景外,還有很多其它用途,如域名的重定向、API的測試等,這里就不一一列舉,如有興趣,可抽空一起探討。
