fiddler的四大功能
本篇對Fiddler抓包工具的原理、安裝、介面不做介紹，此篇講解Fiddler工具高階使用，適用於有經驗的測試員。
Fiddler高階使用
過濾
Fiddler抓包可以完成我們移動開發者的除錯測試需求。但是多餘的網頁請求和手機的其他連結影響我們手機開發的需求。所以我們需要排除其他無用的包，只關注我們指定的域名的請求包。
開啟fiddler，找到Filters選項並點選開啟。如圖所示
預設情況下，這個頁面是灰色的，代表預設不過濾任何請求。現在我們勾選Use Filters。
一般常用的有三種過濾條件：
- 域名過濾，只顯示特定域名的記錄：
*.baidu.com表示所有的百度二級域名會話；*baidu.com表示一級域名 二級域名的會話。設定好了後一定要點選Actions生效；
- 型別過濾，一般對各種圖片、CSS、JS這類的靜態素材也不需要看的情況下，直接全部過濾
.*/.(bmp|css|js|gif|ico|jp?g|png|swf|woff)
需要過濾多少自己直接加入就好了
- 3.根據返回狀態碼，比如只想顯示200的狀態，其他的不顯示
3.2斷點請求/響應
如圖，箭頭所指的位置時可以點選的。共三種狀態：
空白：不設定斷點。
箭頭向上：表示斷點請求。此時客戶端的請求是無法直接到達目標伺服器的，需要手動控制。
箭頭向下：表示斷點響應。此時目標伺服器的響應是無法直接到達客戶端的，需要手動控制。
還有一種打斷點的方式
在命令列中輸入以下命令:
bpu www.baidu.com （斷點請求）
bpuafter www.baidu.com（斷點響應）
這種方法只會中斷www.baidu.com
斷點請求並修改
如圖，操作步驟:
- 設定斷點請求，訪問網頁
- 點選對應的會話
- 檢視請求報文資訊
- 修改請求內容
- 完成斷點，放行，把該請求傳送給目標伺服器。
圖中Break On Response表示把請求發給伺服器，但是伺服器的響應被fiddler攔截，此時可以修改響應內容（和斷點響應類似）。
斷點響應並修改
和斷點請求操作類似，只是在響應區域修改報文資訊即可。
在斷點響應時，請注意超時時間。
3.3模擬網路
在解決日常的支援需求中，經常會遇到一些使用者反饋一些無法簡單復現的bug，有很大一部分的bug是由於使用者自身的網路環境波動，或者是本身網路環境就較為惡劣，而服務在面對這種惡劣的網路環境的健壯性不夠，導致會出現一些意想不到的bug。而在正常的開發自測過程中很難去營造出這種惡劣的網路環境，使得這些bug較難被提前發現和修復。另外一些服務在惡劣網路環境下雖然不會出現不可用的情況，但是使用者體驗很差，為了優化這個情況下的使用者體驗，也需要去在本地模擬這種環境來進行調優。所以要去復現這些bug，甚至是去提前發現這些bug，就需要能夠在開發環境中模擬出惡劣的網路環境，從而看到在這種惡劣的網路環境下的服務的表現等。當前模擬惡劣網路環境主要可以通過以下這些手段實現：
- 通過應用層或者傳輸層的代理伺服器，通過在代理伺服器上設定一些模擬惡劣網路環境的引數，使得通過這些代理伺服器的流量都被轉化為惡劣網路環境下的流量。如利用Fiddler，Charles等具有代理伺服器功能的網路流量分析軟體來實現。
- 通過利用一些更底層的驅動層面的服務，通過控制網絡卡的收包發包的行為，來模擬惡劣的網路環境。如dummynet的ipfw驅動等。
- 通過建立一個可控的閘道器，在閘道器上部署模擬惡劣環境的相關程式，所有需要藉助該閘道器進行轉發的流量都會被模擬為惡劣網路條件。Linux下的netem就提供了這類支援。
這裡主要先講的是第一種手段，即利用Fiddler來模擬惡劣的網路環境，對服務進行測試，這個手段實現簡單，較為直觀，但是缺點是隻能支援那些利用HTTP進行通訊和互動的服務。
方式1：
Fiddler本身已經預置提供了模擬Modem速度的選項，其位置位於：
Rules – Performances – Simulate Modem Speeds
勾選該選項後，所有通過Fiddler代理的流量都會變得和多年前的56k小貓時上網一般的慢。
方式2：
直接模擬Modem速度實在是慢爆了，事實上就算是在很差訊號的情況下，手機行動網路的速度都已經超過了當年的56k Modem速度了，所以採用預設的配置模擬出來的環境過於惡劣，並不一定符合需求，此時就需要對限速的引數進行調整。
Fiddler本身就提供了一個配置檔案供調整這些引數，點選：Rules – Customize Rules…
就會用文字編輯器開啟CustomRules.js檔案，其預設位於使用者目錄的文件目錄下的/Fiddler2/Scripts 位置，字尾名是js，其內容實質是JScript.NET——微軟對ECMAScript規範的實現，與日常使用的javascript是屬於同一個規範下的，但是在擴充套件的細節實現存在一定的不同。
開啟該檔案後，可以找到一個m_SimulateModem標誌位：
該標誌位控制著oSession的兩個引數值的設定，當勾選了Simulate Modem Speeds時，request-trickle-delay與response-trickle-delay就會被設定，其中request-trickle-delay中的值代表每KB的資料被上傳時會被延時多少毫秒，response-trickle-delay則對應下載時每KB的資料會被延時多少毫秒，
如果本身網速已經相當快的話，這裡設定的值就可以近似地推算出開啟模擬後的上傳和下載頻寬了，比如預設設定下下載延時為150ms，上傳延時為300ms，對應可以推算出大致的模擬頻寬為：
上傳頻寬=(1*8/1000)/0.300≈0.053Mbps
下載頻寬=(1*8/1000)/0.150≈0.027Mbps
然而實際情況下卻得到了兩倍於這個值的頻寬，推測可能是Fiddler的內部實現上有一些和描述上的不同，為何為造成這個現象現在還不是很清楚，所以上述公式最後還需要修正一個2.0的係數，即：
上傳頻寬=((1*8/1000)/0.300)*2.0≈0.106Mbps
下載頻寬=((1*8/1000)/0.150)*2.0≈0.053Mbps
假設我們將兩個引數都設定為50，則會得到上下載頻寬均為0.32Mbps
方式3：
查詢到if (m_SimulateModem)語句，修改程式碼。模擬網路頻寬不是恆定的一個低速的值，而是一定範圍內隨機抖動，下面的指令碼實現了一個隨機延時量設定，使得網路頻寬不是恆定為一個低速的值。
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(100,200); // Delay receives by 150ms per KB downloaded. oSession["response-trickle-delay"] = "" randInt(1,50); }
在程式碼裡找到onBeforeRequest，這裡定義了在傳送請求前做什麼。加入如下程式碼可以實現延遲：
oSession["request-trickle-delay"]="3000"; //請求階段延遲3秒 oSession["response-trickle-delay"]="3000"; //響應階段延遲3秒
備註：每次編輯並儲存配置檔案後，Simulate Modem Speeds選項會被取消，需要重新勾選。