網上一搜效能測試，就會出現很多諸如效能測試、負載測試、壓力測試、強度測試等一堆專有名詞的解釋。

但實際上我們不需要區分這麼多。

那什麼是效能測試？

高樓老師在[效能測試實戰30講]中給出了一個定義，我覺得參考價值很大。

效能測試針對系統的效能指標，建立效能測試模型，制定效能測試方案，制定監控策略，在場景條件之下執行效能場景，分析判斷效能瓶頸並調優，最終得出效能結果來評估系統的效能指標是否滿足既定值。

這個定義，其實也就是一個完整的效能測試流程了。

為什麼要弄清楚？因為這些概念要抹平溝通的誤解，讓不同層級，不同角色的人，可以在同樣的知識背景下溝通，也可以讓做事情的人有清晰的邏輯思路。

一、效能測試需要有指標

指標這個東東通常在很多公司並沒有明確的定義。可能老闆隨口一句“把系統壓掛”，下面人就得開始張羅了。但是這個“把系統壓掛”其實就是一種指標。

通常來說，有三種指標：時間指標、容量指標和資源利用率指標，具體這裡先不展開。

二、效能測試需要有模型

模型，可以理解為場景。

比如說，要對一個返回廣告的介面進行效能測試。那麼使用者進入首頁之後，可能有50%的人會點選 banner 位廣告，30%的人會點選中部位的廣告，最後20%的人會點選側邊框廣告。

那麼，你基於這樣的一個模型，在施加壓力的時候就需要控制好比例。這些業務資料，通常來說是有渠道可以獲得的。

三、效能測試要有方案

需要確定性能測試方案，以便指導後續的工作。

通常來說，內容如下：

• 測試環境
• 測試資料
• 測試模型
• 效能指標
• 壓力策略
• 准入準出
• 進度風險

其中每一項內容的細化程度，要具體參考專案需要。

四、效能測試中要有監控

關於監控：

• 分層、分段
• 全域性監控、定向監控

具體這裡先不展開。

五、效能測試要有預定的條件

在測試場景執行之前，通常要確定如下的條件：

• 軟、硬體環境
• 測試資料
• 測試執行策略
• 壓力補償

六、效能測試中要有場景

場景：在既定的環境（包括動態擴充套件等策略）、既定的資料（包括場景執行中的資料變化）、既定的執行策略、既定的監控之下，執行效能指令碼，同時觀察系統各層級的效能狀態引數變化，並實時判斷分析場景是否符合預期。

效能場景也要有分類，通常逃不出如下四大類

1. 基準效能場景

這裡要做的是單交易的容量，為混合容量做準備。

2. 容量效能場景

是最核心的效能執行部分。根據業務複雜度的不同，這部分的場景會設計出很多個。

3. 穩定性效能場景

最核心的元素是時間，而時間的設定應該來自於運維週期，而不是來自於老闆、產品和架構等這些人的“拍腦袋”。

4. 異常效能場景

要做異常效能場景，前提就是要有壓力。在壓力流量之下，模擬異常。

那需要哪些異常？這也是要明確定義出來的。比如有宕主機、宕應用、宕網絡卡、宕容器、宕快取、宕佇列、宕流量控制、宕熔斷等等。

總之，實際的場景中需要模擬什麼異常，不是拍腦袋決定的，而是根據系統的業務架構和部署架構分析來的，不是看到有什麼都宕一下。

另外，關於場景下對應的測試用例，不僅要描述測試指令碼和測試資料，而且要描述需要哪些實時的判斷和動態的分析，否則會影響效能結果。

七、效能測試中要有分析調優

相信有很多跟我一樣的測試工程師，在進行效能測試的時候，其實也僅僅做的是效能驗證，很少有進行分析調優，因為很難（o(╥﹏╥)o）。

但是，分析調優才是一個更能體現效能測試價值的重要元素。

八、效能測試肯定要有結果報告

結果報告是效能測試活動的價值內容體現，自然要展示領導關心的內容，比如調優前後的 TPS、響應時間以及資源對比。相比較而言，用了多少人，花了多少時間可以往後放一放。

九、總結

一圖流。

本文參考：
高樓老師 效能測試實戰30講