阿里巴巴在应用性能测试场景设计和实现上的实践
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/yunqiinsight/article/details/99827709
本文是《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 上配置我們設計的壓力測試場景，由于操作都比較簡單，僅截取關鍵配置用于演示，大家如果有不明白的地方可以留言討論或者進入我們的釘釘群中討論。
下面我們演示怎么在阿里云 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 監控，以及時的發現問題。
總結
本文介紹了性能壓測場景設計和實現的常用方法和流程，針對目前幾款受眾相對較多的性能壓測工具給出了場景實現相關的功能對比。與實際需求匹配的方法和工具才是最佳實踐，大家可以針對不同需求選取最合適的性能壓測工具來實施性能測試。
原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。
————————————————
版權聲明：本文為CSDN博主「阿里云云棲社區」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/yunqiinsight/article/details/99827709
總結
以上是生活随笔為你收集整理的阿里巴巴在应用性能测试场景设计和实现上的实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 安卓手机文件管理器在哪里打开（安卓手机文
- 下一篇： java中的void是什么？有什么作用？