Jmeter性能測試的標准流程

說說軟件測試那些事兒

1、性能測試必要性評估

常見關鍵評估項

監管單位要求性能報告

涉及財產、生命安全的系統

首次投產的大型系統

核心數據庫、軟硬件升級

用戶量、業務量增長30%以上

單版本單業務評估權重

是否平台核心位置

是否存在部署方式調整或優化

是否增加了性能風險較高的調整

是否存在客戶要求必須測試的業務流程

是否涉及多個功能缺陷的修複且流程發生較大變化

2. 性能測試需求分析

業務層面

用戶大量使用的功能

日常占比80%以上的業務

特殊交易日或峰值80%的業務

核心業務發生流程重大調整的業務

項目層面

曾經測試過性能調整了架構的業務

邏輯複雜、關鍵的業務

可能消耗大量資源的業務

與外部系統存在接口調用、大量交互的業務

調用第三方業務組件且邏輯複雜的業務

性能測試需求評審

可測性

可搭建相對真實的環境

一致性

用戶需求、生產需求（真實性）、運營需求（規劃未來發展要求）

正確性

3.性能測試用例設計

測試模型建模

舉例：登陸業務操作流程（思維導圖）

打開首頁

輸入用戶名、密碼登陸

退出系統

場景用例設計

分類

單業務基准測試：是否滿足系統設計和用戶期望的性能指標

單業務壓力測試：最大負載下，持續服務的時長

單業務負載測試：系統能夠承受的最大負載

綜合業務壓力測試

綜合業務負載測試

綜合業務穩定性：核心業務基准負載下長時間運行系統穩定服務的能力

線程數計算

場景用例

腳本用例設計

4.測試數據構造

腳本開發創建用戶注冊腳本

錄制腳本導出為jmx

Jmeter迭代生成賬號

${username}變量要導入CSV

5. 測試腳本開發

腳本開發錄制登陸與購買腳本

Jmeter配置

添加->定時器->固定定時器：設置間隔時間

添加->斷言->響應斷言：檢查登陸成功

添加->監聽器->查看結果樹/聚合報告

Fiddler的使用

若腳本開發未錄制到商品添加到購物的請求，需要用Fiddler抓包手動添加

添加->Sample->HTTP請求

6.場景設計與實現

並發線程數與調度器配置

如果是腳本開發錄制的腳本，循環設置在Step1設置 永遠

監聽結果

資源監聽器gc-perfMon Metrice Collector

下載：

地址https://jmeter-plugins.org/downloads/all/，下載plugins-manager.jar

把給文件放到apache-jmeter/lib/ext目錄下

增加插件：

選擇，重啟

添加監聽器：

重啟後可以 添加-監聽器-@gc-perfMon Metrice Collector

增加CPU、內存等指標後保存

7. 用例執行

環境

注意客戶端性能

注意服務器最好能夠獨占測試

注意時間的選擇，測試環境/生產環境最好是少人使用的時候

記錄服務器配置

測試服務端配置：

應用服務器-機型-台數-CPU-內存-IP

數據庫服務器-機型-台數-CPU-內存-IP

測試客戶端配置：

客戶端-機型-台數-CPU-內存-IP

運行任務

8.結果分析

響應時間

Apdex

業務成功率（看斷言）

測試腳本中設置了斷言，判斷用戶登錄後是否出現“登錄成功”字樣，並設定“斷言結果”查看器，通過查看斷言結果，全部通過表示業務成功率100%

並發數

CPU與內存

數據庫

結果統計

9.性能調優

性能問題表現特征

響應時間平穩但較長

響應時間逐步變長

響應時間隨著負載變化而變化

數據積累導致鎖定

穩定性差

響應時間長，系統越來越慢，出現業務錯誤，通常原因

物理內存資源不足；內存泄露；資源爭用；外部系統交互；業務失敗頻繁重啟，無終止狀態；中間件配置不合理，數據庫連接設置不合理；進程/線程設計錯誤