性能測試過程中，首先應該設計測試場景，模擬真實業務發生的情境，然后是針對場景設計腳本。為了真實的反映被測對象可能存在的性能問題，需要盡可能模擬被測對象可能發生瓶頸的業務場景。測試需求分析過程中已經確定了需要測試的業務類型，在此，則需要設計針對每種或綜合業務的測試場景。
一、應用性能測試場景的設計
在了解了相關背景之后，我們開始進入正題。性能場景的設計主要包括：業務場景建模、測試數據准備、監控指標確認三個關鍵步驟。下面我們用實戰的方式說明每個步驟的常見做法。
1.1.業務場景建模
確定壓測場景范圍：
人的行為是不可預測的，在性能測試中模擬每個用戶可能的操作場景基本上是不可能實現的。一般情況下我們必須要關注的性能場景包括但不限於：
- 高頻使用的場景
- 關鍵的業務場景
- 最耗性能的場景
- 曾經出現過問題的場景
- ……
在測試具有大量新功能的業務時，往往需要與業務方一起確認預期內有哪些功能點可能會被高頻使用，需要與研發人員確認哪些功能雖然使用頻率不高，但是存在性能隱患、容易引起雪崩效應；在測試已經上線的功能時，還可以通過業務監控、系統日志來分析現有用戶的行為模式，得到更加逼近真實用戶行為的業務場景。
業務場景的操作路徑：
業務場景的操作路徑可以借助一些可視化的工具來描述，這部分工作相對比較簡單，不再詳細深入。我們詳細說明一下比較常見的延時策略。
思考時間：
思考時間模擬的是用戶在等待響應、閱讀頁面內容、表單填寫等延遲操作的場景。每個人的閱讀速度、輸入速度都存在非常大的差異，決定了每個人的思考時間也是不一樣的，在性能測試配置中有常見的四種延時模型覆蓋了絕大部分的延時場景：
- 固定時間：顧名思義，設置一個固定的思考時間。
- 均勻分布：均勻分布在范圍的上限和下限之間的隨機數。
- 正態分布：根據中心極限定理，如果一個事物受到多種因素的影響，不管每個因素本身是什么分布，它們加總后，結果的平均值就是正態分布。
- 負指數分布：該模型將延遲時間的頻率強烈地偏向該范圍的一端。
- 雙駝峰正態分布：雙峰駝正態分布可以模擬第一次訪問時把頁面說明整個仔細的閱讀一遍，但下次訪問時直接掃過頁面，點擊頁面深處的操作鏈接。
我們通常可以通過以下方式對思考時間進行建模：
- 如果是已上線系統，可以從線上日志統計分析出來平均值以及標准方差
- 沒有線上日志，可以從內部人員的使用模式中收集響應的數據
- 可以計算自己和同事訪問的時候，在不同頁面停留的時間
- 如果沒有更好的來源，也可以從第三方統計數據獲取延時數據
集合點
集合點模擬的是大量的用戶在同一時刻一起做同樣的操作（加購、付款等），集合的方式通常包括按時間集合和按量集合。一般只有具備秒殺特性的業務才會使用到。雖然直接在壓測工具中設置巨大的起步量級看似也能模擬秒殺的行為，但是壓測工具一般都存在一個不太穩定的預熱的過程，因此不推薦超高的起步量級模擬秒殺。
確定場景的施壓參數
施壓模式：
常見的施壓模式有以下兩種， 並發模式與 RPS 模式沒有優劣，各自有各自適用的場景。
1、並發模式（虛擬用戶模式）
並發是指虛擬並發用戶數，從業務角度，也可以理解為同時在線的用戶數。如果需要從客戶端的角度出發，摸底業務系統各節點能同時承載的在線用戶數，可以使用該模式設置目標並發。
2、RPS 模式（吞吐量模式）
RPS（Requests Per Second）是指每秒請求數。RPS 模式即“吞吐量模式”，通過設置每秒發出的請求數，從服務端的角度出發，直接衡量系統的吞吐能力，免去並發到 RPS 的繁瑣轉化，一步到位。
目標量級：
目標量級往往來自於對項目計划、目標，業務方要求，或者是技術文檔的量化。
場景的負載占比：
已上線應用，盡量使用線上的日志、埋點數據結合業務運營的預期目標確保分配比例盡可能的符合實際情況；新上線的應用一般依靠事前預期分配虛擬用戶，在測試的執行過程中可以逐步的調整。
1.2.測試數據准備
高質量的測試數據應當能真實的反映用戶的使用場景。我們一般會選擇以線上真實數據作為數據源，經過采樣、過濾、脫敏，作為性能測試的測試數據。低質量的測試數據也許能夠測試出一些問題，但是更大的可能性是無效的測試結果。壓測數據至少包括基礎數據和運行時數據兩種。
基礎數據，主要是應用系統存儲的元數據，比如用戶信息、產品信息、商品信息等；基礎數據的數據量、數據分布應當與線上運行的數據量相當，否則容易引起無效測試。
運行時數據，主要是虛擬用戶操作過程中需要使用的表單數據，比如虛擬用戶的用戶名、密碼、搜索關鍵詞等；運行數據的逼真度也是至關重要的。
1.3.確認監控指標
在性能測試執行過程中，往往需要實時觀察各項指標是否正常，包括客戶端指標、應用服務器、數據庫、中間件、網絡入口等各方面的指標。更重要的是，監控的過程是發現系統瓶頸的過程，監控數據是性能基線管理、容量規划甚至是高可用架構的重要基礎。我們通常需要關注的監控指標包括：
- 業務接口指標，響應時間、RPS、成功率等；
- 網絡指標，數據吞吐量、數據錯誤率等；
- 服務器指標，連接數、CPU、內存、I/O、磁盤等；
- ……
最理想的狀態是，這些監控指標能夠與性能測試工具集成，在一個操作界面上展示各個維度的監控數據，並能夠基於策略來智能化、自動化識別指標異常。這對快速、准確的定位壓測過程中可能出現的各種問題是至關重要的。
二、應用性能測試場景設計的實踐
DISCUZ 是一個使用PHP語言開發的論壇網站
業務場景建模
在這次的實戰演示中，我們通過實際操作體驗的方式來獲取所有的業務場景、操作路徑、思考時間。我們先用文字的方式來描述場景和操作路徑。
- 用戶登錄，訪問首頁->登錄操作
- 發帖流程1，訪問首頁->用戶登錄->進入版塊->編寫帖子->思考(3s-5s)->提交帖子->用戶退出->退出后頁面
- 發帖流程2，訪問首頁->進入版塊->用戶登錄->發表帖子->思考(3s-5s)->提交帖子->用戶登錄->登錄后首頁
- 發表帖子3，訪問首頁->進入注冊主頁->提交注冊>思考(3s-5s)->自動登錄->跳轉到主頁->進入版塊->發表帖子->思考(3s-5s)->提交帖子->用戶登錄->登錄后首頁
我們的目的是做壓力測試。我們選擇 RPS 模式，梯度遞增，漏斗模型；
- 與並發模式相比，RPS 模式可以實現更加精准的流量控制；常見的限流設施都是基於TPS設置閾值的；因此我們首選 RPS 模式。
- 我們使用手動遞增的方式，逐步的逼近系統極限。
- 在真實的業務中，用戶會由於各種原因（網絡、不想發帖、發帖失敗等）而放棄發帖，在此我們構造一個漏斗模型，我們假定100個人查看詳情之后有30個人加入登錄，最終10個人發帖成功；在真實的場景中我們可以從線上用戶行為中采集到這些信息。
假定用戶登錄容量足夠，不是這次壓力測試的重點業務。我們基於線上日志和產品運營分析得出以下結論：
- 使用發帖流程1的用戶占比10%
- 使用發帖流程2的用戶占比60%
- 使用發帖流程3的用戶占比為30%