引用：根據2008年Aberdeen Group的研究報告，對于Web網站，1秒的頁面加載延遲相當于少了11%的PV（page view），相當于降低了16%的顧客滿意度。如果從金錢的角度計算，就意味著：如果一個網站每天掙10萬元，那么一年下來，由于頁面加載速度比競爭對手 慢1秒，可能導致總共損失25萬元的銷售額。

Compuware公司分析了超過150個網站和150萬個瀏覽頁面，發現頁面響應時間從2秒增長到10秒，會導致38%的頁面瀏覽放棄率。由此可見，網站性能與業務目標有著直接的關系，對網站進行性能測試非常重要。

做性能測試的同學都知道性能執行中有很多場景，每個企業還會有自己定義的場景名詞在這里就不列舉，我做性能一般使用四個場景（基準場景、容量場景、穩定性場景、異常場景）來覆蓋一個性能需求。下面聊一聊這四個場景怎么落地怎么覆蓋性能需求。

實際落地

在聊四個場景之前我們先聊下性能測試一般流程，流程就是規則，在孟子-《離婁章句上》:"離婁之明，公輸子之巧，不以規矩，不能成方圓"。有這個流程后遇到性能測試就不會亂手腳，就可以按這個流程開展工作。

關于每個動作需要做什么內容，做性能測試的人一看就知道需要做什么內容，在這里就不展開說明具體內容。我們做好前置條件后，就可以開展場景設計與執行，對于性能分析就不在這節課講解，這里使用 Jmeter 壓力工具、 TPS 是指 Jmeter 中Summary Report 組件中的 Throughput 值、后端接口不考慮前端頁面js、css等頁面元素加載時間，在具體做性能測試中也可以使用其他壓力工具做，沒有限制用什么壓力工具，這里主要講解場景怎么使用。

基準場景

基準場景就是單個接口進行壓測，如果這樣講解誰都知道，那么我們應該怎么做基準場景呢？

• 環境準備

在互聯網企業做性能測試一般都選擇在線上進行壓測，都知道搭建一套與線上一致的壓測環境成本比較高如硬件成本、軟件成本、人力成本、維護成本等等所以互聯網企業選擇線上做壓測。?對于不是一線互聯網企業或者傳統行業一般都是在測試環境中做壓測，我待過的銀行保險就有自己的壓測環境，他們的環境相對來說比較獨立，做壓測，做調優相對來說比較方便。

在測試環境中壓測建議機器配置與線上機器配置一致，應用容器配置也得與線上環境一致，只有這樣壓測出來的結果才真實，說白了就是壓測環境與線上環境需要一致，如果不能一致需要按一定比例做縮容。

• 數據準備

對于數據準備我們需要考慮壓測環境中的鋪墊數據量，一般鋪墊數據來源脫敏后的真實生存庫數據，在壓測開始前需要把數據庫備份，方便做問題排查，問題定位等等。如果數據量與線上數據量不一致，會導致壓測結果不可信，大家可以思考下一個幾百條數據庫與線上百萬，千萬條數據庫在性能上面根本不是一個級別的事情，所以在壓測時候需要考慮壓測環境中鋪墊數據量。

• 參數準備

在做性能壓測腳本時我們需要準備參數化數據，很多人覺得做性能測試幾條數據就夠，不需要大量數據做性能測試，這樣就會導致壓力與真實生存環境不一致，比如，幾十條數據操作出千萬級乃至億級業務，這樣壓測出來的場景可信度就不好說。那么到底多少參數設置合理呢？

要回答這個問題需要確定參數化用在什么場景，因為場景不一樣，參數化數據也不一樣，假如不考慮場景情況下，100個線程，TPS 為800，系統運行1小時，數據類型、限制條件和數量計算方式如下：

假如把場景考慮進來我們就根據實際業務場景來分析用到什么樣的數據，以便計算參數化數據量，這里的數據包括重復與不重復的數據，這里用我司統一登錄做舉例說明，對于登錄業務需要兩個參數一個是賬號，一個是密碼（這不考慮通過驗證碼登錄）賬號與密碼必須可登錄系統的否則不能完成后續業務操作，很顯然不同人一定用不同賬號登錄。

