淺析性能測試策略及適用場景

面對日益複雜的業務場景和不一樣的系統架構，前期的需求分析和準備工做，須要耗費不少的時間。而不一樣的測試策略，也對咱們的測試結果是否符合預期目標相當重要。

這篇博客，聊聊我我的對常見的性能測試策略的理解，以及它們的適用場景。。。

 

1、常見的測試策略

性能測試實施過程當中，針對不一樣的業務場景，咱們通過分析和場景建模後，會選擇不一樣的測試策略。下面的十種測試策略，覆蓋了絕大多數的場景。

一、併發測試

模擬客戶端請求，在單位時間內(S)同時發起必定量的請求，驗證系統是否具備併發性的問題。

PS：不要無腦高併發！！！

二、負載測試

不斷增長請求壓力，直到服務器某個資源項達到飽和（好比CPU使用率達到90%+）或某個指標達到安全臨界值（好比運維的監控告警閾值or拐點）；

負載測試（也叫階梯式壓測）通常主要用來尋找性能的拐點，驗證系統在既有測試環境不一樣的請求壓力下可否正常運行。示例以下：

三、容量測試

採用負載測試策略，驗證在現有測試環境下被測系統的最大性能表現（可接受的最大性能表現，不必定是最優性能表現）。

四、極限測試

在既有測試環境下，不考慮資源佔用率的極限狀況（CPU使用率達到95%以上或IO異常繁忙或Load值較高），在系統不宕機的狀況下的最大處理能力。

PS：因爲被測系統的業務場景各不相同，這種策略，採用率相對較少。

五、配置測試

不斷調整系統各方面的配置（軟硬件、參數配置等），驗證在性能達到最優時（最優的性能必定是權衡各方面因素找到的平衡點）的最佳配置。

六、浪涌測試

驗證系統在某段時間內併發突增或請求量波動較大的狀況下，系統可否正常穩定的提供服務。

PS：這種測試策略使用的也相對較少，主要針對不肯定性的短時間的峯值流量涌入場景（好比某微博的離婚、戀愛、分手話題）。

七、穩定性測試

以恆定的併發數（根據負載測試的結果，CPU使用率在70%時對應的併發數），驗證系統在混合場景下的性能表現。

八、批處理測試

驗證待測系統在既有環境下，系統的批處理（通常都是一個crontab或者觸發式的job）業務能力可否知足生產的業務需求指標。

九、高可用測試

在集羣多節點或分佈式的狀況下，破壞其中一個或多個集羣節點，驗證系統可否及時恢復服務能力。

十、容錯恢復測試

驗證系統可否在出現故障的狀況下仍能保持正常提供服務的能力或出現故障後的自我恢復能力。好比下面這張圖：

a1面積越大，說明系統的處理能力越強；a2面積越大，說明系統穩定性越好；a3面積越大，說明系統的容錯能力越好（嘖嘖，圖有點醜。。。）

以前有手動畫了好幾個性能模型圖，找不到了，尷尬。。。

 

2、適用場景

以上十種測試策略，根據適用的業務&測試場景、採用該策略的目的以及場景出現頻次來劃分，僅供參考。

 

3、經驗之談

一、中小型團隊：常規的測試策略選型：併發、負載、容量、配置、批處理、穩定性、高可用策略，能夠覆蓋絕大部分需求。

二、電商類業務：高併發、高可用、穩定性，是重中之重。

三、業務場景：不少時候一個性能需求包含好幾個業務場景，但併發、負載、容量、穩定性，建議都採用。

四、需求場景：需求分析和場景建模作很差，測試結果每每誤差很大。

五、壓測環境：環境的調研選型，建議和生產環境等配置最小化部署，這是成本和結果精準度的平衡。

六、測試數據：不管是數據量仍是數據的有效性以及熱點數據的覆蓋率，都決定了測試結果的可參考價值。

七、技術建設：基礎架構（包括環境、服務部署、詳盡的監控體系、問題處理流程）的完備，才能讓性能測試左移。

八、文檔建設：必定要重視文檔建設和數據留存，這樣能夠避免不少沒必要要的麻煩和重複性工做。

九、平臺化：平臺的做用是對流程的規範以及多人協同工做的效率整合，不要過分追求平臺化（但必定要有技術規劃和方案准備）。

十、不要無腦高併發！！！