性能測試基礎知識
目錄
第一章 性能測試類型
1.1 基准測試
1.2 負載測試
1.3 壓力測試
1.3.1 穩定性壓力測試（可靠性測試）
1.3.2 破壞性壓力測試
1.4 Spike測試
1.5 並發測試
1.6 失效恢復測試
第二章 性能指標
2.1 業務指標
2.2 資源指標
2.3 應用指標
2.4 前端指標
第三章 性能測試流程
3.1 需求階段
3.1.1提出需求
3.1.2需求評審
3.1.3需求調研
3.2 准備階段
3.2.1 環境准備
3.2.2 應用部署
3.2.3 數據准備
3.2.4 腳本開發
3.3 實施階段
3.3.1 壓測執行
3.3.2 服務監控
3.3.3 瓶頸定位
3.3.4 優化驗證
3.4 結束階段
3.4.1 測試報告
3.4.2 報告評審
第四章 監控
4.1目的
4.2 參數
第五章 關於我們目前
第一章 性能測試類型
性能測試類型主要分為：基准測試、負載測試、壓力測試、穩定性壓力測試（可靠性測試）、破壞性壓力測試、Spike測試、並發測試、失效恢復測試，每種測試類型針對不同的目的，可以根據生產系統實際情況進行選擇，基准測試和穩定性測試一般情況必須做
1.1 基准測試
1.1.1 概念
1) 每次對外發布產品版本前必須要完成的測試類型
2) 執行固定的性能測試場景得到系統的性能測試報告
3) 與上一版本發布時的基准測試結果進行對比，優化 or 惡化 ?
1.1.2 測試目的
1) 獲取系統性能基准作為參照物
2) 識別系統或環境的配置變更對性能帶來的影響
3) 給系統優化前后的性能提升/下降提供參考標准
4) 觀察系統的整體性能趨勢與性能拐點，識別系統性能風險
1.2 負載測試
1.2.1測試目的
1) 持續穩定地增加系統的負載，測試系統性能的變化
2) 找出指標閾值下的系統瓶頸和性能拐點
3) 測試系統所能承受的最大負載量
4) 找出內存管理錯誤，內存泄漏，緩沖區溢出的問題
5) 找到處理極限，為調優提供數據
6) 找出系統在穩定情況下的最大壓力值
1.2.2測試意義
通過改變負載方式、增加負載，發現系統中所存在的性能問題
1.3 壓力測試
測試目的
1) 測試系統的資源在飽和狀態下的應用的處理會話能力
2) 持續穩定的增加系統壓力，測試系統性能的變化
3) 破壞性測試，確保系統失敗並能正常恢復
4) 發現系統穩定性的隱患和系統在負載峰值的條件下功能隱患
5) 關注大業務下系統的長時間運行狀態（例如反應變慢、內存泄漏、系統崩潰、失效 恢復）
6) 找出系統在可控錯誤率下的最大壓力值
1.3.1 穩定性壓力測試（可靠性測試）
(1)長時間運行（7*24 小時）模擬被測系統的測試負載
(2)觀察系統在長期運行過程中是否有潛在的問題
(3)對系統指標進行監控,發現長期運行時的內存泄漏、資源非法占用等問題
1.3.2 破壞性壓力測試
1)不斷加壓，直至系統崩潰
2)測試系統的最大承受能力
3)通過破壞性加壓的手段，快速造成系統的崩潰或讓問題明顯的暴露出來
1.4 Spike測試
尖峰測試（Spike testing）在性能測試中屬於壓力測試的一個子集。指的是在某一瞬間或者多個頻次下用戶數和壓力陡然增加的場景。為了驗證我們的網站在訪問用戶急劇增加的情況下，或者短時間內反復急劇增加工作負載時能否正常工作；以及程序能否從高負荷中恢復並正常工作時常常用到這種測試手法。Spike 在英文中是釘子的意思，或者我們可以將其稱之為沖擊測試，反復沖擊服務器。
常見場景
12306 開始售票時訪問用戶急劇增加
網站公布高考成績、錄取分數時，訪問用戶急劇增加
網站投放商業促銷廣告和促銷活動，如雙 11 和 618 等活動開始時，訪問用戶急劇增加等等。。。。
1.5 並發測試
在高並發情況下驗證單一業務的功能正確性以及性能問題
使用思考時間為零的虛擬用戶來發起具有“集合點”的測試
用於發現諸如線程死鎖、資源競爭、資源死鎖之類的錯誤
1.6 失效恢復測試
針對有多余備份和負載均衡的系統設計
定義：檢測如果系統局部發生故障，系統能否繼續使用
特點：
1）該方法主要目的是驗證局部故障下系統能否繼續使用
2）該方法需要指出：問題發生時“能支持多少用戶訪問”和“采取何種應急措施”
一般只有對系統持續運行能力有明確指標的系統才需要該類型測試
第二章 性能指標
2.1 業務指標
Error：應用層的指標優先關注”error”，也就是錯誤率。反過來說就是要優先保證“正確率”。但是錯誤率的准入標准可以適當的放寬。但是涉及到金融的項目，錯誤率一定會被嚴格控制，甚至於不會允許有錯誤出現。
RPS： RPS 全稱是 request persecond(每秒請求數)，它描述了施壓引擎向服務器實際發出 的壓力大小。
TPS: TPS 全稱是 transaction persecond(每秒處理完成的請求數), TPS反應的其實是cpu 的處理能力。但是 cpu 的處理能力是有上限的，也就是我們說的性能瓶頸點。因此我們做壓力測試就是通過設計 RPS（壓力值）施壓服務器，來找到 tps 的瓶頸點。
一般參考：中小型企業50-1000筆/秒，銀行1000-50000筆/秒，淘寶30000-300000筆/秒
平均響應時間：系統處理事務的響應時間的平均值；事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間。
並發用戶數：單位時間內與系統發生交互的用戶數。
2.2 資源指標
CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比，長時間情況下，一般可接受上限不超過85%；
內存利用率：內存利用率=（1-空閑內存/總內存大小）*100%，一般至少有10%可用內存，內存使用率可接受上限為85%；
磁盤I/O: 磁盤主要用於存取數據，因此當說到IO操作的時候，就會存在兩種相對應的操作，存數據的時候對應的是寫IO操作，取數據的時候對應的是是讀IO操作，一般使用% Disk Time（磁盤用於讀寫操作所占用的時間百分比）度量磁盤讀寫性能；
網絡帶寬：一般使用計數器Bytes Total/sec來度量，其表示為發送和接收字節的速率，包括幀字符在內；判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較；
2.3 應用指標
空閑線程數、數據庫連接數、函數耗時等
2.4 前端指標
頁面加載時間、網絡時間（連接時間、傳輸時間等）
第三章 性能測試流程
按照業內目前的最佳實踐，精簡后的性能測試流程以及對應階段的崗位職責，如下圖：
3.1 需求階段
3.1.1提出需求
1、有效的性能需求：
1) 明確的數據
2) 有憑有據，合理，有實際意義
3) 相關人員達成一致
2、如何獲取有效的性能需求：
1) 客戶方提出
2) 跟進歷史數據來分析
3) 參考歷史項目的數據
4) 參考其他類似行業應用的數據
5) 參考新聞或其他資料的數據
3、需求內容信息：
項目名稱（立項留檔、提高重視）
測試背景（為什么？充足的理由）
測試目的（容量評估、調優驗證）
測試范圍（什么業務？對應服務）
接口文檔（哪些接口？對應地址）
調用關系（業務/系統/關系拓撲）
關鍵參數（線程池/連接數/JVM）
預期指標（性能指標、資源指標）
數據量級（線上數據、訪問頻次）
4、關於需求搜索的一些資料，僅供參考
業務選取：
系統中有很多業務，每種業務邏輯和業務量是不一樣的，消耗的系統資源也不一樣，因此業務種類、業務占比決定了系統的處理能力。
業務模型中的業務和占比選取不對，跟生產差異非常大，直接導致測試結果沒有任何參考價值，並且容易誤導對系統處理能力的判斷，有些業務的業務量雖然占比很低，但一旦突變，對系統也是致命的。
所以系統中的典型業務選取一般情況下遵循的規則是選取業務量高的、經常使用的、有風險的、未來有增長趨勢的業務作為系統的典型業務，已經上線的系統可以通過高峰時段歷史業務量和生產問題性能來評估，對於即將上線的系統可以通過調研和單交易資源消耗的結果來評估
數據量：
數據量主要包括基礎數據量（或者叫歷史數據量、墊底數據量、數據庫中已有的數據量）和參數化數據量，對於數據庫中只有幾條記錄和有幾億記錄里面查詢，結果肯定相差非常大。
輸入數據量不太同一數量級上，將會導致相關指標不真實，甚至導致測試結果沒參考意義，如果參數化數據量過少，未考慮數據分布的情況的，測試結果會不太真實，沒有參考意義，需要考慮數據准備的完整性，還有清理的邏輯需要完整。
如果測試環境和生產環境在同一數據量級上，那需要考慮未來三年的數據量增長趨勢，如果增長過快需要在測試環境造非常多的數據；參數化數據量盡可能的多，參數化數據分布，如果業務有明顯的地域分布特征，需要考慮數據分布的情況
測試結果中各業務TPS占比需跟生產上業務占比（業務模型）相一致，可以使用PTS特有的RPS模式（Request Per Second，直接測試吞吐能力）來保證一致。 例如：A和B兩筆業務，占比為1：4，響應時間分別為1ms、100ms，那么只需要通過PTS給A和B兩個接口按照1：4比例設置請求數（TPS）施壓即可。如果使用傳統的並發模式，A和B的並發需要經過換算確保比例是1：400，使得最終與生產上保持一致的業務模型
3.1.2需求評審
需要多方相關人員參與評審，從各自的角度給出意見，溝通達成一致，決定后續的要不要做？怎么做？以及誰來做什么事情！
3.1.3需求調研
需求調研階段主要是對后續性能測試實施的一些必要信息進行更細致的溝通和確認，以及在職責、工時、排期、交付時間這幾點上尋求平衡的可接受的點，並在各項信息確定后輸入測試計划文檔。
3.2 准備階段
3.2.1 環境准備
壓測環境需要盡量和生產環境配置一致，且盡量有一套獨立的壓測環境。當測試環境與實際生產環境差異較大時，性能測試結果往往不被接受，如果在性能測試實施過程中，無法搭建相對真實的測試環境，即可認為被測對象不具備性能的可測性。
測試環境搭建：
1) 測試環境與線上環境架構要相同
2) 機型盡量相同，雲化的資源確保是同規格ECS或者容器
3) 軟件版本相同：操作系統、中間件相關、數據庫、應用等
4) 參數配置相同：操作系統參數、中間件參數、數據庫參數、應用參數
5) 數據量需要在同一數量級上
6) 測試環境機器台數需要同比例縮小，而不能只減少某一層的機器台數
7) 測試環境等比配置是生產環境的1/2 、1/4
測試環境調研：
1) 系統架構：系統如何組成的，每一層功能是做什么的，與生產環境有多大差異，主 要為后面進行瓶頸分析服務和生產環境性能評估，這個很重要
2) 操作系統平台：操作系統是哪種平台，進行工具監控
3) 中間件：哪種中間件，進行工具監控和瓶頸定位
4) 數據庫：哪種數據庫，進行工具監控和瓶頸定位
5) 應用：啟動多少個實例，啟動參數是多少，進行問題查找和瓶頸定位
6) 可以配合APM工具進行中間件、數據庫、應用層面的問題定位
3.2.2 應用部署
性能測試的被測應用必須是穩定的，需要是沒有P2及以上缺陷或通過回歸測試的版本包
3.2.3 數據准備
性能測試對數據的要求是很高的，無論是數據量級、精准度抑或是數據的多樣性。一般分為如下幾種數據類型：
鋪底數據：最常見的准備方式為從生產拖庫最新的最完整的基礎數據來作為性能測試所用；
測試數據：比如性能測試場景需要讀寫大量的數據，而為了保證測試結果的准確性，一般通過從生產拉取同等量級或者至少未來一年的增長量級的脫敏數據；
參數化數據：不同類型的數據處理邏輯有差異時，需要通過測試數據的多樣化來提高性能測試代碼的覆蓋率，而參數化是最常見的方式；
3.2.4 腳本開發
性能測試腳本需要針對業務模型轉化后的測試模型以及采用的測試策略進行針對性的開發調試試運行。
3.3 實施階段
3.3.1 壓測執行
性能測試執行階段，是需要執行很多輪次，且測試腳本也需要不斷地調整修改，根據測試結果不斷改進的，這樣才能得到更為准確的測試結果。
3.3.2 服務監控
這個階段稱之為APM（Application Performance Management：對應用程序性能和可用性的監控管理）更合適。
狹義上的APM單指應用程序的監控，如應用的各接口性能和錯誤監控，分布式調用鏈路跟蹤，以及其他各類用於診斷(內存，線程等)的監控信息等。
廣義上的APM, 除了應用層的監控意外，還包括App端監控、頁面端監控、容器、服務器監控，以及其他平台組件如中間件容器、數據庫等層面的監控。
3.3.3 瓶頸定位
進行性能測試的目的，就是為了探測系統是否存在影響提供正常服務的性能瓶頸以及為上線提供容量評估。
如果系統性能表現未到達預期指標，則需要對日志、監控數據進行分析，定位其性能瓶頸並針對性的進行優化才可以。
3.3.4 優化驗證
發現性能瓶頸並修改優化后，需要再次執行壓測，以驗證問題是否得到解決以及性能的提升能力，衡量的標准是需求評審和調研階段確定的業務性能指標。
3.4 結束階段
性能測試結束的標志，一般包括如下幾點：涉及的測試場景均已測試完畢、測試過程中發現的問題已全部修復驗證、測試結果達到了預期的性能指標、滿足上線要求。
3.4.1 測試報告
在滿足上面4個條件后，測試人員出具一份簡潔但是明確的測試報告，說明本次性能測試的目的、范圍、環境信息、測試結果、問題，並給出測試結論。
3.4.2 報告評審
參與本次性能測試各環節工作的各個角色都參與進行評審，大家對結果無異議，即可視為本次性能測試結束。
第四章 監控
4.1目的
監控的目的主要是為進行性能測試分析服務，完善會系統進行監控，針對瓶頸定位起到事半功倍的效果，一般需要針對操作系統、中間件、數據庫、應用等進行監控，每種類型的監控盡量指標全面。
4.2 參數
操作系統：CPU（user、sys、wait、idle）利用率、內存利用率（包括SWAP）、磁盤I/O、網絡I/O、內核參數等
中間件：線程池、JDBC連接池、JVM（GC/FULLGC/堆大小）
數據庫：效率低下的SQL、鎖、緩存、會話、進程數等
應用：方法耗時、同步與異步、緩沖、緩存
第五章 關於我們目前
1、測試性能的電腦，配置不能太低，可以分布式壓測
2、我們目前測試環境，一台服務器上部署多個項目，做性能測試項目會有影響，壓測的意義不大
3、我們目前最大的壓力應該在MQTT上，主要是設備訪問，是否可控制每秒的設備接入量，如，這一秒接入100請求，下一秒在接入100，就不用同秒去處理1000或更多，產生壓力
查的資料：MQTT通訊使用TLS證書：性能上TCP 1G內存可維持5W的連接數，使用TLS 1G內存大約維持1.5W左右的連接數，
查詢的他人結果：12W連接8G內存消耗
15W連接CPU維持利用率在100%--150%
25W連接12G內存消耗
每秒連接速度3000/S 4核剩余20%空閑