??場景一

我們在做腳本的時候，有多少線程就配置多少個用戶，讓每個線程用同一用戶循環執行業務操作，但是這樣的參數配置只能滿足特定業務場景，比如早上登錄后一直不退出，一直帶著 token 操作業務，到下班退出系統，這樣的場景我們有多少線程就需要準備多少用戶數據。

??場景二

對于一個電商系統按上面參數就不可取，因為一個賬號不停購買商品這樣的行為完全不符合真實場景，這時候我們應該怎么辦呢？在這樣的場景中，我們需要考慮TPS 和持續時間，用戶數據計算方式參考：

??場景三

假如一個線程可以循環使用固定參數，在這情況下我們需要根據實際業務判斷，比如100 壓力線程情況下，我們準備 1000 條數據，我們就可以讓每個線程用不同的 10 條數據。這樣的場景沒固定條數限制，只能根據實踐業務判斷，但是在配置這個參數之前還需要考慮參數是什么類型，如果是可循環的數據，那么它在真實性能場景非常少，也就是說只使用一條或者幾條測試數據真實場景基本沒有。

• 參數化數據

知道參數用多少后，還需要解決參數化數據從什么地方獲取，這一步目的是確保參數數據是有效的，一般我們參數化數據來源兩個方向，一個是后臺數據庫存在的，一個是數據庫不存在通過壓力工具造出來的數據。

總之參數化數據來源需要確保數據的有效性，這些數據需要滿足下面兩個條件：

???? 滿足生產環境數據分布

???? 滿足性能場景中數據量的要求

對于一個系統來說，參數化數據是否合理，會直接影響壓力測試結果是否有意義。如果壓力工具使用的數據量少，那么那么應用服務器、緩存服務器、數據庫服務器等都將使用少量的緩存來處理，導致不能把后端各類服務器的緩存占用到真實場景中應該有的大小，所以在這種狀態之下是測試不出來真實場景下的壓力。

對數據庫連接的存儲設備來說同樣也有影響。如果數據量少，則相應的存儲的 I/O 使用就少。參數取得過多，對系統的壓力就會大；參數取得過少，不符合真實場景中的數據量，則無法測試出系統真實的壓力。

如果參數來源于數據庫，我們通常要檢查一下數據庫中的數據直方圖。對于直接從生產上拿的數據來說，數據的分布更為精準。但是對于一些在測試環境中造的數據，則一定要在造數據之后，檢查下數據分布是否與生產一致。有上面準備后，就可以開始做基準測試，我們在做基準測試需要注意兩個點：

我們在實施中什么時候基準場景結束呢？或者到壓到什么情況下就可以結束基準場景呢？一般壓測過程中接口調用系統資源使用率到達90%或者完全把系統資源使用完畢就可以停止基準場景，注意遇到性能問題需要調優確保資源充足使用，以達到 TPS 還有響應時間是最合理。

容量場景

對于容量場景來說就是把之前基準場景所有接口按一定比例組合起來一起執行，還有做容量場景的目的是要回答“線上容量最大能達到多少”的問題。這里有個問題就是接口與接口間的比例怎么定？在壓力工具中又怎么配置？如果不能解決這些問題我們就沒法做容量場景設計，可能有些同學就說，直接把接口全部放到一個場景按1倍、2倍、3倍等倍數直接跑就行，沒有必要考慮每個接口比例，直接跑個最大值就行，但是這樣場景與實際場景有差距，跑出來的場景脫離真實性，那么我們應該怎么設計呢？還有一個問題就是容量場景什么時候停止？

首先我們可以抽取生產日志，相信每個公司都有日志系統，如果沒有日志系統可以使用 awk 命令去抽取日志，還可以使用 ELFK 來抽取日志，有上面數據后，就可以梳理業務邏輯。

我司可以通過 lambda 平臺可以獲取被壓測日志，通過檢索條件獲取我們想要一段時間的接口數據：

