性能測試流程
平常我們做黑盒測試，都會有一套功能測試流程，做性能測試也不例外，性能也會有規范的流程。如下圖所示就是我們常規的性能測試流程圖。

.1.業務學習：通過查看文檔，手工操作系統來了解系統功能。
.2.需求分析：分析系統非功能需求，圈定性能測試范圍，了解系統性能指標。
3.工作評估：工作量分解，評估工作量，計劃資源投入（即需要多少人力，多少工作日來完成性能測試工作）
.4.設計模型：圈定性能測試范圍后，把業務模型映射成測試模型。
.什么是測試模型呢？比如我們測試工作中，需要調用一些第三方的服務，如最常見的支付功能，如我們需要實現一個支付訂單的功能，但是此時支付那邊暫時不能夠支持提供服務，那我們為了確保整個性能測試能夠正常開展，需要開發一個程序去替代這個支付功能，即Mock程序，這個過程就是設計模型。
在比如我們測試用戶加入購物車下單購買商品功能，需要操作用戶登錄，點擊瀏覽商品，加入購物車，下單等一系列流程，這些流程需要綁定在一起進行測試，這就是測試模型，通俗點講，性能測試用例設計 + 性能測試實現方案，用例只關注業務，模型還需要關注實現，是否具有可操作性、可驗證性等問題，我們需要根據不提供的測試目的組合不同的測試場景。
.5.計劃編寫計劃測試工作，在文檔中明確列出測試范圍、人力投入、持續時間、工作內容、風險預估、風險應對策略等。
.6.腳本開發：錄制或者編寫性能測試腳本
.7.測試環境準備：性能測試環境準備包括服務器與負載機兩部分，服務器是被測系統運行平臺（包括硬件與軟件，比如應用服務器需要8Core，32G內存，中間件是JBoss7等），負載機是我們用來產生負載的機器，用來安裝負載的工具，運行測試腳本。
.8.測試數據準備：根據數據模型來模擬被測系統的主數據與業務數據（主數據指的是保證業務能夠正常運行暢通的基礎，比如菜單、用戶等數據；業務數據是運行業務產生的數據，比如訂單；訂單出庫需要庫存數據，庫存數據也是業務數據。我們知道數據量變會引起性能的變化，在測試的時候，往往要準備一些存量/歷史業務數據，這些數據需要考慮數量與分布）
.9.測試執行：測試執行是性能測試的成敗與關鍵，同樣的腳本不同的人執行得出的結果可能差異較大。這樣差異主要源于提現在場景設計與測試執行上。
.10.缺陷管理：對性能測試中發現的缺陷進行管理。
.11.性能分析：對性能測試過程中暴露的問題進行分析，找出原因。
.12.性能調優：性能測試工程師與開發人員一起來解決性能問題。
.13.測試報告：測試工作的重要交付件，對測試結果進行報告，主要包括常見的性能指標說明（TPS、RT、CPU Using…)
性能測試主要交付件：
1）測試計劃；
2）測試腳本；
3）測試程序；
4）測試報告或者階段性測試報告；
如果性能測試執行過程較長，換句話說性能測試過程中性能問題較多，經過了多輪的性能調優，需要執行多次回歸測試，那么在這個過程中需要提交階段性測試報告。
.14.評審對性能報告中的內容進行評審，確認問題，評估上線風險。有些系統雖然測試結果不理想，但是基于成本及時間的考慮也會在評審會議中通過從而上線。

性能測試常見的指標
B/S架構-常見性能指標：對于B/S架構的軟件，一般會關注如下Web服務器性能指標

C/S架構-常見性能指：對于C/S架構的程序，由于軟件后臺通常為數據庫，所以我們更注重數據庫的測試指標除了表格里面的概念，還有部分指標：CPU占用率、內存占用率、數據庫連接池等。

性能測試結果分析
1–如何分析性能測試結果
分析在整個性能測試執行期間，測試環境是否穩定正常。
例如，測試期間運行Jmeter的及其CPU占用率經常達到100%（或內存占用很高）、測試網絡出現擁塞導致響應延遲、待測系統參數配置錯誤（JDBC連接池等）…
2-- 檢查jmeter測試腳本參數設置是否合理、檢查jmeter運行模式是否合理。例如，線程組的參數Ramp-Up Period(in seconds)設置為0或1，jmeter就會瞬間啟動該線程組下的所有虛擬用戶，會為待測服務器造成巨大的壓力，輕則導致服務器響應時長超長，重則導致部分虛擬用戶等待響應超時而報錯。
3.–檢查測試結果是否暴露出了系統瓶頸。性能測試分析的原則：由表及里、由內而外、抽絲剝繭
借助監聽器發現性能缺陷
圖形結果(Graph Results)

指標概念解釋如下：

總結

以上是生活随笔為你收集整理的JMeter性能测试流程及性能指标关注点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。