在做性能測試的時候，在使用LR或者jmeter等一些性能測試工具測試執行結束後，首先要做的是判斷採集到的結果數據是否真實有效。多數的性能測試場景都要迭代的進行測試，因此很多測試結果本身就不能反應問題，深入分析這樣的結果沒啥意義。下面說一下就有效的測試結果數據進行分析做一些思考後的見解。
1、在整個測試場景的執行的時候，你要留意測試的環境是否正常，測試的過程中是否發生異常，如果發生異常，應該立刻終止測試，應爲異常的測試結果是不準確的，沒有意義。
舉個栗子：
你在測試的過程當中，如果你發現測試機的CPU利用率經常達到100%、測試環境的網絡不穩定、系統的配置參數不正確等外部的原因導致系統出現了異常的運行，這樣的測試結果沒有必要進行分析。這是應該先把這些問題搞定了在重新進行測試。
2、測試場景的設置是否正確、合理。當你的測試出現異常的時候，你有分析是不是異常的原因是什麼，是外界原因還是系統本身原因，外界原因有配置、網絡、還有就是你的場景設置本身就有問題，這點往往是你在設計的時候考慮欠缺導致的額。
舉了栗子：
比如你在測試的時候，你以上來就加載全部的虛擬用戶，比如同時加載1000個虛擬用戶，如果客戶端都還沒來得及處理，這時就會出現有很多虛擬用戶因不能初始化而導致失敗，失敗的原因就是還沒有鏈接應用服務器。這是壓力壓根就沒有傳過去。所以正確的做法應該是可以使用逐步加壓的方式儘量的把所有的數據都加載進去。
3、分析試結果直接暴露出系統問題。測試結果中正常的，往往沒有必要進行分析，因爲他是正常的。這時應該進一步進行測試分析，比如加壓等。在加壓測試的時候能反映出的問題有很多：
例如在測試中一些常見的事務響應時間過大，併發用戶過低，服務器資源利用率過高CPU、內存使用過高。對於這些問題，需要深入分析其原因。
性能分析的原則
- 觀察性能表現，系統在高併發下性能表現下降的最直接的表象就是響應時間變長。所以這是需要分析系統的響應時間作爲起點。
- 判斷響應時間是否滿足設計的期望，2S、3S、10S等。如果不滿足，說明系統的性能已經出現問題了。他既然出現問題，那麼問題在哪裏呢？B中解釋。
- 系統中與時間有關的有兩個部分：服務器（應用服務器和數據庫服務器）處理時間、網絡傳輸數據時間。所以能夠影響響應時間的就是這倆傢伙了。所以需要最這倆進行分析。如何分析呢？C中解釋。
- 首先模擬請求的過程，如下圖：
這處理這個過程中，總共有兩個時間段，Tn，這個是網絡的響應時間；Ts，這個是服務器的處理時間，包括應用服務器和數據庫服務器的響應時間。通過將這兩個的時間進行對比，就能分析出性能問題是網絡問題還是服務器問題了。
- 對於虛擬用戶與事務分析的原則：
- 虛擬用戶是否存在失敗、如果有失敗的話，需要定位失敗的原因並寫在報告中。
- 在整個測試中，所有的虛擬用戶是否一直穩定運行併成功執行全部事務：如果只有部分用戶能夠正常運行，那麼說明腳本或者場景設置可能有問題。
- 對於失敗的事務，需要找出失敗的原因，同時需要注意該事務的失敗是否會影響到用戶也失敗。
- 判斷平均事務響應時間以及90%用戶的最大響應時間
- 觀察在整個過程中，事務的平均響應時間是否出現逐步變大，正常的事務響應時間應該是平穩的（與X軸平行）
- 觀察服務器每秒通過的事務總數、事務通過數是否穩定，如果整個測試過程中基本不變，這是就有分析是服務器達到出來上限還是加壓到了極限
場景設計
經過分析，場景設計不必覆蓋所有功能模塊，只需要測試系統中使用比較頻繁的功能即可。
測試場景中設計的內容主要有登錄、查看、添加、刪除、修改等基本操作。
測試場景詳細如下：具體參考Excel表
（1）登錄（如表1-1）
表1-1登錄測試場景
|
功能 |
系統支持多個用戶併發進行登錄 |
|||
|
目的 |
測試多用戶登錄時系統的處理能力 |
|||
|
方法 |
模擬多個用戶在客戶併發進入系統的操作 |
|||
|
執行時間 |
5min/10min/15min/20min/25min/30min |
|||
|
加載方式 |
逐步加載（每秒50個） |
|||
|
併發用戶數與事務執行情況 |
||||
|
併發用戶數 |
平均事務響應時間 |
最大事務響應時間 |
事務成功率 |
平均流量（bit/s） |
|
500 |
|
|
|
|
|
1000 |
|
|
|
|
|
1500 |
|
|
|
|
|
2000 |
|
|
|
|
|
2500 |
|
|
|
|
|
3000 |
|
|
|
|
|
3500 |
|
|
|
|
（2）查詢（如表1-2）
表1-2 查詢測試場景
|
功能 |
系統支持多個用戶併發進行查詢 |
|||
|
目的 |
測試多用戶查詢設備時系統的處理能力 |
|||
|
方法 |
模擬多個用戶在客戶登錄、然後併發查詢設備的操作 |
|||
|
併發用戶數與事務執行情況 |
||||
|
併發用戶數 |
平均事務響應時間 |
最大事務響應時間 |
事務成功率 |
平均流量（bit/s） |
|
500 |
|
|
|
|
|
1000 |
|
|
|
|
|
1500 |
|
|
|
|
|
2000 |
|
|
|
|
|
2500 |
|
|
|
|
|
3000 |
|
|
|
|
|
3500 |
|
|
|
|
（3）查詢-修改設備（混合場景）（如表1-3）
表1-3 查詢-修改設備測試場景
|
功能 |
系統支持多個用戶併發進行查詢、然後修改設備信息 |
|
目的 |
測試多用戶查詢設備時系統的處理能力 |
|
方法 |
模擬多個用戶在客戶登錄、然後併發查詢設備後進行修改設備的操作 |
|
併發用戶數與事務執行情況 |
||||
|
併發用戶數 |
平均事務響應時間 |
最大事務響應時間 |
事務成功率 |
平均流量（bit/s） |
|
500 |
|
|
|
|
|
1000 |
|
|
|
|
|
1500 |
|
|
|
|
|
2000 |
|
|
|
|
|
2500 |
|
|
|
|
|
3000 |
|
|
|
|
|
3500 |
|
|
|
|
測試的實施
|
模擬用戶數 |
測試內容 |
測試結果 |
備註 |
|
500 |
通過jmeter測試系統是否支持500用戶併發訪問系統 模擬用戶的操作有以下： 1、登錄 2、登錄、查詢 3、登錄、查詢、修改 |
通過/不通過 |
按照場景進行測試 |
|
1000 |
|
|
|
|
1500 |
|
|
|
|
2000 |
|
|
|
|
2500 |
|
|
|
|
3000 |
|
|
|
|
3500 |
|
|
|