【性能測試】性能測試小總結

性能測試核心問題

找到系統瓶頸，然後調優

測試方案

1. 單交易基準測試
   
   • 單獨一個請求的性能測試
   • 初試設置1個線程，即1個併發量，查看TPS
   • 然後，1,5,10,20,30,50…依次併發，去找最大TPS對應的最小併發量
   • jmx文件中添加TPS監控組件（transaction per second）來查檢測TPS
   • 尋找到TPS最優時的最優併發量
   • 然後設計3-4組併發量，執行性能測試，檢測並統計記錄應用及服務器性能數據
2. 混合場景測試
   
   • 假如某個系統包含A、B兩個業務，A、B業務請求量爲2:1，那麼在評估整個系統性能時要考慮業務佔比
   • 在已知業務佔比情況下，可以手動調整併發量，觀察兩個業務的TPS值來尋找合適的併發量作性能測試
   • 也可以在壓測腳本中通過生成隨機數的方法來比較嚴格控制業務的請求量
   • 創建jmx文件時添加兩個線程組，分別設置線程數，根據TPS監控來看多個接口占比（根據業務場景確認比例），查看併發數，併發數之和就是系統最大併發數。
3. 穩定性測試
   
   • 穩定性測試時的併發量，一般取最優TPS時對應的併發值*80%
   • 一般需要至少跑12個小時
   • 測試過程中需要觀測系統的各個性能指標
4. 異常場景測試
   
   • 比如緩存掛掉、數據庫掛掉等場景

測試數據

1. 測試數據庫中添加測試數據，要注意數據的多樣性
2. csv文件中配置多個請求參數

腳本編寫

1. 和開發確認入參取值個數及範圍
2. 和開發確認請求成功、失敗的斷言條件
3. 考慮腳本本身的性能問題，如數據庫創建連接、釋放時是否會有性能問題

其他問題

1. 單交易併發測試需要執行多久？
   
   • 一般5-10min，一般不少於5min最好
2. 性能測試需求調研時預期TPS怎樣確認？
   
   • 根據線上業務量預估
   • 其次，根據業務訴求預估
   • 如果是新項目，可以根據28原則來大概預估
3. 穩定性測試時需要在單臺機器跑還是多臺？
   
   • 這個沒有太大差別
4. 根據檢測系統的一段時間內請求量，和壓測的次數總和來對比，看數據是否對的上，來保證壓測的有效性
5. 壓測的目的是要找出TPS、響應時間最優情況下的用戶數量嗎？
   
   • 因爲壓測時的用戶數量（併發線程） 是沒有實際意義的。系統的性能由TPS決定，跟併發用戶數沒有多大關係。在同樣的TPS下，可以由不同的用戶數去壓（通過加思考時間設置）。拿查詢來說：考慮的是查詢接口支持1秒多少次查詢，而不是支持多少人同時查詢。

性能測試能力定位

1. 初級：會寫腳本+會設計場景+會執行
   
   • 腳本+參數化 來模擬調用接口的真實情況，然後設計場景找最優併發數，統計各場景的資源等能提供的信息
2. 中級：會點瓶頸定位
3. 高級：深入瓶頸定位+調優建議