前面幾篇文章介紹了性能測試中的核心術語和指標、常用測試策略、壓測工具選型、性能需求分析以及性能測試能力分層和新手的學習路徑，這幾部分可以理解爲做性能測試之前打基礎的部分。
今天的這篇文章是性能測試知識科普的第六篇，我會聊聊在實際工作中開展性能測試，前期最核心的工作。
即業務模型、流量模型和數據模型這三大模型，該如何評估和建立。
在性能測試工作中，業務模型、流量模型和數據模型是至關重要且必須在項目中構建的，否則很可能導致測試的場景和實際差距很大，測試結果也無法爲性能分析和優化提供足夠有說服力的支撐。
爲了便於大家理解三大模型，我會以電商業務下單的場景來舉例說明，如下圖：
業務模型
大家可以將業務模型看作功能測試中的業務場景。在性能測試中要構建業務模型，我們要考慮如下幾個因素：
- 商品庫存是否足夠；
- 下單的商品是否可參與營銷活動；
- 下單的用戶是否是vip會員，有會員折扣；
- 下單的用戶是否有優惠券，該優惠券是否滿足本訂單的優惠條件；
- ............
其實業務模型和功能測試時候的業務場景分析沒什麼區別，都是爲了針對被測業務和服務進行分析，確保測試的場景和需求是一致的。
如果是更復雜的業務和更大範圍的測試需求，可能還要考慮線上業務的流量入口、風控等因素。
當然在實際的工作或項目中，建議通過分析需求，梳理出壓測涉及到的業務和場景，繪製成一個業務模型思維導圖，這樣便於後續的工作開展。
業務模型思維導圖可以用樹狀圖也可以用類似上圖的樣子，便於理解即可。
流量模型
我們都知道，性能測試執行壓測時，都是基於接口或某個URL來進行的。本質是模擬生產環境的用戶，構造請求對被測系統施加壓力，驗證系統性能是否滿足業務需要，是否存在性能瓶頸。
生產環境的用戶操作場景是很複雜的，所以請求的大小和請求路徑也各不一樣。
以上圖爲例，下單時候有些用戶使用了優惠券，有些用戶不是vip會員無法享受折扣，有些商品沒有營銷活動。這些因素要求我們在構造請求時，需要按照不同的業務場景構造不同的請求。
所謂的流量模型，其本質是按照業務場景的不同將請求按照真實的比例進行配置，也稱之爲業務配比。
大家也可以將流量模型理解爲壓測模型，工作中常見的壓測模型有如下幾種：
單機單接口基準測試
基準測試最常見的就是對登錄場景進行壓測。
單機單接口的壓測，可以通過梯度遞增的方式，觀察隨着請求的增加，其性能表現&資源損耗的變化。
單機混合鏈路容量測試
以上圖爲例，訂單服務包含創建訂單、取消訂單、訂單列表、訂單詳情等接口。
每個接口的請求量大小、請求內容各不相同。單機混合場景，大多通過梯度增加請求的方式，觀察服務級別的性能表現，目的是排查上下游調用依賴的瓶頸。
生產環境全鏈路壓測場景
針對生產集羣的全鏈路壓測，常見的案例就是雙11電商大促。生產全鏈路壓測模型較多，一般有如下幾種：
- 梯度加壓：爲了探測集羣模式下系統的最大吞吐量（避免壓垮服務，造成事故）；
- 固定併發：驗證系統長期處於負載下的穩定性；
- 脈衝併發：探測系統的健壯性、驗證限流熔斷等服務保護措施的正確性&可用性；
- 超賣驗證：對電商業務來說，主要針對一些限時搶購&秒殺的場景（一般這種場景，會涉及到分佈式鎖、緩存、數據一致性等技術點；玩不好的話，容易造成客訴、資損、甚至服務異常宕機！）；
構建流量模型
下面是之前我實際工作中一次雙11大促時的流量模型構建案例，僅供參考。
業務目標：雙11當天，預估平均客單價爲500，單日GMV爲10億，那麼支付訂單量爲10億/500=200W；
技術指標：
- 假設日常支付訂單量爲50W，支付轉化率爲40%，訂單支付QPS峯值爲200。預估大促時的支付轉化率爲60%，則可得：大促峯值訂單支付QPS爲（200/40%）*60%*（200W/50W）=1200QPS。爲了留有一定冗餘空間，上浮30%，即訂單支付的QPS預估爲1500；
- 電商的導購下單支付鏈路爲：首頁→商品詳情→創建訂單→訂單支付→支付成功，這是類似漏斗的一個轉化邏輯。假設首頁→商品詳情轉化率爲40%，商品詳情→創建訂單轉化率爲40%，創建訂單→訂單支付轉化率爲40%，那麼可得：創建訂單QPS爲1500/40%=3750，商品詳情QPS爲3750/40%=9375，首頁QPS爲9375/40%=23437；
- 按照核心鏈路之間的依賴調用關係，藉助trace追蹤，可得到大促期間所有核心應用及核心鏈路的QPS數值。
建議評估後流量模型後，結合業務場景和服務間的調用關係，繪製成一個流量模型圖，這樣會更直觀，便於工作開展。
數據模型
瞭解了業務模型和流量模型後，數據模型就很好理解了。
以上圖爲例，電商下單業務在構建數據模型時，要根據壓測時常、壓測次數和壓測場景，準備不同類型的數據。
在準備數據時，還要考慮數據的有效性、數據量級、數據的組合邏輯關係以及數據是否符合生產環境的數據分佈等情況。
如果測試過程中採用的數據不準確，那測試結果往往出現較大偏差。關於測試數據模型構建，可參考如下幾點：
|
數據信息 |
說明 |
|
限制條件 |
用戶操作權限、數據引用次數、數據過期設定（次數、絕對時間） |
|
數據量 |
實際生產環境的數據量爲多少，在性能測試環境如何等量代換 |
|
數據類型 |
基礎數據、熱點數據、緩存數據、特殊數據 |
|
數據特點 |
是否可以複用、是否具有唯一性、自增、加密、拼接、轉義等 |
|
準備方式 |
copy真實環境數據、預埋鋪底數據、脫敏生成數據 |
基礎數據
也稱爲鋪底數據，鋪底數據目的是與線上保持一致（至少數量分佈一致），再結合線上增長率，確認預埋數據量級及預埋方式。
涉及到壓測時需要校驗的數據，需要在鋪底的時候就要精細化的設計，包括數據大小、數量、分佈。
熱點數據
需要了解被測接口的實現邏輯，確認以下信息：
- 是否有熱點數據相關的操作：比如說所有用戶秒殺同一件商品；
- 不同類型數據處理邏輯有差異時，需通過測試數據多樣化提高性能測試代碼覆蓋率；
緩存數據
要確認是否有緩存，緩存大小。
秒殺搶購相關數據，一般來說都是進行隊列處理，將該類型數據放入緩存中進行處理來應對高併發。
再比如用戶登錄所需的token等數據，在壓測時，可以提前將構造好的數據預熱到緩存，避免壓測時用戶服務成爲瓶頸。
構建數據模型
構建數據模型的目的，最直觀的就是壓測時候的測試數據參數化。一般構建步驟如下：
- 構建業務模型；
- 構建流量模型(壓測模型)；
- 羅列出業務和流量模型所需要的測試數據以及對應關係；
- 將準備好的參數化數據從數據庫取出來生成對應的不同的參數化數據文件；
- 在壓測腳本中設置對應的數據匹配關係，保證業務模型、流量模型和數據模型匹配，模擬生產真實場景；