性能測試-2.Fiddler抓包工具的使用
Fiddler基礎知識
- Fiddler是強大的抓包工具，它的原理是以web代理服務器的形式進行工作的，使用的代理地址是：127.0.0.1，端口默認為8888，我們也可以通過設置進行修改。
- 代理就是在客戶端和服務器之間設置一道關卡，客戶端先將請求數據發送出去後，代理服務器會將數據包進行攔截，代理服務器再冒充客戶端發送數據到服務器；同理，服務器將響應數據返回，代理服務器也會將數據攔截，再返回給客戶端。
- Fiddler可以抓取支持http代理的任意程序的數據包，如果要抓取https會話，要先安裝證書。
HTTP協議
- 要分析Fiddler抓取的數據包，我們首先要熟悉HTTP協議。HTTP即超文本傳輸協議，是一個基於請求與響應模式的、無狀態的、應用層的協議，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。
- HTTP的工作過程：當我們請求一個超鏈接時，HTTP就開始工作了，客戶端先發 送一個請求到服務器，請求內容包括：協議版本號、請求地址、請求方式、請求頭和請求參數；服務器收到請求後做相應的處理，並將響應數據返回到客戶端，響應 內容包括：協議版本號、狀態碼和響應數據。前端根據響應數據做相應的處理，就是最終我們看到的內容。這些過程是HTTP自動完成的，我們只是輸入或點擊請 求地址，然後查看前端給我們展示的內容。更多關於HTTP協議的介紹請參考：http://www.cnblogs.com/li0803 /archive/2008/11/03/1324746.html
- 請求方式常用的有：GET、PUT、POST、DELETE。
- HTTP狀態碼主要分為5類：以1開頭的代表請求已被接受，需要繼續處理；以2開 頭的代表請求已成功被服務器接收、理解、並接受；以3開頭的代表需要客戶端采取進一步的操作才能完成請求；以4開頭的代表了客戶端看起來可能發生了錯誤， 妨礙了服務器的處理；以5開頭的代表了服務器在處理請求的過程中有錯誤或者異常狀態發生，也有可能是服務器意識到以當前的軟硬件資源無法完成對請求的處 理。
- 常見的主要有：200：服務器成功處理了請求；404：未找到資源；500：內部服務器錯誤；503：服務器目前無法為請求提供服務；302：請求的URL已臨時轉移；304：客戶端的緩存資源是最新的，要客戶端使用緩存。
- 每個狀態碼的詳細介紹請參考：https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin
Fiddler的使用
- Fiddler是一個很好用的抓包工具，可以將網絡傳輸發送與接收的數據包進行截獲、重發、編輯等操作。也可以用來檢測流量。
- Fiddler安裝後，設置的端口默認為8888，當Fiddler啟動後，默認將IE的代理設為了127.0.0.1:8888，而其他如火狐瀏覽器需要手動設置代理後才可以抓包。設置內容如圖：
1）要使用Fiddler進行抓包，首先需要確保Capture Traffic是開啟的（安裝後是默認開啟的），勾選File->Capture Traffic，也可以直接點擊Fiddler界面左下角的圖標開啟和關閉抓包。
2）所以基本上不需要做什麽配置，安裝後就可以進行抓包了。那麽我們怎麽分析抓到的這些數據包呢？如圖所示的區域為數據包列表，要分析這些數據包，首先要了解各字段的含義。
#：順序號，按照抓包的順序從1遞增
Result：HTTP狀態碼
Protocol：請求使用的協議，如HTTP/HTTPS/FTP等
HOST：請求地址的主機名或域名
URL：請求資源的位置
Body：請求大小
Caching：請求的緩存過期時間或者緩存控制值
Content-Type：請求響應的類型
Process：發送此請求的進程ID
Comments：備註
Custom：自定義值
3）每個Fiddler抓取到的數據包都會在該列表中展示，點擊具體的一條數據包可以在右側菜單點擊Insepector查看詳細內容。主要分為請求（即客戶端發出的數據）和響應（服務器返回的數據）兩部分。
4）HTTP Request Header：以百度為例，查看請求百度主頁這條數據包的請求數據，從上面的Headers中可以看到如下內容：
請求方式：GET
協議： HTTP/1.1
Client 頭域：
Accept: text/html, application/xhtml+xml, image/jxr, */* ---------瀏覽器端可以接受的媒體類型
Accept-Encoding: gzip, deflate ---------壓縮方法
Accept-Language: zh-CN ---------語言類型
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393 ---------客戶端使用的操作系統和瀏覽器的名稱和版本
COOKIE頭域：將cookie值發送給服務器
Transport 頭域：
Connection：當網 頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接是否關閉。keep-alive表示不會關閉，客戶端再次訪問這個服務器上的網頁，會 繼續使用這一條已經建立的連接；close表示關閉，客戶端再次訪問這個服務器上的網頁，需要重新建立連接。
HOST：主機名或域名，若沒有指定端口，表示使用默認端口80.
5）HTTP Response Header：繼續以百度為例，如圖所示：
協議：HTTP/1.1
狀態碼：200
Cache頭域：
Cache-Control: private ---------此響應消息不能被共享緩存處理，對於其他用戶的請求無效
Date: Sat, 05 Aug 2017 04:37:43 GMT ---------生成消息的具體時間和日期
Expires: Sat, 05 Aug 2017 04:37:42 GMT ---------瀏覽器會在指定過期時間內使用本地緩存
Cookie/Login 頭域：
Set-Cookie: BDSVRTM=264; path=/ ---------把cookie發送到客戶端
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=1425_21097_22157; path=/; domain=.baidu.com
Entity頭域
Content-Length: 202740 ---------正文長度
Content-Type: text/html;charset=utf-8 ---------告知客戶端服務器本身響應的對象的類型和字符集
Miscellaneous 頭域：
Bdpagetype: 2
Bdqid: 0x99791efd00036253
Bduserid: 2577220064
Server: BWS/1.1 ---------指明HTTP服務器的軟件信息
X-Ua-Compatible: IE=Edge,chrome=1
Security頭域：
Strict-Transport-Security: max-age=172800 ---------基於安全考慮而需要發送的參數，關於這個參數的解釋，請參考：http://www.freebuf.com/articles/web/66827.html
Transport頭域：
Connection: Keep-Alive
6）TextView：顯示請求或響應的數據。
7）WebForms：請求部分以表單形式顯示所有的請求參數和參數值；響應部分與TextView內容是一樣的。
8）Auth：顯示認證信息，如Authorization
9）Cookies：顯示所有cookies
10）Raw：顯示Headers和Body數據
11）JSON：若請求或響應數據是json格式，以json形式顯示請求或響應內容
12）XML：若請求或響應數據是xml格式，以xml形式顯示請求或響應內容
13）上面是以百度主頁為例，百度主頁采用的是GET請求，在TextView中沒有請求body，我們再以無憂行網站登錄接口為例，它是一個POST請求，除了請求頭外，在TextView中多了請求數據。這也是GET請求和POST請求的一個區別。GET請求是將請求參數放在url中，而POST請求一般是將請求參數放在請求body中。
總結：通過Fiddler可 以抓取請求和響應參數，通過對參數進行分析，可以定位是前端還是後臺問題。例如我們在測試登錄接口時，輸入了正確的手機號和密碼，但前端提示“請輸入正確 的用戶名和密碼”；僅僅通過界面提示我們只能描述bug表象，但不能分析出問題原因。假設通過抓包我們發現是由於前端參數名錯誤或參數值為空，從而導致後 臺報錯。這個時候我們將bug指向前端開發人員，並將參數數據和接口文檔中對應的報文數據作為附件上傳，是不是可以提高bug的解決效率 呢？Fiddler在實際的功能測試中有很大的作用，一方面幫助我們更好的了解某個業務中客戶端和服務器端是通過哪些接口進行請求的，從而更好的了解代碼 邏輯；另一方面，我們還可以通過響應數據判斷哪裏出現了問題，例如可能服務器程序掛了，導致前端報“服務器故障”，這時我們通過抓包發現響應數據返回 502，這時我們可以手動去重啟服務或是聯系運維重啟服務，從而提高問題的解決效率。
此文原文地址
性能測試-2.Fiddler抓包工具的使用