關于性能測試需要知道的
隨著各企業的業務發展、用戶量以及數據量的不斷增加，系統承載的壓力也會隨之增加，服務系統的性能好壞又嚴重影響企業的利益。因此，性能測試重要性與需求越來越強烈。
常見的性能測試目的
性能測試是確定系統在特定工作負載下的穩定性和響應能力。在進行性能測試之前，首先是要明確性能測試的目的，目的不同，對應的解決方案會有很大差異，最常見的性能測試目的（或契機）有三種：
(1) 評測當前系統性能
通過性能測試了解系統當前的性能是否達到預期。例如：新系統上線前、技術升級后，都會進行性能測試，確保系統在線上穩定可靠地運行。
(2) 尋找瓶頸，優化性能
系統已知有性能問題，進行測試尋找瓶頸，以便優化其性能。例如：用戶提出業務操作響應時間長，需要定位問題，調整性能；系統運行一段時間后，速度變慢，尋找瓶頸，進而優化
(3) 預測系統未來的性能、可擴展性
通過性能測試預測系統在未來達到一定負載量的情況下，系統的性能表現。為的是提前預防并降低風險。擴展能力非常好的系統，性能是隨資源擴展呈線性或接近線性提升。
性能測試的不同類型
(1) 基準測試
基準測試：系統較低壓力時，查看系統的運行狀況并記錄相關數作為基礎參考。
(2) 負載測試
負載測試是通過逐漸增加系統負載，測試系統性能的變化，并最終確定在滿足性能指標的情況下，系統能承受的最大負載量的測試。目標：確定系統的性能容量（如系統在保證一定響應時間情況下能夠允許多少并發用戶的訪問），系統各項指標，如吞吐量、響應時間、CPU負載、內存使用等如何決定系統的性能。
(3) 壓力測試
壓力測試通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。目標：壓力測試是為了發現在什么條件下您的應用程序的性能會變得不可接受。
(4) 并發性能測試
負載測試和壓力測試通常被合稱為并發性能測試。即大并發場景下的系統性能，多用戶同時訪問時，檢測系統是否能夠穩定運行。
(5) 大數據量測試
大數據量測試包括獨立的數據量測試和綜合數據量測試。獨立的數據量測試指針對某些系統存儲、傳輸、統計、查詢等業務進行的大數據量測試。綜合數據量測試指系統在具備一定數據量時，在負載壓力測試下，考察業務是否能夠正常運行的測試。目標：測試數據量較大時系統的性能狀況。
(6) 容量測試
容量測試的目的是通過測試預先分析出反映軟件系統應用特征的某項指標的極限值（如最大并發用戶數），系統在其極限狀態下沒有出現任何軟件故障且能正常運行。
(7) 配置測試
通過對被測系統軟硬環境的調整，了解各種不同環境對系統性能的影響程度，從而找到系統各項資源的最優分配原則。
(8) 穩定性測試
穩定性是通過給系統加載一定的壓力，讓系統持續運行一段時間（通常為7x24小時），檢測系統是否能夠穩定運行。穩定性測試也稱為疲勞強度測試，屬于可靠性測試的范疇。目標：測試系統長時間無故障穩定運行的能力
(9) 失效恢復測試
失效恢復測試是針對有冗余備份或負載均衡的系統來說，檢驗如果系統局部發生故障，系統災備措施是否可以正常啟動，用戶是否可以繼續使用。（如：集群、熱備等） 目標：通過實施失效恢復測試，評估系統的健壯性和可恢復性。
在實際項目當中，可根據不同的性能測試目的，選相對應的性能測試方式。
性能測試的監控指標
在進行各類性能測試時，需要同步檢測系統各項性能指標，從而分析系統的實際的響應能力與穩定性等。常用的性能監測指標有四類：業務性能指標、資源性能指標、中間件監測指標、數據庫監測指標。
業務性能指標
- 每秒交易數（TPS）：每秒鐘系統能夠處理的交易或事務的數量
- 響應時間：從請求端發起請求開始，到請求端接收到服務器端的返回結束，這個過程所耗費的時間。
- 并發用戶數：指系統可以同時承載的正常使用系統功能的用戶的數量，即在給定的時間段內正在使用系統的用戶數。
- 在線用戶數：沒有提交請求，會話狀態在線的用戶數。
- 吞吐量：指系統在單位時間內處理請求的數量。即在給定時間段內系統完成的交易數量。
(1) 響應時間行業標準
- 互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右。
- 金融企業：1秒以下為佳，部分復雜業務3秒以下。
- 保險企業：3秒以下為佳。
- 制造業：5秒以下為佳。
- 時間窗口：不同數據量結果是不一樣的，大數據量的情況下，2小時內完成。
(2) TPS行業標準
- 互聯網企業：500毫秒以下，如某寶業務10毫秒左右。
- 金融行業：1000TPS~50000TPS，不包括互聯網化的活動
- 保險行業：100TPS~100000TPS，不包括互聯網化的活動
- 制造行業：10TPS~5000TPS
- 互聯網電子商務：10000TPS~1000000TPS
- 互聯網中型網站：1000TPS~50000TPS
- 互聯網小型網站: 500TPS~10000TPS
資源性能
- CPU指標：主要指的CPU使用率、利用率，包括用戶態（user）、系統態（sys）、等待態（wait）、空閑態（idle）。一般情況下，CPU使用率、利用率要低于警戒值范圍75%。
- 內存/SWAP：內存利用率100%并不代表內存有瓶頸，衡量系統內有瓶頸主要靠SWAP（與虛擬內存交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低于70%，太多的交換將會引起系統性能低下。
- 磁盤吞吐量：磁盤吞吐量是指在無磁盤故障的情況下單位時間內通過磁盤的數據量。磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的重要依據，一般情況下，磁盤繁忙率要低于70%。
- 網絡吞吐量：網絡吞吐量是指在無網絡故障的情況下單位時間內通過的網絡的數據數量。一般情況下不能超過設備或鏈路最大傳輸能力的70%。
資源性能（CPU、內存、磁盤）行業標準：
- CPU 利用率要低于業界警戒值范圍之內，即小于或者等于75%;
- CPU sys%小于或者等于30%;
- CPU wait%小于或者等于5%
- SWAP交換空間利用率低于70%
- 磁盤繁忙率低于70%
- 網絡吞吐不能超過最大傳輸能力70%
中間件指標
中間件監測指標主要包括JVM、線程池、JDBC連接池，常用的中間件如：Tomcat、Weblogic等。
中間件監控內容及行業標準：
- 線程數最小設置50和最大設置200比較合適。
- JDBC最小設置50和最大設置200比較合適。
- JVM最小堆大小和最大堆大小分別設置1024M比較合適。
數據庫性能指標
- SQL：執行SQL耗時
- 吞吐量：每秒事務次數（TPS），每秒查詢次數（QPS）
- 鎖：鎖等待次數和鎖等待時間
- 命中率：索引緩沖區命中率、線程緩存命中率、表緩存命中率、查詢緩存命中率等。
數據庫監控內容及行業標準：
- SQL耗時越小越好，一般情況下微秒級別。
- 命中率越高越好，一般情況下不能低于95%。
- 鎖等待次數越低越好，等待時間越短越好。
- 操作系統內核參數主要包括信號量、進程、文件句柄。
性能測試流程
首先要制定測試計劃，明確目的、策略等。以測試計劃為依據，逐步開展性能測試工作。
明確性能測試目標
確定本次性能測試的目標，包括性能測試對象、需求范圍，以及性能指標達標要求，即測試退出條件。
制定性能測試計劃
確定了測試對象和測試需求之后，需要制定一份性能測試計劃，指導性能測試工作的進行。包括：簡介、測試環境、測試場景、測試數據、測試策略、測試時間與人員安排。
(1) 測試環境
描述性能測試環境的物理架構。
(2) 測試場景
針對各業務功能模塊，設計不同測試類型（穩定性測試、負載測試、壓力測試）等的單場景、組合場景測試。
(3) 測試數據
描述各性能測試場景下的數據量要求，加壓多大數據量需要提前與業務側對齊目標，系統現存數據體量以及每年增長幅度也可以通過與業務人員（產品經理)確定，當然也可以一些經驗方法或公式來估算。比如：有并發用戶數與峰值公式，以及二八原理估算方法。
- 【并發用戶數公式】：C = nL/T。C：平均的并發用戶數；n：平均每天訪問用戶數（login session的數量）；L：一天內用戶從登錄到退出的平均時間（login session的平均長度）；T：考察的時間段長度（一天內多長時間有用戶使用系統）；
- 【并發用戶數峰值公式】：C'≈C+3*根號C。其中：C：公式1中的平均并發用戶數；
- 【二八原理估算測試強度】：每個工作日中80%的業務在20%的時間內完成。例如：每年業務集中在8個月，每個月20個工作日，每個工作日8小時，即每天80%的業務的在1.6小時完成。去年全年處理業務約100萬筆，其中15%的業務處理中每筆業務需對應用服務器提交7次請求；其中70%的業務處理中每筆業務需對服務器提交5次請求；其余15%的業務處理中每筆業務需對應用服務器提交3次請求。（根據以往統計結果，每年的業務增量為15%，考慮到今后3年業務發展的需要，測試需按現有業務量的兩倍進行。）
(4)性能測試策略
描述性能測試方法和流程與工具等。需要進行哪幾種類型的測試。
(5) 測試時間與人員安排
描述參與性能測試的人員，以及性能測試時間計劃。
執行性能測試
依據性能測試計劃進行實施測試，準備測試環境、構造測試數據 、執行測試用例 、記錄測試結果。在此過程中，如發現性能問題，提交Bug，修正Bug。
性能測試報告
完成性能測試之后，編寫性能測試報告，整理總結本次性能測試的背景、目的、測試范圍、測試指標需求、測試環境與工具、測試內容、測試結果與分析等。
其中測試結果與分析主要是羅列測試指標結果數據及圖表，并且對測試的結果及發現的性能問題進行總結、分析。性能測試報告樣例參見下圖：
性能測試工具
為了更高效的進行性能測試，選用適合的測試工具非常關鍵，下面列舉了一些常用的性能測試工具供參考。
