性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。需要在對系統性能有一定程度了解的前提下，在確定的環境下進行壓測。從測試目的上性能壓測又可以劃分為負載測試、壓力測試、并發測試、配置測試以及可靠性測試。

• 負載測試是測試當負載逐漸增加時，系統各項性能指標的變化情況。

• 壓力測試是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。

• 并發測試通過模擬用戶并發訪問，測試多用戶并發訪問同一個軟件、同一個模塊或者數據記錄時是否存在死鎖等性能問題。

• 配置測試是通過對被測系統的軟/硬件環境的調整，了解各種不同方法對軟件系統的性能影響的程度，從而找到系統各項資源的最優分配原則。

• 可靠性測試是在給系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定。

適用場景

性能壓測可以用于以下場景：

1. 新系統上線支持：在新系統上線前，通過執行性能壓測能夠對系統的負載能力有較為清晰的認知，從而結合預估的潛在用戶數量保障系統上線后的用戶體驗。

2. 技術升級驗證：在系統重構過程中，通過性能壓測驗證對比，可以有效驗證新技術的高效性，指導系統重構。

3. 業務峰值穩定性保障：在業務峰值到來前，通過充分的性能壓測，確保大促活動等峰值業務穩定性，保障峰值業務不受損。

4. 站點容量規劃：通過性能壓測實現對站點精細化的容量規劃，指導分布式系統機器資源分配。

5. 性能瓶頸探測：通過性能壓測探測系統中的性能瓶頸點，進行針對性優化，從而提升系統性能。

性能壓測伴隨著系統開發、重構、上線到優化的生命周期，有效的性能壓測對系統的穩定性具有重要的指導意義，是系統生命周期中不可或缺的一部分。

最佳實踐

確定性能測試目標和基線

性能測試目標可能源于項目計劃、業務方需求等。這一階段需要確定性能測試的業務指標和系統的資源指標和應用指標。

業務指標中，最需要關注的是以下“黃金三指標”：

• 業務響應時間：具體指標為RT（Response Time），業務部門一般更關注此指標的具體值。一般情況下，不同系統的業務響應時間期望值是不同的，建議１秒以內。像大型電商系統業務RT基本在幾十毫秒以內。

• 業務吞吐量：具體指標為TPS（Transaction Per Second，即系統每秒處理事務數），這個指標是衡量系統的處理能力的一個非常重要的指標。TPS可以參照同行業系統和結合具體業務，中小企業TPS值為50~1000筆/秒，銀行TPS值為1000~50000筆/秒，大型電商系統TPS值為30000~300000筆/秒。

• 成功率：這個指標是衡量系統處于壓力下，業務的成功率，一般業界成功率要大于99.6%。

確定以上業務指標后，即可定義出性能基線，在手動或自動化執行完性能測試后，將測試結果和性能基線比對，判斷性能測試是否通過。

確定性能壓測環境

全新生產環境

如果是剛遷移到云上或者是新的機房，全鏈路的進行業務壓力測試之后可以進行正式投產的，這種驗證效果較好，因為最終就是真實的性能環境，一般可以將真實的生產環境數據進行脫敏導入，確保業務數據量（交易數據、流水、各種業務核心業務記錄等）維持在半年以上，同時確保數據的關聯完整性（包括跨系統的業務完整性數據），壓測基于這些基礎數據進行相應的核心業務的流量（登錄、購物車行為、交易行為等）構建，最后在投產前做相應的數據清理再初始化一次存量基礎數據。

等比性能環境

一般是指在生產環境單獨劃分區域，準備等比的容量，共享接入層的性能測試環境。這種方案缺點是成本較高，優點是方案簡單、風險可控，容量規劃較為精準。

在等比性能環境中，必須保證有共享的接入層（CDN動態加速、BGP、WAF、SLB、4層7層負載均衡等等，確保最重要的網絡接入層相同，能發現問題）。后端的服務容量配比上至少保證是生產環境的1/4，配比越大精準度也會大幅下降，數據庫建議能相同配置。在基礎數據的準備上和上面全新生產環境的方法一致，確保業務數據量維持在半年以上，同時保證數據的關聯完整性。

生產環境

生產環境上基礎數據基本分為兩種方式，一種是數據庫層面不需要做改造，直接基于基礎表里的測試賬戶（相關的數據完整性也要具備）進行，壓測之后將相關的測試產生的流水數據清除（清除的方式可以固化SQL腳本或者落在系統上）；另一種就是壓測流量單獨打標（如單獨定義的Header），然后業務處理過程中識別這個標并傳遞下去，包括異步消息和中間件，最終落到數據庫的影子表或者影子庫中。此外，生產環境的壓測盡量在業務低峰期進行從而避免影響生產的業務，無論上述哪種方式都可以通過部署單獨的壓測專用集群來進一步避免對生產業務的影響。

在云計算時代，推薦使用等比性能環境的方案。在壓測時，快速彈性擴容出足夠的計算資源，壓測結束后，即可縮容，節省成本。

構建性能測試場景

執行性能測試前，需要構造測試腳本，并為腳本準備輸入參數文件，來盡可能模擬全業務鏈路的真實請求鏈路與負載。為了保證測試腳本能夠擬合真實用戶的行為，并且腳本中不遺漏接口，一般會采用錄制的方式，從瀏覽器或客戶端將用戶行為完整記錄下來，并自動轉為壓測腳本。開源JMeter壓測工具和阿里云PTS都提供了腳本錄制工具，幫助用戶高效構建測試腳本。

執行性能測試，分析測試結果

測試腳本和輸入參數文件構造完成后，就可以借助性能壓測工具，按照設計來執行測試了。執行過程中，需要觀察請求成功率、響應時間、業務吞吐量，如果發現指標有明顯的拐點，比如成功率或吞吐量大幅下降、響應時間大幅上升，就代表系統已經遇到性能瓶頸，可以根據系統資源監控和應用監控，定位具體的瓶頸點，做對應的彈性擴容。調優后，重新執行測試，驗證擴容效果。

持續壓測，防止性能退化

性能測試通過后，需要定期執行回歸測試，并比對性能基線，防止在持續迭代過程中系統性能退化，一般定期的頻率與敏捷開發的周期一致，推薦每一周或兩周，自動化定時執行性能測試，如果發現性能大幅退化，可以及時回滾系統版本，并配合性能監控，排查瓶頸點。