本文是《Performance Test Together》（簡稱PTT）系列專題分享的第5期，該專題将從性能壓測的設計、實作、執行、監控、問題定位和分析、應用場景等多個緯度對性能壓測的全過程進行拆解，以幫助大家建構完整的性能壓測的理論體系，并提供有例可依的實戰。
該系列專題分享由阿裡巴巴 PTS 團隊出品，歡迎在文末處加入性能壓測交流群，參與該系列的線上分享。
第1期：
《壓測環境的設計和搭建》 第2期： 《性能壓測工具選型對比》 第3期： 《阿裡巴巴在開源壓測工具 JMeter 上的實踐和優化》 第4期： 《并發模式與 RPS 模式之争，性能壓測領域的星球大戰》 本文将介紹應用性能測試場景的設計和實作，旨在借助阿裡巴巴在這方面的沉澱幫助您更準确的找到性能瓶頸，文章将圍繞以下：- 性能測試的常見分類
- 應用性能測試場景的設計
- 應用性能測試場景的設計實踐
- 應用性能測試場景的實作
負載測試：
一種驗證性測試，它的目的是驗證預設負載條件下的性能表現是否達到性能目标（可用性、并發數/RPS、響應時間等），在達到性能目标之後不會繼續增加負載。
穩定性測試：
負載測試的一個子集，側重于發現、驗證隻有經過長時間的運作才會暴露的問題。比如記憶體洩漏、FGC 等。
壓力測試：
一種破壞性測試，嘗試探測應用或者基礎設施的極限能力。是以壓力測試過程中會一直增加負載直到部分性能名額不再符合性能預期。壓力測試能發現僅在高負載條件下出現的同步問題、競争條件、記憶體洩漏等。通過壓力測試我們還可以确定應用服務在什麼條件下會變得不可用，不可用的現象，以及可以通過哪些監控名額來監控即将發生的不可用，壓測結果通常可以為限流等管控系統提供資料支撐。
容量測試：
往往與容量規劃一起進行，是在保證使用者體驗不受影響（穩定性）的前提下，使有限的資源的使用率最大化（成本）。也可以用它來預估未來使用者量增長到某個量級的情況下，需要多少資源（例如處理器、記憶體、磁盤、網絡帶寬）來支援。
在了解了相關背景之後，我們開始進入正題。性能場景的設計主要包括：業務場景模組化、測試資料準備、監控名額确認三個關鍵步驟。下面我們用實戰的方式說明每個步驟的常見做法。
業務場景模組化
确定壓測場景範圍：
人類是不可預測的，在性能測試中模拟每個使用者可能的操作場景基本上是不可能實作的。一般情況下我們必須要關注的性能場景包括但不限于：
- 高頻使用的場景
- 關鍵的業務場景
- 最耗性能的場景
- 曾經出現過問題的場景
- ……
在測試具有大量新功能的業務時，往往需要與業務方一起确認預期内有哪些功能點可能會被高頻使用，需要與研發人員确認哪些功能雖然使用頻率不高，但是存在性能隐患、容易引起雪崩效應；在測試已經上線的功能時，還可以通過業務監控、系統日志來分析現有使用者的行為模式，得到更加逼近真實使用者行為的業務場景。
業務場景的操作路徑：
業務場景的操作路徑可以借助一些可視化的工具來描述，這部分工作相對比較簡單，不再詳細深入。我們詳細說明一下比較常見的延時政策。
思考時間：
思考時間模拟的是使用者在等待響應、閱讀頁面内容、表單填寫等延遲操作的場景。每個人的閱讀速度、輸入速度都存在非常大的差異，決定了每個人的思考時間也是不一樣的，在性能測試配置中有常見的四種延時模型覆寫了絕大部分的延時場景：
- 固定時間：顧名思義，設定一個固定的思考時間。
- 均勻分布：均勻分布在範圍的上限和下限之間的随機數。
- 正态分布：根據中心極限定理，如果一個事物受到多種因素的影響，不管每個因素本身是什麼分布，它們加總後，結果的平均值就是正态分布。
- 負指數分布：該模型将延遲時間的頻率強烈地偏向該範圍的一端。
- 雙駝峰正态分布：雙峰駝正态分布可以模拟第一次通路時把頁面說明整個仔細的閱讀一遍，但下次通路時直接掃過頁面，點選頁面深處的操作連結。
我們通常可以通過以下方式對思考時間進行模組化：
- 如果是已上線系統，可以從線上日志統計分析出來平均值以及标準方差
- 沒有線上日志，可以從内部人員的使用模式中收集響應的資料
- 可以計算自己和同僚通路的時候，在不同頁面停留的時間
- 如果沒有更好的來源，也可以從第三方統計資料擷取延時資料
集合點
集合點模拟的是大量的使用者在同一時刻一起做同樣的操作（加購、付款等），集合的方式通常包括按時間集合和按量集合。一般隻有具備秒殺特性的業務才會使用到。雖然直接在壓測工具中設定巨大的起步量級看似也能模拟秒殺的行為，但是壓測工具一般都存在一個不太穩定的預熱的過程，是以不推薦超高的起步量級模拟秒殺。
确定場景的施壓參數
施壓模式：
常見的施壓模式有以下兩種， 并發模式與 RPS 模式沒有優劣，各自有各自适用的場景。
1、并發模式（虛拟使用者模式）
并發是指虛拟并發使用者數，從業務角度，也可以了解為同時線上的使用者數。如果需要從用戶端的角度出發，摸底業務系統各節點能同時承載的線上使用者數，可以使用該模式設定目标并發。
2、RPS 模式（吞吐量模式）
RPS（Requests Per Second）是指每秒請求數。RPS 模式即“吞吐量模式”，通過設定每秒發出的請求數，從服務端的角度出發，直接衡量系統的吞吐能力，免去并發到 RPS 的繁瑣轉化，一步到位。
目标量級：
目标量級往往來自于對項目計劃、目标，業務方要求，或者是技術文檔的量化。
場景的負載占比：
已上線應用，盡量使用線上的日志、埋點資料結合業務營運的預期目标確定配置設定比例盡可能的符合實際情況；新上線的應用一般依靠事前預期配置設定虛拟使用者，在測試的執行過程中可以逐漸的調整。
測試資料準備
高品質的測試資料應當能真實的反映使用者的使用場景。我們一般會選擇以線上真實資料作為資料源，經過采樣、過濾、脫敏，作為性能測試的測試資料。低品質的測試資料也許能夠測試出一些問題，但是更大的可能性是無效的測試結果。壓測資料至少包括基礎資料和運作時資料兩種。
基礎資料，主要是應用系統存儲的中繼資料，比如使用者資訊、産品資訊、商品資訊等；基礎資料的資料量、資料分布應當與線上運作的資料量相當，否則容易引起無效測試。
運作時資料，主要是虛拟使用者操作過程中需要使用的表單資料，比如虛拟使用者的使用者名、密碼、搜尋關鍵詞等；運作資料的逼真度也是至關重要的。
确認監控名額
在性能測試執行過程中，往往需要實時觀察各項名額是否正常，包括用戶端名額、應用伺服器、資料庫、中間件、網絡入口等各方面的名額。更重要的是，監控的過程是發現系統瓶頸的過程，監控資料是性能基線管理、容量規劃甚至是高可用架構的重要基礎。我們通常需要關注的監控名額包括：
- 業務接口名額，響應時間、RPS、成功率等；
- 網絡名額，資料吞吐量、資料錯誤率等；
- 伺服器名額，連接配接數、CPU、記憶體、I/O、磁盤等；
最理想的狀态是，這些監控名額能夠與性能測試工具內建，在一個操作界面上展示各個次元的監控資料，并能夠基于政策來智能化、自動化識别名額異常。這對快速、準确的定位壓測過程中可能出現的各種問題是至關重要的。
應用性能測試場景設計的實踐
JPetStore 是一個開源的簡單的Java語言開發的線上寵物商店，可以從 GitHub 擷取到源碼。為了友善示範，我們用阿裡雲 EDAS 部署了一套 JPetStore 寵物購物網站。
在這次的實戰示範中，我們通過實際操作體驗的方式來擷取所有的業務場景、操作路徑、思考時間。我們先用文字的方式來描述場景和操作路徑。
- 使用者登入，通路首頁->進登入頁->登入操作
- 購買流程1，通路首頁->選擇産品大類->進入産品清單->進入型号清單->檢視型号詳情->加購物車->思考(3s-5s)->送出訂單->确認訂單
- 購買流程2，通路首頁->搜尋産品->進入産品清單->進入型号清單->檢視型号詳情>加購物車->思考(3s-5s)->送出訂單->确認訂單
- 購買流程3，通路首頁->搜尋商品->進入産品清單->進入型号清單->加購物車->思考(3s-5s)->送出訂單->确認訂單
我們的目的是做壓力測試。我們選擇 RPS 模式，梯度遞增，漏鬥模型；
- 與并發模式相比，RPS 模式可以實作更加精準的流量控制；常見的限流設施都是基于TPS設定門檻值的；是以我們首選 RPS 模式。
- 我們使用手動遞增的方式，逐漸的逼近系統極限。
- 在真實的業務中，使用者會由于各種原因（網絡、庫存、不喜歡、付款失敗等）而放棄購買，在此我們構造一個漏鬥模型，我們假定100個人檢視詳情之後有30個人加入了購物車，15個人送出訂單，最終10個人确認訂單，購買成功；在真實的場景中我們可以從線上使用者行為中采集到這些資訊。
假定使用者登入容量足夠，不是這次壓力測試的重點業務。我們基于線上日志和産品營運分析得出以下結論：
- 使用購買流程1的使用者占比10%
- 使用購買流程2的使用者占比60%
- 使用購買流程3的使用者占比為30%
最終，我們得到的業務模型如下圖所示：
因為該應用專為測試而生，不用考慮資料污染，我們免去采樣、過濾、脫敏步驟，直接使用線上的基礎資料作為壓測的基礎資料。基礎資料的結構如下圖所示，當然真實系統的基礎資料，比這個複雜的多：
常見的壓測工具都支援 CSV 格式（可以簡單了解為逗号分隔值，但是實際上更加複雜）的資料源。我們構造的使用者登入的運作時資料格式如下圖所示：
依據我們的應用部署架構圖，本次壓測過程中需要關注 SLB、ECS、RDS 的基礎名額（雲監控）和壓測引擎提供的 RPS、RT、成功率等接口名額。各項監控名額均有平台可以支撐，在此不做贅述。
性能場景的實作主要包括：壓測工具選型、性能場景配置、施壓參數配置三個關鍵步驟，某些壓測工具還提供了監控內建、SLA 等功能，我們稍後也會做一些介紹。
壓測工具選型
工欲善其事必先利其器，選擇一款高效的壓測工具往往能達到事半功倍的效果。然而壓測工具選型已經是一個老生常談的話題了，今天我們換個角度，從場景實作的角度再對比一下，希望對大家做選型有所幫助，如果有哪些方面不太完善的地方，請在文末留言讨論。對比詳情，點選
這裡。
下面我們示範怎麼在阿裡雲 PTS 上配置我們設計的壓力測試場景，由于操作都比較簡單，僅截取關鍵配置用于示範，大家如果有不明白的地方可以留言讨論或者進入我們的釘釘群中讨論。
壓測場景配置
1、高仿真場景編排,完美再現使用者行為
壓測接口錄入：
錄入接口資訊是一件非常繁瑣的事情，接口多，參數多經常容易出錯。今天我們用PTS提供的雲端錄制器來示範怎麼快速的梳理和錄入所有涉及到的接口。雲端錄制器的原理是在本地電腦或者手機裝置配置網絡代理，雲端錄制器就能擷取到所有網絡請求的資訊。具體的錄制步驟如下：
- 配置網絡代理。請參考 PTS 錄制器操作文檔即可，這裡不再贅述。
- 在浏覽器或者 App 中執行業務操作。強烈建議使用域名過濾功能，可以避免錄制到幹擾請求；每次執行業務操作前先建立一個步驟并備注上業務名稱，而不要在所有操作錄制完成之後在梳理分類（想象一下從幾百個請求中撈出來哪些是登陸相關的請求吧）。
- 選擇錄制到的接口資訊，導入一個新場景。仍然請參考 PTS 錄制器操作文檔即可，這裡不再贅述。
阿裡巴巴在應用性能測試場景設計和實作上的實踐
表單資料的參數化處理
這個步驟實際上是做場景與壓測資料的分離。PTS 支援常見的 CSV 格式檔案、包含一個 CSV 檔案的 ZIP 檔案作為場景的資料源。這裡示範一下如何使用使用者名和密碼進行虛拟使用者的登入，其他參數的設定與此類似，不在贅述。
第一步，将我們準備的測試資料上傳到 PTS，并且給每一列設定變量名。
第二步，編輯登入接口，将 username 變量的值和 password 變量的值設定為檔案參數清單中的變量名。
接口間的參數關聯處理
這個步驟的主要作用是從前置接口的傳回内容中提取出後續接口需要的變量，傳遞給後續接口使用。在場景編排過程中經常會碰到很複雜的關聯方式，比如加密、字元串截取等，可以使用系統函數、資料指令進行加工處理，詳見 PTS 操作文檔。我們示範一下怎麼實作從産品清單中随機選擇一個産品進行購買。
第一步，使用正規表達式從産品清單接口的響應中随機提取一個産品 ID ，作為該接口的出參。
第二步，在型号清單接口中，修改參數 productId 的值為上一步導出的變量
第三步，将 itemId 也用類似的方式配置參數關聯，就實作了虛拟使用者随機購買商品的需求。操作過程類似，不在贅述了。
檢查接口調用是否成功
檢查點的作用是保證接口調用是成功的，配置了檢查點的接口有業務成功率的監控名額，是發現服務端問題的重要管道之一。PTS 支援多種複雜的檢查點，具體配置請參考 PTS 操作文檔。下面示範怎麼給産品清單接口添加檢查點，檢查傳回的産品 ID 是否存在。
2、靈活的施壓配置,想怎麼壓就怎麼壓
施壓參數配置
施壓參數主要包括壓力來源、壓測模式、加壓方式、虛拟使用者配置設定等，根據之前設計的場景模型，我們直接配置上去即可。
第一步，配置目标量級、壓力來源、壓測時長、IP 擴充等資訊
第二步，配置各個業務目标量級的配置設定占比，這也是漏鬥模型的關鍵
流量來源定制
PTS 支援 IP 數量定制、國内公網流量的營運商和地域定制，如果有更加複雜的流量定制需求，還可以申請獨占資源池，全球流量定制都不是問題。
3、完整實時監控,瓶頸無所遁形
監控內建&SLA監控
PTS 支援添加雲監控，用于檢視各項名額，更好地保證測試前提，記錄相關資料，輸出最終結果。如果您使用了阿裡雲基礎服務（ECS、RDS、SLB），均可通過添加監控的方式，在壓測及報告中便捷地檢視相應的監控資料。若未使用阿裡雲基礎服務，亦可以使用PTS進行施壓。
結合我們之前的架構圖，我們給 ECS、SLB、RDS 配置雲監控內建，利用 PTS 的監控大盤，友善的監控所有監控名額。
服務等級定義 SLA（Service Level Agreement）是判定服務是否異常的重要依據。壓測過程中，通過監控核心服務狀态的 SLA 名額資料，可以更直覺地了解被壓測業務的狀态。PTS 支援定義常見的的、關鍵的 SLA：
- 業務品質相關名額，RT、RPS、成功率；
- ECS基礎監控名額，CPU使用率、記憶體使用率、load5；
- RDS基礎監控名額，CPU使用率、連接配接使用率；
- SLB基礎監控名額，丢棄連接配接數、後端異常ECS數；
我們給送出訂單、确認訂單、商品詳情、加購物車接口配置 SLA 監控，以及時的發現問題。
總結
本文介紹了性能壓測場景設計和實作的常用方法和流程，針對目前幾款閱聽人相對較多的性能壓測工具給出了場景實作相關的功能對比。與實際需求比對的方法和工具才是最佳實踐，大家可以針對不同需求選取最合适的性能壓測工具來實施性能測試。
本文作者：蔣聖富，花名章進，阿裡雲 PTS 技術專家，2011年加入阿裡巴巴，目前從事性能測試和高可用架構領域的相關工作。