魯德——C/S架構的性能測試

很多人關心LR在C/S架構上如何實施性能測試，我想根本原因在於兩個方面：

一是很多時候腳本無法錄製，即LR無法成功調用被測的應用程序

二是測試腳本即使錄製下來，可讀性不強，往往不能運行通過，調試時無從下手，像音視頻、電子地圖類的測試差不多也是這個問題。

根據我以往的項目經驗，LR是可以做到的，因為它提供了Windows Sockets協議，解決方案實施起來簡單但需要足夠的細心以及一定的判斷力、想像力，可參考 如下步驟進行：

1、通過抓包工具捕捉客戶端與伺服器之間的所有通訊

關鍵點：IP過濾，埠過濾，報文類型過濾

目的：弄清楚業務操作過程中，客戶端向伺服器提交的請求原型，以及伺服器對我們請求所做的正確響應

2、將過濾後的報文整理成測試腳本。

關鍵點：Socket的建立與關閉，send buf的整理，receive buf的整理

目的：將抓包獲得的報文轉成LR測試腳本（提示：選取合適的抓包工具，使得報文能被保存成文檔格式；開發小工具，通過報文中的各個關鍵字抽取報文中 Data Area中的部分作為buf 區的內容，根據IP欄位，埠號等特徵完成lrs_send,lrs_receive語句的填寫。這部分看上去挺難，但只要對報文做好分析，把握規律，編程的事隨便拉個開發都可以輕鬆搞定）

3、調試腳本

關鍵點：定位錯誤，添加校驗點

目的：使腳本真正可以拿來進行壓力測試

這是最難的一個環節，耐心、細心、判斷力都體現在此處。每個人處理問題的方式的不同，我只能提供自己的一點經驗。

將腳本RUN-TIME SETTINGS中的擴展日誌全部打上鉤，並且將腳本拿到controller中單用戶執行，注意設置好日誌路徑。

腳本出錯後，用EDIT PLUS或其他的文本工具打開log,找到出錯行，然後向上逐一對比伺服器返回的數據與錄製過程中抓包獲得的報文。

在這裡，我用了一個小技巧，生成buf內容時，使buf的編號與該buf在抓包獲得的報文中編號保持一致，比較起來很方便。

如果伺服器返回的buf與抓包時的原始數據一致，自然表示該步驟回放成功，如果不一樣，則需要具體情況具體對待。就我的經驗來說，往往是因為數據唯一性問題或者是關聯的問題造成某一步驟返回的BUF為0或-1，從而導致最終腳本失敗。

找到第一個出錯的地方後，參數化，關聯等手段都可以用上了，這裡可能需要重複兩次抓包過程，先行比較自己發送的報文是否有區別。

總體思路便是如此，寫了一堆，也不知道對大家是否有幫助，對於此類問題，網路上的協助很難派上用場，事情還是要在現場才有可能得到解決啊。本來有意將這東西工具化，甚至產品化，但幾個項目實施下來發現變數較多，特別是最後一個環節，完全依賴於測試工程師的自身能力，只好就此作罷。