效能測試概念、適用情境和相關的最佳實務。
效能測試是通過自動化的測試載入器類比多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。需要在對系統效能有一定程度瞭解的前提下，在確定的環境下進行壓測。從測試目的上效能壓測又可以劃分為負載測試、壓力測試、並發測試、配置測試以及可靠性測試。
負載測試是測試當負載逐漸增加時，系統各項效能指標的變化情況。
壓力測試是通過確定一個系統的瓶頸或者不能接受的效能點，來獲得系統能提供的最大服務等級的測試。
並發測試通過類比使用者並發訪問，測試多使用者並發訪問同一個軟體、同一個模組或者資料記錄時是否存在死結等效能問題。
配置測試是通過對被測系統的軟/硬體環境的調整，瞭解各種不同方法對軟體系統的效能影響的程度，從而找到系統各項資源的最優分配原則。
可靠性測試是在給系統載入一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定。
適用情境
效能壓測可以用於以下情境：
新系統上線支援：在新系統上線前，通過執行效能壓測能夠對系統的負載能力有較為清晰的認知，從而結合預估的潛在使用者數量保障系統上線後的使用者體驗。
技術升級驗證：在系統重構過程中，通過效能壓測驗證對比，可以有效驗證新技術的高效性，指導系統重構。
業務峰值穩定性保障：在業務峰值到來前，通過充分的效能壓測，確保大促活動等峰值業務穩定性，保障峰值業務不受損。
網站容量規劃：通過效能壓測實現對網站精細化的容量規劃，指導分布式系統機器資源分派。
效能瓶頸探測：通過效能壓測探測系統中的效能瓶頸點，進行針對性最佳化，從而提升系統效能。
效能壓測伴隨著系統開發、重構、上線到最佳化的生命週期，有效效能壓測對系統的穩定性具有重要的指導意義，是系統生命週期中不可或缺的一部分。
最佳實務
確定效能測試目標和基準
效能測試目標可能源於專案計劃、業務方需求等。這一階段需要確定效能測試的業務指標和系統的資源指標和應用指標。
業務指標中，最需要關注的是以下“黃金三指標”：
業務回應時間：具體指標為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都提供了指令碼錄製工具，協助使用者高效構建測試指令碼。
執行效能測試，分析測試結果
測試指令碼和輸入參數檔案構造完成後，就可以藉助效能壓測工具，按照設計來執行測試了。執行過程中，需要觀察請求成功率、回應時間、業務輸送量，如果發現指標有明顯的拐點，比如成功率或輸送量大幅下降、回應時間大幅上升，就代表系統已經遇到效能瓶頸，可以根據系統資源監控和應用監控，定位具體的瓶頸點，做對應的彈性擴容。調優後，重新執行測試，驗證擴容效果。
持續壓測，防止效能退化
效能測試通過後，需要定期執行迴歸測試，並比對效能基準，防止在持續迭代過程中系統效能退化，一般週期性頻率與敏捷開發的周期一致，推薦每一周或兩周，自動化定時執行效能測試，如果發現效能大幅退化，可以及時復原系統版本，並配合效能監控，排查瓶頸點。