fiddler常見的應用場景

   在移動互聯網時代，做爲軟件測試工程師，fiddler絕對是值得掌握並添加進技術棧裏的工具之一。

 

那麼，fiddler在平常的測試工做中，通常都有哪些常見的應用場景呢？

 

根據以往工做經驗，大概有以下4類應用場景：

• 輔助定位bug；

• 構建模擬測試場景；

•  APP弱網模擬測試；

•  前端性能分析及優化；

    

 

---

 

 

一、輔助定位bug

 

        合格的軟件測試工程師，不只僅須要可以發現bug，還須要能透過bug表象，分析出問題根本緣由，從而提高bug的解決效率，突顯bige。

    

經過fiddler能夠抓取request和response，經過對參數進行分析，能夠定位是前端問題仍是後臺問題。

    

例如：在APP界面輸入數據，點擊下一步時，提示錯誤；這時候不能判斷問題的根本緣由在哪裏，是前端頁面做限制致使？仍是前端request的參數問題，又或者是後臺程序掛了？

 

    

這個時候就能夠經過fiddler抓包，分析request、response來判斷問題根本緣由所在。

    

（每每有些測試就是直接把APP頁面報錯信息截個圖就提缺陷了，而沒有去做bug定位，這樣的缺陷又每每被開發人員所抱怨）

 

 

1.一、實例--APP抓包

 

前提：APP、fiddler在同一局域網

 

1.1.一、fiddler設置

 

Tools>Options>Connections，勾選Allow remote computers to connect，同時記住fiddler listen on port的端口號。    

 

    

    

    

1.1.二、獲取pc端ip

 

開始菜單>cmd>ipconfig

    

 

 

1.1.三、手機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.四、過濾請求

    fiddler抓包時會把手機上全部的請求都鋪抓，這時就須要進行過濾。

    

fiddler右邊有個Filters，打開該頁面後，勾選use Filters，而後根據須要設置過濾規則，再點擊actions>run filterset now便可實現過濾。

    

    

    

   

    

PS：測試完成後，記得把WiFi代理恢復原樣，否則手機沒法正常上網。

    

 

---

 

二、構建模擬測試場景(mock)

 

        在測試過程當中，爲了測試覆蓋率，每每須要執行不少場景的用例來驗證某一功能在各類場景下的業務處理能力，包括正常、異常的場景；

    

而僅僅經過頁面端來發起交易，每每是不可以模擬全部場景的；

    

例如：常見的登陸功能，輸入超出長度的的帳號、密碼，通常都是在前端就提示錯誤了，這樣就不可以測試服務端接收到超出長度的請求時的處理場景了。

    

 

又例如：天氣預報，測試時只能根據當前的城市、天氣狀況來測試，如何快速的將所有天氣信息匹配的icon和出行提示驗證完畢，這就能夠經過修改response數據來實現測試場景。

    

    

利用fiddler的Breakpoints、AutoResponsder等功能，能夠經過修改request或者response的參數，來實現構建模擬測試場景。

 

 

 

2.一、實例--修改request參數

 

     fiddler中選中Rules->Automatic Breakpoints->Before Requests；

    

頁面進行業務操做，此時在fiddler頁面能夠看見對應的請求圖標會有個紅色通行標示，表示請求過程當中設置了斷點，客戶端發出的請求被fiddler攔截了，以下圖所示：

 

    

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

    

    

 

 

 2.二、實例--修改response參數

 

    fiddler中選中Rules->Automatic Breakpoints->After Requests；

    

頁面進行業務操做，此時在fiddler頁面能夠看見對應的請求圖標會有個紅色禁行標示，表示響應過程當中設置了斷點，客戶端發出的請求被fiddler攔截了。

    

在右下頁面的響應tab頁中，修改須要模擬的響應測試場景數據，再點擊run to complete按鈕便可。

    

 

 PS：還能夠經過命令行bpu的方式來實現斷點功能。

    

    

 

---

 

 

 三、APP弱網模擬測試

 

        移動端測試區別於PC端測試的一點就是網絡的多變性；不一樣的網絡環境和網絡制式的差別，都會對用戶使用app形成必定影響。

    

例如：進地鐵、上公交、進電梯等，若是app沒有對各類網絡異常進行兼容處理，那麼用戶可能在平常生活中遇到APP閃退、ANR、數據丟失等問題。所以，app網絡測試，特別是弱網測試顯得尤其重要。

 

 

 

    

利用fiddler的Simulate Modem Speeds功能，能夠經過設置網絡的上傳、下載的網絡流量大小來達到模擬弱網環境，從而實現弱網模擬測試，即經過延遲發送數據或接收的數據的時間來限制網絡的下載速度和 上傳速度，從而達到限速的效果。

 

 

 3.一、實例--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.七、9.6kbs，模擬設置爲：uploaded 約 2962 ms，downloaded 約 833 ms;（弱網通常指2G網絡）

 

3G通常上行/下行速率約爲：38四、2560kbs，設置爲：uploaded 約 2.6 ms，downloaded 約 0.39 ms;

 

 

PS：弱網模擬還能夠經過其它工具實現，好比360WiFi的限速設置等；

 

 

 

3.二、擴展弱網絡規則

        可能在測試中不會想要一個一樣虛弱的網絡環境，而是隨機強弱的網絡，這樣比較貼切真實狀況，那麼能夠修改上述代碼爲：

        

 

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中的一個隨機整數，這樣就會出現偶爾有延遲偶爾網絡又良好的狀況。

 

 

---

 

 

 

四、前端性能分析及優化

        前端性能在必定程度能夠提高用戶體驗，而前端的性能數據能夠經過fiddler的Statistics和Timeline來獲取，從而爲性能分析及優化提供依據。

    

    

  

4.一、實例--前端性能數據獲取分析

        經過陳列出全部的HTTP通訊量，Fiddler能夠很容易的向您展現哪些文件生成了您當前請求的頁面。使用Statistics頁籤，用戶能夠經過選擇多個會話來得來這幾個會話的總的信息統計，好比多個請求和傳輸的字節數。

 

選擇第一個請求和最後一個請求，可得到整個頁面加載所消耗的整體時間。從條形圖表中還能夠分別出哪些請求耗時最多，從而對頁面的訪問進行訪問速度優化。

    

    

 

 

 

同時，還能夠經過Timeline分析資源加載時序圖，能夠很直觀地看到頁面上各個資源加載過程所須要的時間和前後順序，有利於找出加載過程當中比較耗時的文件資源，幫助咱們有針對性地進行性能優化。

    

 

 

 

---

 

 五、小結

 

        總的來講，fiddler是移動互聯網測試的利器，除以上介紹的這些常見的日用場景外，還有不少其它用途，如域名的重定向、API的測試等，這裏就不一一列舉，若有興趣，可抽空一塊兒探討。