六、性能測試流程（如何做性能測試？)
根據學習全棧測試博主的課程做的筆記
1、前期準備–
項目初期就開始，業務需求評審時盡量參與,對業務更深刻的認識（確定哪些是核心業務、哪些可能存在并發請求、確定什么地方會出現瓶頸,方便后續性能需求評審時給出建設性建議）
2、性能需求分析、評審（確定性能測試的范圍、性能測試的目標是多少）
2.1、確定范圍：哪些業務接口
使用多的、核心業務功能
2.2、目標：tps、rt、成功率、資源利用率等
2.3、補充
2.3.1關于需求來源（項目組一起定性能目標）
2.3.1.1迭代項目
1）范圍
新增、修改、受影響的功能也是需要放在壓測范圍內
2）目標
不能低于之前版本的性能
還需要進行容量評估，根據歷史數據的請求數據進行統計月增長率是多少
比如現在要做一個容量預估：可以根據增長率（業務、用戶增長的情況）預估tps達到多少未來才能滿足業務需求，就可以做容量預估
3）業務比例：類似ELK的日志平臺來統計
從生產上統計接口的業務比例(其實就是單接口的比例）
這只是統計出接口的比例，但是需要轉換成業務比例，評審時就需要將業務比例獲取到，最后在jmeter設計場景時要用到。
2.3.2新項目
1）范圍：核心業務功能
2）目標值：參考競品、經驗值（產品經理）
若是迭代項目可以和之前的版本性能做對比，也可以通過生產環境的統計日志獲得容量tps，新項目就是參考競品和產品經理的經驗。
3）補充：①業務比例（項目組談論、項目運行后統計）②要測出最大容量Tps，為上線后限流提供參考
迭代項目的業務比例是可以通過類似ELK日志平臺拉取數據，看一下壓測時間范圍內各個接口請求的壓測業務比例歷史數據統計，新項目沒有歷史數據，怎么解決？
這種新項目的業務比例只能是項目組進行討論（不好定的情況，最簡單的就是1：1或者就是項目試運行后數據統計比例,少量用戶和大量用戶使用的tps有差異，業務比例的1偏差不是太大。
對于新項目，一定需要測出最大容量tps，為上線后限流進行提供參考。
3、制定性能測試方案（為后續工作進行指導）
方案很重要(設計相關的、數據的設計、場景的設計、監控的設計等）
3.1、項目背景
描述項目做什么、核心業務什么、出現什么問題，系統架構（用到什么技術棧）
1）背景描述
2）系統架構
了解系統架構、用到什么技術棧、接口的的數據流向、經過了哪些技術棧，才能為后續設計監控提供參考（才知道去監控哪些服務）
3）壓測目的
解決當前什么性能問題、還需要測試出系統的最大容量tps(為上線后續的保證服務不掛、限流等）
3.2、術語說明（主要為了避免理解偏差）
1）tps
2）rt
3）并發
4）業務比例
5）單場景
6）容量場景（混合場景）
7）穩定性場景
3.3、測試范圍、目標
1）要壓測的接口清單以及業務比例
2）各個場景的目標：tps、rt、成功率等
3.4、測試資源
1）人力資源（組織架構）
項目經理(協調壓測需要的資源）
性能測試工程師（編寫性能測試方案、性能測試腳本、設計壓測場景、執行壓測、收集監控數據、編寫測試報告等)
開發工程師（開發需要配合性能測試進行打對應的壓測分支、做性能分析、做性能優化）
運維工程師（配合性能測試部署壓測測試環境、協助性能部署測試監控）
2）壓測工具（主要是壓力端的工具）
jmeter還是loadrunner
壓力機（window、linux）
如果對性能要求不高，用window壓力機即可，一般用的是linux
3）壓測環境：
硬件、軟件、部署描述清楚
3.5、壓測設計（最重要）
1）數據設計
①參數化數據—數據量–根據業務來
唯一性：tps500，壓測時間600s，至少需要30000數據量乘以20%，
非唯一性：tps500，也是時間600s，至少覆蓋線上時間被使用到的
如：注冊要用不同的用戶名，系統要求用戶名是唯一，就需要準備不同用戶名。
模擬不同的真實用戶，發送請求。
參數化數據設計多少？得根據業務來，對數據有唯一性。
若要求tps=500，壓測時間10分鐘，600s,至少需要30000數據量，但是壓力端在發送請求時，不是輪流發請求，假設起了200個線程，jmeter線程關系之間也是有競爭關系，也是要去爭奪cpu的執行權限。如果獲得cpu的執行權限，就將請求發送出去，可能有的線程獲得cpu執行權限多一點，發的請求數也會多，jmeter數據量把,一部分數據分成線程1，線程2，線程3，獲得cpu的執行權限不一樣，為了避免發的請求更多數據量不夠，再算出的數據量再乘以20%或者更多
對數據若沒有唯一性。如查詢商品，a\bc都可以查詢到電腦，商品表有10萬個商品，數據量應該設置多少？假設tps=500，壓測時間10分鐘，600s，至少需要30000數據量，商品表里有10萬數據，可以直接用，也可以直接統計線上某一段時間內哪些商品被搜索，再進行參數化，需要與線上覆蓋到（實際被使用到的數據）
參數化唯一性數據需要自己造
非唯一性數據在庫里存在，若想所有數據都需要參數化數據導出，若想拿某一些熱點數據進行參數化，就需要統計線上日志。
②數據庫存量
數據庫里各個表都存有數據，測時的數據庫量級與生產一致，方便復現線上回歸壓測復現問題，變量太多，盡量保持與生產一致（數據量級、環境差異、軟硬配置）
數據庫的表和生產量的數據庫表的盡量保持一致
2）場景設計（單場景、容量場景、穩定性場景等）
①單場景
單個業務接口進行壓測
生產環境有很多的業務功能,一般說系統的tps都是混合容量的tps，為什么還需要對單場景進行壓測?單個接口，鏈路簡單，可以發現明顯的性能Bug，可以為后續混合場景tps參考（代碼邏輯性能Bug、軟件配置bug如數據庫連接配置，應用代碼線程池里的配置）
②容量場景（混合場景）
容量場景一定需要集合業務比例模擬線上真實業務場景，在性能需求評審時不僅要給到目標tps，還需要給到業務比例，因為線上環境，每個接口調用次數不一樣。
涉及到有用戶登錄、查詢商品、添加購物差、創建訂單接口：若對這些業務做單場景測試，這四個接口就屬于壓測范圍。
單場景就是針對每一個業務(單獨的接口）去進行單獨指定目標、設計到加壓方式、表的數據量，腳本涉及到關鍵點，以及重點關注相關指標
根據圖中的單場景的目標tps是300、500、500、200，一般性能測試中給出的tps都是混合容量的tps。
混合容量tps=800，接口業務占比，可以根據業務比例算出在混合容量場景各個接口的tps。創建訂單 業務比例10%，總的tps是800，則創建訂單接口的tps為800*10%=80
其他接口也是同樣算法：根據混合容量總的tps算出各接口在混合容量場景下的tps
單場景若沒有指定目標tps，接口的目標tps至少是需要比混合容量場景中各接口的tps高（有的項目組會告訴單場景的tps，有的項目組則不會告訴單場景的tps，不指定的話根據總混合容量場景tps和業務比例是可以進行算出每個單接口的tps需要達到多少）
圖中的業務比例是日志平臺統計業務峰值容量tps，分解出來各個接口的比例，在jmeter中設置的時候還需要進行轉換(吞吐量控制器）
業務占比用戶登錄15%，查詢商品40%，添加購物車35%，創建訂單10%，根據日志平臺線上系統進行統計（有并發請求的業務的一個量，后面再根據jmeter的吞吐量控制器進行業務比例轉換）
③穩定性場景（防止系統在高峰值時掛）
壓測時需要設置一個持續時間,jmter中，循環次數勾選永遠，會設置一個持續時間
穩定性壓測時間設置多少合理？jmeter中，tps=總請求數/并發時間
并發時間=總請求數/tps
5000萬/800=62500s–建議,時間乘以120%
50000萬/1000=50000s,建議：時間乘以120%（防止跑到后面后，性能下降后，沒有達到5000萬的業務量）
穩定性場景的tps用的是混合容量場景測試出來的最大tps1000，用更大的tps跑出更少的時間。
④加壓方式
秒殺、搶購----瞬間產生壓力
非秒殺、搶購-----逐步階梯加壓
3）監控設計
根據壓測接口的鏈路涉及的技術棧、選擇合適的監控工具
比如：鏈路監控工具是微服務的標配（服務很多，排查問題難）
java項目:通過鏈路監控工具，進行時間拆分，發現是應用耗時多（對應用接口的調用的方法，通過arthas之類工具看哪個是方法耗時多或者可能是jg在耗時，通過jdk自帶的相關命令進行查看，jstack）
系統架構、數據流向、技術棧需要清楚
3.6、測試計劃
流程的一個里程碑計劃、產出物什么、時間節點、負責人是誰？
3.7、風險評估
根據當前情況羅列出可能的風險（如涉及到外圍系統，外圍系統也屬于外圍風險、人力資源缺少、環境差異）
3.8、參考資料
4 、性能測試方案評審
寫好后項目組進行評審、性能測試計劃、性能測試場景怎么設計的.
根據評審會議的建議進行修改
評審會議通過后需要發送給各項目組的成員
5、申請性能測試環境
簡單架構（nginx+2 tomcat +mysql），nginx做反向代理，tomcat容器有兩個+mysql，看哪一個服務是影響大的，資源不足的話，對對應的服務等比例縮放進行兩次壓測，看損耗率。
初步判斷，瓶頸在應用層，第一次是一個tomcat，tps是100，兩個tomcat的tps是180，此處有20的tps的損耗。換算成損耗率，生產是3個tomcat，預估可以達到多少tps，現在簡單架構較少，一般都是復雜架構，復雜架構鏈路長，涉及的服務多，每一個服務的影響因子性能大小不一樣，很難換算。建議項目組進行評估，做好線上的保護，如限流。
大公司一般壓測環境不足，一般是直接線上全鏈路，充分利用線上的資源。
補充：新項目可以直接在線上環境壓測
6、性能測試用例編寫及評審
性能測試用例設計：一般是對性能測試場景進行設計
對單場景、混合容量場景、長時間穩定性的設計，重點就是各場景里的數值
單場景(目標tps、加壓方式、數據量、腳本設計等）混合容量場景（業務比例、目標tps等）
長時間穩定性（總的壓測時間、總的目標業務量等）
7、搭建測試環境
參考測試資源壓測環境的部署
除了部署應用，還需要部署監控
8 、準備測試腳本、測試數據
8.1、腳本
推薦：開發提供壓測環境調通的postman或者jmeter腳本
或者根據接口文檔寫（swagger）
8.2、場景設計
8.3、準備數據
1）參數化數據
方式，代碼生成，從數據庫導出
2）數據庫存量數據
方式：
復雜表，jmeter跑業務接口
單表：代碼，存儲過程
9、環境確認測試
9.1、靜態測試
確認環境配置（軟件、硬件），盡量和生產保持一致
軟件（jdbc的配置、線程池的配置等是否和生產保持一致）
9.2、非靜態測試
確認環境是否可用（壓測的接口是否通、發送請求是否有響應響應結果是否正確等）
10、執行壓測并監控
先單場景測試發現明顯的性能bug,為容量場景做準備
混合容量場景：模擬真實線上的真實場景
再執行穩定性場景
執行壓測監控時，不要一次性打開所有監控，監控也是需要耗費監控資源。先通過jmeter非gui模式下持續階梯加壓跑一下，看一下結果，如不達標后，若是微服務（用skywalking）是哪一個節點耗時多，就著重監控不達標的節點（如果是mysql服務，則將mysql的服務打開），通過mysql監控看是什么問題，若有慢sql，后續就需要出現問題的接口執行的sql，拿出來用explain單獨分析sql執行情況
每一步需要哪個監控就開哪個監控
11、分析定位
11.1方法
1）簡單架構
查看資源消耗,通過監控發現應用服務器的CPU高，java項目可以進行打棧，看一下線程在做什么，下一步就是代碼邏輯。
2）復雜架構
通過分解時間方式（微服務skywalking）
舉例：
場景比對：加節點懷疑是服務資源不足，可以進行加節點，
性能提升后就是服務資源不足導致的，服務為什么消耗資源，代碼邏輯是否合理。
隔離:這個功能會調另一個功能，先將一個功能去掉后再進行壓測。
線程)
