大多數測試人員在談到性能測試時，往往會倍感壓力。對於我來說更是如此，想做好性能測試需要龐大的知識體系，不斷實踐所總結的經驗教訓更是彌足珍貴。而且每個人對性能測試的理解都有獨到的地方，此次逐步揭開性能測試得神秘面紗，結合課堂學習及自身消化理解后的，歸納了一些性能測試的基礎知識，希望對大家理解性能測試有所幫助。
性能測試的基礎
就是在確保功能實現正確的前提下，通過合適的性能測試加壓方式和策略，並收集考察服務端應用程序的各項性能指標，以及服務器硬件資源的使用情況，來評估是否存在性能問題隱患。
性能指標分類
從性能測試分析度量的度角來看，可以從如下幾個維度來收集考察各項性能指標：
- 系統性能指標
- 資源性能指標
- 中間件指標
- 數據庫指標
- 穩定性指標
- 可擴展性指標
- 可靠性指標
下面將從如上這幾個維度，分別從各自維度常見指標，以及指標含義、指標行業參考標准等方面進行介紹。
系統性能指標
系統性能指標，常見的可從如下幾類進行參考：
- 響應時間
- 系統處理能力
- 吞吐量
- 並發用戶數
- 錯誤率
響應時間
定義和解釋： 響應時間，簡稱RT。是指系統對請求作出響應的時間，可以理解為是指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間。直觀上看，這個指標與人對軟件性能的主觀感受是非常一致的，因為它完整地記錄了整個計算機系統處理請求的時間。
在性能檢測中一般以壓力發起端至被壓測服務器返回處理結果的時間為計量，單位一般為秒或毫秒，由於一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入數據的情況下響應時間也不相同。所以，在討論一個系統的響應時間時，通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。
行業參考標准： 不同行業不同業務可接受的響應時間是不同的，一般情況，對於在線實時交易：
- 互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右。
- 金融企業：1秒以下為佳，部分復雜業務3秒以下。
- 保險企業：3秒以下為佳。
- 制造業：5秒以下為佳。
- 時間窗口：不同數據量結果是不一樣的，大數據量的情況下，2小時內完成。
- 互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右。
- 金融企業：1秒以下為佳，部分復雜業務3秒以下。
- 保險企業：3秒以下為佳。
- 制造業：5秒以下為佳。
- 時間窗口：不同數據量結果是不一樣的，大數據量的情況下，2小時內完成。
需要指出的是，響應時間的絕對值並不能直接反映軟件的性能的高低，軟件性能的高低實際上取決於用戶對該響應時間的接受程度。
系統處理能力
定義和解釋： 系統處理能力是指系統在利用系統硬件平台和軟件平台進行信息處理的能力。系統處理能力通過系統每秒鍾能夠處理的交易數量來評價，交易有兩種理解：一是業務人員角度的一筆業務過程；二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程，后者稱為事務。兩種交易指標都可以評價應用系統的處理能力。
一般情況下，系統處理能力又用以下幾個指標來度量：
- HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
- TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒。
- QPS（Query per Second）：系統每秒處理查詢次數，單位是次/秒。
行業參考標准：對於互聯網業務中，如果某些業務有且僅有一個請求連接，那么TPS=QPS=HPS，一般情況下用TPS來衡量整個業務流程，用QPS來衡量接口查詢次數，用HPS來表示對服務器點擊請求。
- 金融行業：1000TPS~50000TPS，不包括互聯網化的活動
- 保險行業：100TPS~100000TPS，不包括互聯網化的活動
- 制造行業：10TPS~5000TPS
- 互聯網電子商務：10000TPS~1000000TPS
- 互聯網中型網站：1000TPS~50000TPS
- 互聯網小型網站: 500TPS~10000TPS
吞吐量
定義和解釋： 吞吐量是指系統在單位時間內處理請求的數量。對於單用戶的系統，響應時間可以很好地度量系統的性能，但對於並發系統，通常需要用吞吐量作為性能指標。
而對於一個多用戶的系統，如果只有一個用戶使用時系統的平均響應時間是t，當有你n個用戶使用時，每個用戶看到的響應時間通常並不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數和用戶使用模式的系統，如果其最大吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致。
並發用戶數
定義和解釋： 並發用戶數指在同一時刻內，登錄系統並進行業務操作的用戶數量。
並發用戶數對於長連接系統來說最大並發用戶數即是系統的並發接入能力。對於短連接系統而言最大並發用戶數並不等於系統的並發接入能力，而是與系統架構、系統處理能力等各種情況相關。
與吞吐量相比，並發用戶數是一個更直觀但也更籠統的性能指標。實際上，並發用戶數是一個非常不准確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發出不同數量的請求。
錯誤率
定義和解釋： 錯誤率簡稱FR，指系統在負載情況下，失敗交易的概率。錯誤率＝(失敗交易數/交易總數)*100%。
行業參考標准：
不同系統對錯誤率的要求不同，但一般不超出千分之六，即成功率不低於99.4%
資源性能指標
資源性能指標，常見的可從如下幾類進行參考：
- CPU
- 內存
- 磁盤吐吞量
- 網絡吐吞量
CPU
定義和解釋： CPU又稱為中央處理器，是一塊超大規模的集成電路，是一台計算機的運算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟件中的數據。
行業參考標准：
CPU指標主要指的CPU利用率，包括用戶態(user)、系統態(sys)、等待態(wait)、空閑態(idle)。
- CPU 利用率要低於業界警戒值范圍之內，即小於或者等於75%;
- CPU sys%小於或者等於30%;
- CPU wait%小於或者等於5%；
內存
定義和解釋： 內存是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存中進行的，因此內存的性能對計算機的影響非常大。
行業參考標准：
現在的操作系統為了最大利用內存，在內存中存放了緩存，因此內存利用率100%並不代表內存有瓶頸，衡量系統內存是否有瓶頸主要靠SWAP（與虛擬內存交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低於70%,太多的交換將會引起系統性能低下。
磁盤吐吞量
定義和解釋： 磁盤吞吐量簡稱為Disk Throughput，是指在無磁盤故障的情況下單位時間內通過磁盤的數據量。
行業參考標准：
磁盤指標主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的的重要依據，一般情況下，磁盤繁忙率要低於70%。
網絡吐吞量
定義和解釋： 網絡吞吐量簡稱為Network Throughput，是指在無網絡故障的情況下單位時間內通過的網絡的數據數量。單位為Byte/s。網絡吞吐量指標用於衡量系統對於網絡設備或鏈路傳輸能力的需求。當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時，則需要考慮升級網絡設備。
行業參考標准： 網絡吞吐量指標主要有每秒有多少兆流量進出，一般情況下不能超過設備或鏈路最大傳輸能力的70%。
中間件指標
常用的中間件例如Tomcat、Weblogic等指標主要包括JVM, ThreadPool, JDBC,具體如下：
| 一級指標 | 二級指標 | 單位 | 解釋 |
|---|---|---|---|
| GC | GC頻率 | 每秒多少次 | java虛擬機垃圾部分回收頻率 |
| GC | Full GC頻率 | 每小時多少次 | java虛擬機垃圾完全回收頻率 |
| GC | Full GC平均時長 | 秒 | 用於垃圾完全回收的平均時長 |
| GC | Full GC最大時長 | 秒 | 用於垃圾完全回收的最大時長 |
| GC | 堆使用率 | 百分比 | 堆使用率 |
| ThreadPool | Active Thread Count | 個 | 活動的線程數 |
| ThreadPool | Pending User Request | 個 | 處於排隊的用戶請求個數 |
| JDBC | JDBC Active Connection | 個 | JDBC活動連接數 |
行業參考標准：
- 當前正在運行的線程數不能超過設定的最大值。一般情況下系統性能較好的情況下，線程數最小值設置50和最大值設置200比較合適。
- 當前運行的JDBC連接數不能超過設定的最大值。一般情況下系統性能較好的情況下，JDBC最小值設置50和最大值設置200比較合適。
- ＧＣ頻率不能頻繁，特別是FULL GC更不能頻繁，一般情況下系統性能較好的情況下，JVM最小堆大小和最大堆大小分別設置1024M比較合適。
數據庫指標
常用的數據庫例如ＭySQL指標主要包括SQL、吞吐量、緩存命中率、連接數等，具體如下：
| 一級指標 | 二級指標 | 單位 | 解釋 |
|---|---|---|---|
| SQL | 耗時 | 微秒 | 執行SQL耗時 |
| 吞吐量 | QPS | 個 | 每秒查詢次數 |
| 吞吐量 | TPS | 個 | 每秒事務次數 |
| 命中率 | Key Buffer命中率 | 百分之 | 索引緩沖區命中率 |
| 命中率 | InnoDB Buffer命中率 | 百分比 | InnoDB緩沖區命中率 |
| 命中率 | Query Cache命中率 | 百分比 | 查詢緩存命中率 |
| 命中率 | Table Cache命中率 | 百分比 | 表緩存命中率數 |
| 命中率 | Thread Cache命中率 | 百分比 | 線程緩存命中率 |
| 鎖 | 等待次數 | 次 | 鎖等待次數 |
| 鎖 | 等待時間 | 微秒 | 鎖等待時間 |
行業參考標准：
- SQL耗時越小越好，一般情況下微秒級別。
- 命中率越高越好，一般情況下不能低於95%。
- 鎖等待次數越低越好，等待時間越短越好。
穩定性指標
最短穩定時間：系統按照最大容量的80%或標准壓力（系統的預期日常壓力）情況下運行，能夠穩定運行的最短時間。
一般來說，對於正常工作日（8小時）運行的系統，至少應該能保證系統穩定運行８小時以上。
對於7*24運行的系統，至少應該能夠保證系統穩定運行24小時以上。如果系統不能穩定的運行，上線后，隨着業務量的增長和長時間運行，將會出現性能下降甚至崩潰的風險。
參考標准：
- TPS曲線穩定，沒有大幅度的波動。
- 各項資源指標沒有泄露或異常情況。
可擴展性指標
定義和解釋：是指應用軟件或操作系統以群集方式部署，增加的硬件資源與增加的處理能力之間的關系。
計算公式 為：（增加性能/原始性能）/（增加資源/原始資源）*100%。
擴展能力應通過多輪測試獲得擴展指標的變化趨勢。一般擴展能力非常好的應用系統，擴展指標應是線性或接近線性的，現在很多大規模的分布式系統的擴展能力非常好。
參考標准：
理想的擴展能力是資源增加幾倍，性能就提升幾倍。擴展能力至少在70%以上。
可靠性指標
對於服務端性能測試，從系統可靠性指標度量分析時，常見從三類來入手：
- 雙機熱備
- 集群
- 備份和恢復
雙機熱備
對於將雙機熱備作為可靠性保障手段的系統，可衡量的指標如下：
- 節點切換是否成功及其消耗時間。
- 雙機切換是否有業務中斷。
- 節點回切是否成功及其耗時。
- 雙機回切是否有業務中斷。
- 節點回切過程中的數據丟失量在進行雙機切換的同時，使用壓力發生工具模擬實際業務發生情況，對應用保持一定的性能壓力，保證測試結果符合生產實際情況。
集群
對於使用集群方式的系統，主要通過以下方式考量其集群可靠性：
- 集群中某個節點出現故障時，系統是否有業務中斷情況出現
- 在集群中新增一個節點時，是否需要重啟系統
- 當故障節點恢復后，加入集群，是否需要重啟系統
- 當故障節點恢復后，加入集群，系統是否有業務中斷情況出現
- 節點切換需要多長時間在驗證集群可靠性的同時，需根據具體情況使用壓力工具模擬實際業務發生相關情況，對應用保持一定的性能壓力，確保測試結果符合生產實際情況。
備份和恢復
本指標為了驗證系統的備份/恢復機制是否有效可靠，包括系統的備份和恢復、數據庫的備份和恢復、應用的備份和恢復，包括以下測試內容：
- 備份是否成功及其消耗時間。
- 備份是否使用腳本自動化完成。
- 恢復是否成功及其消耗時間。
- 恢復是否使用腳本自動化完成指標體系的運用原則。
- 指標項的采用和考察取決於對相應系統的測試目的和測試需求。被測系統不一樣，測試目的不一樣，測試需求也不一樣，考察的指標項也有很大差別。
- 部分系統涉及額外的前端用戶接入能力的，需要考察用戶接入並發能力指標。
- 對於批量處理過程的性能驗證，主要考慮批量處理效率並估算批量處理時間窗口。
- 如測試目標涉及到系統性能容量，測試需求中應根據相關指標項的定義，明確描述性能指標需求。
- 測試指標獲取后，需說明相關的前提條件（如在多少的業務量、系統資源情況等）。
性能測試場景設計
場景分類
- 手工場景
手工場景可以為同一個組中的不同用戶分配不同的腳本，負載生成器。
- 目標場景
面向目標場景，即首先的定義需要測試達到的目標，然后loadrunner會自動根據這一目標創建場景。
場景設計策略
- 快增長
使用場合：比如說秒殺功能。
問題： loadrunner場景中的加載方式：simultaneously，即同時加載。和Initialize中的
一次性初始化所有的vuser用戶的選項，兩者有什么區別嗎？
- 慢增長
使用場合：單個場景，比如打開某個頁面，接口，登錄等操作。
- 用戶數執行完場景停止場景
用戶停止場景即用戶執行完場景完后，退出當前的場景的操作。
問題： 一般情況來說，用戶停止場景的方式，是與用戶加載的方式一樣適合還是一次性全部退出場景適合呢？
問題： 用戶場景的執行時間：可以不可以這樣理解，用戶場景的整體執行時間等於：
用戶加載時間+用戶執行時間+用戶退出場景的時間？
場景適用場合
- 單場景
例如：打開某個頁面操作，用戶登錄等。
- 混合場景
混合場景，即多個業務組成的場景。比如BBS論壇發帖，有用戶登錄，發帖，回帖的業務，這些業務可以組成一個混合的場景，在運行場景時，可以指定多少vuser去執行某一個單個業務的操作。
問題： 在混合場景中，針對了某個單業務進行了檢查點的設置，例如BBS論壇的發帖檢查點，當虛擬用戶數變多時，其整個發帖的事物響應時間明顯變慢，是不是增加了檢查點后，在多虛擬用戶執行場景時，會影響到其事務的響應時間呢？或者說檢查點不適合在混合場景中多次添加？
壓力機
- 壓力機定義
壓力機顧名思義就是增加壓力的機器，即負載機，在性能測試過程中，可以指定多個加壓機對其進行加壓。
- 添加負載機步驟
1、保證聯合的機器上裝了LRagent，並啟用了。（狀態欄會有一個小衛星）
2、本地系統的服務RPC服務開啟，改為自動。
3、請從你的Controller的機子上登錄要聯合的機子。
4、關閉防火牆+殺毒+360等。擁有權限，必須保證負載機器在同一個網段內，保持網絡可以相互通信。
參考資料
性能測試的內容到這里啦！如有需要了解軟件測試相關的其他內容，可到「 [主頁]」進行查看學習~
同時，有不理解或有誤的地方也歡迎評論區留言大家一起吹牛聊天交流技術🤗。
- ✔️如果這篇文章對你有用，記得點個贊👍🏻加個關注支持我一下~
- ✔️我們下期見！👋👋👋