如果沒有這樣的系統我們可以在?Nginx 日志中獲取相關數據， 可以通過寫 python 腳本處理也可以使用 shell 命令獲取我們想要的數據，我們需要數據格式為：

這樣我們就可以知道，每個時間段內每個請求的數量，也就可以得到相應的業務比例了。

如果是 ELFK 抽出生存日志大家可以自己安裝一個這樣的環境配置后，設置相關條件抽出上面數據對應關系的數據類型。

注意：如果出現某個請求的高并發時間點和其他的請求不在同一時間點，就一定要做多個場景來模擬，因為場景中的業務模型會發生變化。

假設我們通過上面步驟就能得出被壓測接口的調用量與請求比例，也就可以拿某請求的數量除以總請求數得出每個接口的比例,這里使用一個表格做說明（注意里面數據是假設出來）：

這里總結下獲取生產數據比例步驟：

請注意，上面的業務場景在實際的項目業務統計過程中可以有多個。這個思路可以解決任何性能場景和生產場景不一致的問題。有業務比例后接下來我們需要梳理業務場景，用場景覆蓋業務比例，場景比例應該怎么設計呢，大家可以思考下，設計幾個場景能覆蓋上面接口業務比例，這里就不講解，大家自己思考思考。

用 JMeter 里面，會用Throughput Timer來控制TPS。

關于 Throughput Controller ?控制器怎么場景比例，大家可以查詢資料就能解決。

有上面業務比例后，我們可以思考下容量場景在什么情況下結束呢？我們在做容量場景時需要確定一個目標，否則就沒有結束時間點。大家是否還記得我們在業務比例分配的時候是按一個數據總量分配給每一個接口做比例，這個總量就是我們容量測試的目標。

穩定性場景

我們在前面提到，容量場景是為了看系統所能承受的最大容量，而穩定性場景主要看的是系統提供長時間服務時的性能穩定性，觀察系統在長時間運行過程中出現的累積效應。因此，運行時長就是穩定性場景中非常重要的一個指標了。

這里需要明白穩定性運行時長不是固定的，它取決于業務系統的具體應用場景，那么應該怎么計算穩定性時間呢？這里提供一種計算執行時間計算方法。

假設你根據生產系統統計出，在之前的運維周期中，有6千萬的業務容量，而在容量場景中得到的最大TPS有1000。那么，我們就可以通過下面這個公式來計算：

穩定性運行時長=6千萬(業務累積量)÷1000(TPS)÷3600(秒)≈16(小時)。

不管是什么樣的系統，要想運行穩定性場景，都得確定一個業務累積量（一時間業務總量），我們在執行的時候直接用最大TPS來運行，如果一個系統在最大TPS狀態下正常運行，才能驗證系統能否經得起考驗。

異常場景

在異常場景設計中首先針對系統的架構，先分析異常場景中的需求點，再設計相應的案例來覆蓋。為什么要分析系統架構呢？因為在一個應用中，我們把功能測試完一遍之后，異常問題通常有兩大類：其一是架構級的異常；其二是容量引起的性能異常。而對于架構級的異常，我們只能站在架構的角度進行分析。

從性能技術的角度來說，基本上采用的是宕主機、斷網絡、宕應用等常用測試手段，現在市場上還有混沌工具，大家也可以采用混沌工具做異常測試，這提供一些通用手段幫助大家做操作：

??主機：斷電、reboot、shutdown 等；

??網絡：ifdown 命令關網卡、模擬抖動丟包延時重傳等；

??應用：kill、stop 等。

這里再談下異常場景設計的邏輯，第一步把技術架構中的組件全部列出來，并分析可能產生異常的點，第二步根據分析異常點設計對應的場景。在很多時候都是根據感覺走，就會導致異常場景覆蓋不全，這里建議參考 FMEA 失效模型來設計異常場景，因為有 FMEA 可以讓我們有章可循，這里要注意的是對于任何方法論還有邏輯在實踐落地時候都不要過度使用，而是要注意內容的合理性。

這里只是提供一種設計思路，大家在落地的時候把不符合自己公司的或者實踐干活的可以去的，希望大家設計一套符合自己系統的異常場景模型。