軟件測試：C/S架構的性能測試

很多人關心LR在C/S架構上如何實施性能測試，我想根本原因在于兩個方面，一是很多時候腳本無法錄制，即LR無法成功調用被測的應用程序，二是測試腳本即使錄制下來，可讀性不強，往往不能運行通過，調試時無從下手，像音視頻、電子地圖類的測試差不多也是這個問題。

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

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

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

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

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

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

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

3、調試腳本

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

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

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

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

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

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

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

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

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