在客戶端的功能測試過程中，常常需要驗證URL請求是否發(fā)送，參數(shù)是否正確。市場上有不少的網(wǎng)絡(luò)數(shù)據(jù)分析工具，smsniffer、wireshark、fiddler......他們可以很好的輔助我們完成驗證的工作。但是，在自動化測試的過程中，無法再依靠肉眼檢查來完成相關(guān)的驗證。通常的做法，可以在本地Mock一個服務(wù)器，再又服務(wù)器將請求的數(shù)據(jù)返回給客戶端來進行驗證，這在接口測試中比較有效。但是在功能測試的過程中，需要額外的編寫一個工具，完成相關(guān)的代理轉(zhuǎn)發(fā)工作，本身是一件略有難度的事。因此，團隊在測試的過程中考慮通過另外的方法去捕獲客戶端程序發(fā)出的請求和響應(yīng)。
設(shè)想的方案的是利用現(xiàn)有的工具，生成網(wǎng)絡(luò)監(jiān)聽數(shù)據(jù)后，再通過 TCP/IP + HTTP 協(xié)議反向解析出請求數(shù)據(jù)和響應(yīng)數(shù)據(jù)。通過調(diào)研選定了Windows平 臺下的網(wǎng)絡(luò)監(jiān)聽工具WinDump（該工具是Window平臺下一款出色的開源的輕量級網(wǎng)絡(luò)監(jiān)聽工具）。通過實驗及對WinDump文檔的研究，確定了抓 包時使用的參數(shù)：WinDump.exe -i N -s 0 -w file_name -a host host_name其中：
-i 表示監(jiān)聽的網(wǎng)絡(luò)端口編號
-s 0 表示捕獲完整的數(shù)據(jù)包
-w file_name 輸出到文件file_name中
-a 使用Ascii編碼輸出數(shù)據(jù)包
host host_name 只捕獲與host_name間的通信數(shù)據(jù)包。
通過這些參數(shù)，WinDump生成的數(shù)據(jù)文件格式是穩(wěn)定的，包含完整的MAC、IP、TCP層的完整數(shù)據(jù)，是可以反向解析的。根據(jù)相關(guān)協(xié)議的文檔和生成 文件的數(shù)據(jù)比對，確定生成的文件格式為：24字節(jié)未知數(shù)據(jù) + 16或者22字節(jié)的未知數(shù)據(jù) + MAC幀 + IP幀 + TCP幀 + 數(shù)據(jù)幀，第2、3、4、5、6部分每個數(shù)據(jù)包都會重復(fù)出現(xiàn)。此外，通過比對，工具會生成完整的三次握手?jǐn)?shù)據(jù)。
在分析完數(shù)據(jù)文件的格式 后，就可以通過編碼去分拆數(shù)據(jù)包了，去除未知數(shù)據(jù)后，把有用的數(shù)據(jù)包提取出來，并解析出其中的數(shù)據(jù)幀。并通過請求發(fā)送的端口和目標(biāo)端口，對并發(fā)數(shù)據(jù)做完整 的對應(yīng)關(guān)系(Request的端口是動態(tài)的，服務(wù)器會根據(jù)請求的端口將相應(yīng)的Response返回給請求端口)。最后提取出關(guān)鍵的請求和響應(yīng)的數(shù)據(jù)幀存儲 起來。這里是一份基于Ruby語言的捕獲http數(shù)據(jù)包和正則驗證數(shù)據(jù)請求存在的輔助類實現(xiàn)代碼。在輔助類中通過正則表達式去拆分Http請求及相應(yīng)中的相關(guān)參數(shù)，并進行存儲。通過對外的接口獲取相關(guān)的請求和相應(yīng)，后面想做什么，就隨心所愿了....
最后有一些需要改進的地方：1、如果能在請求時能過濾一些不Care的數(shù)據(jù)(例如未知數(shù)據(jù)、三次握手的數(shù)據(jù))，這樣最好了。2、需要根據(jù)數(shù)據(jù)分包標(biāo)志完 成數(shù)據(jù)包的拼接(TCP協(xié)議中對數(shù)據(jù)包的大小做了一些限制，因此在數(shù)據(jù)包超過協(xié)議長度時會分為多個數(shù)據(jù)包傳輸，需要通過偏移量完成完整數(shù)據(jù)包的還原工 作)。