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

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

根據(jù)我以往的項(xiàng)目經(jīng)驗(yàn)，LR是可以做到的，因?yàn)樗峁┝薟indows Sockets協(xié)議，解決方案實(shí)施起來簡單但需要足夠的細(xì)心以及一定的判斷力、想象力，可參考如下步驟進(jìn)行：

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

關(guān)鍵點(diǎn)：IP過濾，端口過濾，報(bào)文類型過濾

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

2、將過濾后的報(bào)文整理成測試腳本。

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

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

3、調(diào)試腳本

關(guān)鍵點(diǎn)：定位錯(cuò)誤，添加校驗(yàn)點(diǎn)

目的：使腳本真正可以拿來進(jìn)行壓力測試

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

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

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

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

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

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

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