軟件測試：C/S架構(gòu)的性能測試

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

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

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

關(guān)鍵點：IP過濾，端口過濾，報文類型過濾

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

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

關(guān)鍵點：Socket的建立與關(guān)閉，send buf的整理，receive buf的整理

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

3、調(diào)試腳本

關(guān)鍵點：定位錯誤，添加校驗點

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

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

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

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

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

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

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

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