性能測試流程

注意點：

性能測試用例設計，特別關注數據容量的問題

性能測試環境搭建，與被測試環境區分開

執行：跑腳本、記錄數據

數據記錄：cpu ? io ? 內存 ? 網絡

調優：一般由開發人員進行

調優有成本，適當即可

寫好報告，才能讓老板看到勞動成果，怎么寫好看，寫清晰

LR在性能測試流程中的位置

LR在性能測試過程中能幫我們完成的東西如上圖所示，只是性能測試的一個“前端”工具

腳本開發很重要，決定性能測試結果的正確與否

LR能幫我們做什么

1、 讓我們開發腳本簡單化

我們可以不用管系統真正在傳輸的東西是什么，不需要理解系統的實現機制是什么，只需要簡單了解相關的協議，就能開發腳本了

性能測試是基于協議的。只需要知道使用的協議，使用協議相關的函數，就可以開發腳本了

2、 讓我們更好的模擬用戶行為

不管是腳本開發中的參數化、自定義邏輯，還是場景中的用戶行為控制，利用好這些東西，我們就能夠輕松的模擬用戶行為，最大程度上讓系統的壓力符合現實運行情況

可以模擬多個用戶（參數化），模擬用戶并發（集合點）

3、 能夠方便的采集事務響應時間

LR的分析結果中，最有用的監控數據就是事務的響應時間，在合理設置事務的前提下，我們能夠很方便的知道每個事務花費的時間，為我們的調優提供了大的方向

可以自己定義事務 通過start-end采集時間

4、其他一些常用的指標

如虛擬用戶運行情況，TPS大小、波動情況，錯誤分布等

LR不能幫我們做什么

1、 監控

雖然lr的場景中自帶了很多的計數器，linux的，數據庫的，中間件的。對性能測試工程師來說，選擇什么計數器，都是很為難的事情。因為不知道這些計數器是什么意思。所以大部分情況下，我們看到一些人的推薦就是選擇默認的那些（help里有一些說明），如果我們遇到的問題正好在我們選擇的那幾個計數器里有體現，還真是太幸運了。而且作為壓力機而言，模擬用戶行為時，就會產生大量的負載，這時候再去處理服務器傳回來的監控數據，會對測試結果造成一定的影響。

lr能監控到的，是程序呈現給用戶的，已經處理過的錯誤信息，與實際程序中報出來錯誤不一定好對應。而且計數器需要提前設定好，也許不一定能采集到分析過程中，真正需要的數據

建議：采用第三方工具來處理。現在很多的第三方監控工具都做得小而精，對服務器產生的壓力可以忽略不計。如nmon，spotlight系列，jprofiler、jconsole、AWR報告等。

2、 分析

通常情況下，lr中能夠體現出來的問題，已經是經過了系統中一系列的處理之后拋到lr上的，所以我們再討論lr的某個錯誤代號和打印出來的一串串紅色字符串已經沒有實質的意義了，還需要進一步去分析應用的整個通信過程，才能找到最終問題本質。

我們可以發現某個事務慢了，但是你無法定位出來是為什么慢，在哪一層慢了，是中間件的問題，系統的問題，還是數據庫處理的時間長了？

對于web界面而言，我們能從lr上知道哪個頁面響應慢了，在哪個環節響應慢了，但是我們也無法得知它為什么慢了

系統組成：前段--中間件--系統--數據庫

建議：在性能測試執行過程中，我們需要有意識的利用第三方工具去監控一些數據，如線程數的運行情況，服務器資源的消耗情況，jvm內存的使用情況等，以便于我們后期的分析

3、 調優

這塊內容不是任何工具可以幫到我們的，都是具體情況具體分析。同一個現象，可能會有N多種不同的情況引起，需要我們日積月累的經驗以及對系統的敏感程度來解決。很多時候這塊并不是測試能參與的

建議：對于目前來說，調優還是塊很難啃的內容，它需要很廣的知識面以及一定的經驗。我們所需要做的，是幫助有能力的人去盡可能正確的定位問題。如果不能做到定位到某個代碼片段，至少要告訴人家是哪個層面的問題