不管是Loadrunner還是jmeter進行性能測試，測試流程基本上都是一樣的，限制以Jmeter為例分析測試流程：

一、性能測試需求分析
一般而言，被測對象的性能需求，會在用戶需求規格說明說中給出，比如單位時間內的訪問量達到多少、業務響應時間不超過多少、業務成功率不低于多少、硬件資源消耗應該在一個合理的范圍內等，性能指標應以量化數據給出，對于一個規范的產品，產品團隊會給出如下的性能要求：

如果產品團隊并沒有指明性能測試需求，或者只給出表述字面意義上的需求，如：系統的TPS需要到300以上，單筆交易時間不超過3秒，那么測試工程師如何提前量化的指標呢？

需要結合業務需求和系統本身特性進一步分解和提取顯性和隱性的需求，可以從以下兩個用戶方法進行確定：

1、業務用戶

用戶頻繁使用，且存在大量用戶頻繁使用的業務流程
交易占比高，日常占比在80%以上甚至更高的業務流程
特殊交易日或峰值交易占比80%以上甚至更高的業務流程
性能較差且做過調整的業務流程
特殊業務場景
核心業務發送較大流程調整的業務流程
以上為業務用戶層面可能需要的性能需求點，實際項目中可能會向終端用戶進行調研。

2、項目團隊（業務系統）

曾經測試過性能后調整了架構設計的業務
邏輯復雜、關鍵的業務
可能消耗大量資源的業務
與外部系統存在接口調用，且有大量數據交互的業務
調用第三方業務組件，邏輯復雜業務
以上為項目開發角度可能需要的性能需求點，性能測試工程師需要與開發團隊密切配合、深入了解被測對象。

3、案例分析

通過分析，我們以網上商城性能需求指標為例，得到下面數據：
二、測試用例設計及測試數據準備
1、測試用例設計

為了真實地反映被測對象可能存在的性能問題，需要盡可能地模擬被測對象可能發生瓶頸的業務場景，測試需求分析過程中已經確定了業務類型，在此需要設計如下性能測試場景：
2、測試數據準備

以本次測試為例，2小時內5萬用戶登錄，意味著需要有50000個可用賬戶（盡量多準備一些，可以為60000），可以直接在數據庫中添加，但要求對數據庫結構相對熟悉；也可以使用Jmeter錄制注冊腳本，使用3個線程，循環2000次即可。

構造好測試數據后，需要對數據庫進行備份，便于后期進行回歸測試，可以使用NaviCat進行數據備份。
三、性能測試腳本開發
根據登錄業務模型，利用BadBoy錄制用戶登錄過程，生成Jmeter腳本
登錄用戶名進行參數化
設置定時器：參考測試用例輸入信息5s、登錄成功等待返回3s、退出成功等待返回
為登錄成功頁面設置斷言，失敗則提示信息，成功不提示
添加查看結果樹、聚合報告等，實時查看腳本運行情況
四、場景設計及資源監控
1、場景設計

以登錄業務為例子，本次測試的目的在于驗證平臺是否能支持100個用戶的并發登錄，無需考慮持續時間，根據對應的場景測試用例，設置線程組數據，腳本可以通用（如果有必要可以去掉思考時間、添加集合點等）。

相應的線程組可以改名為場景名稱：用戶登錄業務并發負載
2、Jmeter利用自帶插件進行資源監控

解壓JMeterPlugins-Extras-1.4.0.zip及JMeterPlugins-Standard-1.4.0.zip到Jmeter安裝目錄/lib/ext下
重啟Jmeter，添加監聽器：jp@gc - PerfMon Metrics Collector
下載ServerAgent-2.2.3.zip，并通過rz指令上傳到服務器（Linux）指定目錄下，執行unzip -o ServerAgent-2.2.3.zip解壓該文件到當前目錄
關閉服務器防火墻：systemctl stop firewalld.service
給啟動文件設置執行權限：chmod u+x startService.sh
執行sh文件：./startService.sh
Jmeter監聽器jp@gc - PerfMon Metrics Collector下，添加監控的資源，如CPU、內存等
運行場景，即可監控服務器相應的資源
根據場景用例要求，業務量測試需要設置78個線程數，同時需設置執行的時間段（參考業務量指標：2小時完成5萬筆交易或者是TPS），設置如下：
五、場景執行及結果分析
1、場景執行

場景執行前，需要對測試環境進行確認，保證所有環境，系統業務均能正常使用：

數據庫恢復（避免腳本設計過程中對數據庫中數據量的影響），記錄商品、交易等相關數據
隨機購買商品，為避免出現商品庫存為零情況，將庫存統一設置為1000
盡量單獨部署服務器在Linux系統上，避免Jmeter對服務器性能的影響
執行前，啟動相應的監控代理和apache和mysql服務
CMD下非GUI模式執行場景：

Jmeter -n -t 測試腳本Jmx文件 -l 日志文件名 -e -o HTML測試結果文件路徑

2、場景結果分析

結合聚合報告，分析登錄業務的每個請求的平均響應時間為：15s，是小于5s的，故該項指標測試不通過；在最大和最小響應時間差異較大時，我們可以采用90%事務響應時間作為標準。
Apdex（Application Performance Index）指標是一個國際通用的標準。是用戶對應用性能滿意度的量化數值，他提供了一個統一的測量和用戶體驗的方法， 吧最終用戶的體驗和應用性能統一度量，下圖中0表示沒有滿意度，1表示所有用戶均滿意，是開發團隊追求的目標。

六、性能調優及回歸測試
測試結果分析完成以后，即可對進行性能問題的確定及優化，通常情況下性能問題表現如下幾個方面：

1、響應時間問題：

響應時間平穩但較長，測試過程中響應時間就較長，即使減少線程數量（負載），也不會降低
響應時間逐步變長，測試過程中，負載不變，運行時間越長，響應時間越長，直至出現很多錯誤
響應時間隨著負載的變化而變化，響應時間變長；負載減少，響應時間變短，資源利用率也下降
數據積累導致鎖定，起初運行正常，但數據量積累到一定值，立刻出現錯誤，無法消除，只能重啟系統
2、穩定性問題：

特定場景或運行很長時間以后，突然出現問題，系統運行緩慢，主要原因有如下：

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

最后感謝每一個認真閱讀我文章的人，下面這個網盤鏈接也是我費了幾天時間整理的非常全面的，希望也能幫助到有需要的你！!這些資料，對于想轉行做【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術行業，一定要提升技術功底。希望對大家有所幫助……

如果你不想一個人野蠻生長，找不到系統的資料，問題得不到幫助，堅持幾天便放棄的感受的話，可以點擊下方小卡片加入我們群，大家可以一起討論交流，里面會有各種軟件測試資料和技術交流。

敲字不易，如果此文章對你有幫助的話，點個贊收個藏來個關注，給作者一個鼓勵。也方便你下次能夠快速查找。

自學推薦B站視頻：

零基礎轉行軟件測試：自學完軟件測試，拿到了字節的測試崗offer，堪稱B站最好的視頻！

自動化測試進階：已上岸華為，漲薪20K，2022最適合自學的python自動化測試教程，自己花16800買的,無償分享

總結

以上是生活随笔為你收集整理的浅谈Jmeter性能测试流程的全部內容，希望文章能夠幫你解決所遇到的問題。

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