Jmeter 核心原理
基於協議，模擬真實使用者場景，並通過多執行緒模擬使用者發起請求。
- 基於協議：效能測試的物件是網路分散式架構的軟體，而網路分散式架構的核心是網路協議
- 多執行緒：人的大腦是單執行緒的，電腦的 cpu 是多執行緒的。效能測試就是利用多 執行緒的技術模擬多使用者去負載
- 模擬真實場景。使用者的訪問時間，訪問頻率都不是固定的
效能測試理論
效能測試的
- 基本目標：測試系統效能是否達標；通過一定的技術手段，模擬使用者的併發請求，去測試系統最大處理能力與穩定執行的能力，找到效能瓶頸，提升系統整體處理能力
- 基本方法：基準、負載、壓力……
核心原理
基於協議，通過多執行緒的方式模擬使用者併發，在不同場景下施壓伺服器
- 基於協議：包括http，https，tcp，udp，socket，websocket，基於協議發起請求
- 多執行緒：通過多執行緒的方式，模擬併發使用者，施壓伺服器
- 涉及場景：jmeter 方法，元件；設計使用者使用系統的關聯，思考時間，集合點，對結果進行斷言
應用領域
能力驗證：系統能否在固定條件下具有所宣告的能力
乙方向甲方提供的專案中，宣告瞭系統可以支援5000使用者同時登入，且響應時間不超過3s;乙方需要通過效能測試得到測試結果，給予甲方驗收報告
瓶頸發現：發現瓶頸與缺陷，無可參照的效能指標與目標
通過一系列的效能測試手段，發現效能瓶頸與缺陷
效能調優：對系統效能的調優
針對發現的效能瓶頸做調優
- TPS 瓶頸
- 服務資源瓶頸
- 響應時間瓶頸
- SQL 瓶頸
- 容量規劃：系統能否支援未來一段時間內的使用者增長
當前使用者可能只支援5000使用者併發;
預計未來使用者併發量能達到 50000 or 500000;
針對未來可能存在的業務量爆發，以預計的使用者併發量為基數，做對應的效能測試，提前調整硬體設施
測試思路
- 要測什麼？
前端：web、APP；從使用者角度考慮，更多關注頁面載入時間，與響應時間
服務端：
- 工具層面：關注錯誤率與吞吐量
- 伺服器層面：CPU，記憶體，IO，JVM
資料庫：包括慢SQL，死鎖……
- 怎麼測？
需求--計劃--方案--測試環境搭建--設計用例--資料準備--設計場景--指令碼開發--資料監控--結果分析--效能調優--提交報告
- 測試結果通過的標準：
按照需求：測試結果符合預期
無標準需求的：例如測試一個頁面的最大併發
效能指標
- 前端效能指標
響應時間：使用者視角最優先關注的指標
258原則：
- 2s以內，很滿意
- 5s，一般
- 8s，無法接受
前端相應時間：
- 前端資源載入渲染的時間
- 前後端互動的時間
- 前端將後端查詢的資料，在頁面呈現出來
網路連線時間：
- connect time-連線時間：請求發出到服務端接收到，中間的網路時間
- latency-延遲：網路連線時間+服務處理返回的時間
- 服務段處理時間=latency - connect time
錯誤率
點選率（HPS）：使用者點選按鈕，觸發請求
TPS：
- 單介面業務：單位時間完成的請求數
- 多介面業務：單位時間完成的事務數
RPS：直接從服務端角度衡量壓力值
- 單位時間發起的請求數
TPS 衡量了服務端/系統的效能；RPS 衡量了壓力
- 服務端效能指標
CPU
記憶體
磁碟IO
JVM
中介軟體：Tomcat、redis、Nginx
測試視角
使用者視角
- 響應時間
- 系統穩定
運維視角
- 硬體設施是否需要更換
資源利用率是否達標
- 利用率超標
- 利用率過低
- 系統容量
開發視角
- 程式碼是否需要優化
- SQL 優化
- 系統架構優化
效能測試工程師的視角
測試型別
基準測試：每一次版本迭代都需要做基準測試，目的是對比上一次的測試結果，給出調優的依據
負載測試：持續不斷地增加壓力；需要保證壓力的持續性；找到系統的瓶頸點
- 併發使用者模型：持續不斷地增加併發使用者
- RPS模型：持續不斷地增加請求數
壓力測試：當資源處於一個飽和狀態，持續執行服務，考察系統的穩定性；或者負載處於一個高峰
- 穩定性測試：最大壓力的80%，持續執行一段時間
- 破壞性測試：在最大壓力的基礎上，依然不斷增加壓力，目的是讓系統崩潰報錯
失效恢復測試：系統異常之後，能否及時地恢復
容量測試：考察系統在未來時間段內，能支撐的使用者數；測試大容量下，系統需要的硬體設施