面對日益復雜的業務場景和不同的系統架構，前期的需求分析和准備工作，需要耗費很多的時間。而不同的測試策略，也對我們的測試結果是否符合預期目標至關重要。
這篇博客，聊聊我個人對常見的性能測試策略的理解，以及它們的適用場景。。。
一、常見的測試策略
性能測試實施過程中，針對不同的業務場景，我們經過分析和場景建模后，會選擇不同的測試策略。下面的十種測試策略，覆蓋了絕大多數的場景。
1、並發測試
模擬客戶端請求，在單位時間內(S)同時發起一定量的請求，驗證系統是否具有並發性的問題。
PS：不要無腦高並發！！！
2、負載測試
不斷增加請求壓力，直到服務器某個資源項達到飽和（比如CPU使用率達到90%+）或某個指標達到安全臨界值（比如運維的監控告警閾值or拐點）；
負載測試（也叫階梯式壓測）一般主要用來尋找性能的拐點，驗證系統在既有測試環境不同的請求壓力下能否正常運行。示例如下：
3、容量測試
采用負載測試策略，驗證在現有測試環境下被測系統的最大性能表現（可接受的最大性能表現，不一定是最優性能表現）。
4、極限測試
在既有測試環境下，不考慮資源占用率的極限情況（CPU使用率達到95%以上或IO異常繁忙或Load值較高），在系統不宕機的情況下的最大處理能力。
PS：由於被測系統的業務場景各不相同，這種策略，采用率相對較少。
5、配置測試
不斷調整系統各方面的配置（軟硬件、參數配置等），驗證在性能達到最優時（最優的性能一定是權衡各方面因素找到的平衡點）的最佳配置。
6、浪涌測試
驗證系統在某段時間內並發突增或請求量波動較大的情況下，系統能否正常穩定的提供服務。
PS：這種測試策略使用的也相對較少，主要針對不確定性的短期的峰值流量涌入場景（比如某微博的離婚、戀愛、分手話題）。
7、穩定性測試
以恆定的並發數（根據負載測試的結果，CPU使用率在70%時對應的並發數），驗證系統在混合場景下的性能表現。
8、批處理測試
驗證待測系統在既有環境下，系統的批處理（一般都是一個crontab或者觸發式的job）業務能力能否滿足生產的業務需求指標。
9、高可用測試
在集群多節點或分布式的情況下，破壞其中一個或多個集群節點，驗證系統能否及時恢復服務能力。
10、容錯恢復測試
驗證系統能否在出現故障的情況下仍能保持正常提供服務的能力或出現故障后的自我恢復能力。比如下面這張圖：
a1面積越大，說明系統的處理能力越強；a2面積越大，說明系統穩定性越好；a3面積越大，說明系統的容錯能力越好（嘖嘖，圖有點丑。。。）
之前有手動畫了好幾個性能模型圖，找不到了，尷尬。。。
二、適用場景
以上十種測試策略，根據適用的業務&測試場景、采用該策略的目的以及場景出現頻次來划分，僅供參考。
三、經驗之談
1、中小型團隊：常規的測試策略選型：並發、負載、容量、配置、批處理、穩定性、高可用策略，可以覆蓋絕大部分需求。
2、電商類業務：高並發、高可用、穩定性，是重中之重。
3、業務場景：很多時候一個性能需求包含好幾個業務場景，但並發、負載、容量、穩定性，建議都采用。
4、需求場景：需求分析和場景建模做不好，測試結果往往偏差很大。
5、壓測環境：環境的調研選型，建議和生產環境等配置最小化部署，這是成本和結果精准度的平衡。
6、測試數據：無論是數據量還是數據的有效性以及熱點數據的覆蓋率，都決定了測試結果的可參考價值。
7、技術建設：基礎架構（包括環境、服務部署、詳盡的監控體系、問題處理流程）的完備，才能讓性能測試左移。
8、文檔建設：一定要重視文檔建設和數據留存，這樣可以避免很多不必要的麻煩和重復性工作。
9、平台化：平台的作用是對流程的規范以及多人協同工作的效率整合，不要過度追求平台化（但一定要有技術規划和方案准備）。
10、不要無腦高並發！！！