本文將圍繞性能測試常見分類、業務場景建模、測試數據準備、監控指標確認介紹性能測試場景的設計。
性能測試常見分類
我們知道，軟體總是運行在一定的環境下 ，這種環境包括支撐軟體運行的軟硬體環境和影響軟體運行的外部條件。為了讓客戶使用軟體系統感到滿意，必須確保系統運行良好，達到高安全、高可靠和高性能。
其中，系統是否具有高性能的運行特徵，不僅取決於系統本身的設計和程序算法，而且取決於系統的運行環境（硬體環境）。一般系統的運行環境會受以下因素影響:
- 系統架構：如分布式伺服器集群還是集中式主機系統等。
- 硬體配置：如伺服器的CPU、內存、硬碟等配置。
- 網絡：如網絡帶寬，跨網段、隔離等。
- 支撐軟體的選定 ：如選定不同的資料庫管理系統( Oracle、MySQL等 )和WEB應用伺服器( Tomcat Glassish、Jboss、WebLogic等 )，對應用系統的性能都有影響。
- 外部負載：同時有多少個用戶連接、用戶上載文件大小、資料庫中的記錄數等都會對系統的性能有影響。一般來說 ，系統負載變大，系統的性能會降低。
從上面可以看出，使系統的性能達到一個最好的狀態，不僅通過對處在特定環境下的系統進行測試以完成相關的驗證，而且往往要根據測試的結果，對系統的設計、代碼和配置等進行調整，提高系統的性能。 許多時候，系統性能的改善是測試調整、再測試再調整、一個持續改進的過程，這就是我們經常說的性能調優。
在了解了這樣一個背景之後 ，就比較容易理解性能測試中常見的分類。從測試的目的出發、從用戶的需求出發，就比較容易區分性能測試、負載測試、穩定性測試、壓力測試。
性能測試、負載測試、穩定性測試、壓力測試的測試目的不同，但其手段和方法在一定程度上比較相似，通常會使用相同的測試環境和測試工具，而且都會監控系統所占用資源的情況以及其它相應的性能指標，這也是造成我們容易產生概念混淆的主要原因。
性能測試類型
廣義上，性能測試指的是以下幾種性能測試類型：
- 性能測試
- 負載測試
- 穩定性測試
- 壓力測試
一般系統的性能指標
- 響應時間：指系統對請求作出響應的時間，即系統為其服務所耗費的時間。
- 吞吐率（TPS/RPS）：指系統在單位時間內處理請求的數量，簡單講就是系統在每單位時間內能處理多少個事務/請求/單位數據等，吞吐率也指單位時間內網絡上傳輸的數據量。當壓力加大時，點擊率/每秒通過事務數（TPS）曲線如果變化緩慢或者有平坦的趨勢，很有可能是伺服器出現瓶頸。
- 吞吐量：指在一次性能測試過程中網絡上傳輸的數據量的總和，也指在單次業務中，客戶端與伺服器端進行的數據交互總量。
- 資源使用率：常見的資源包括，CPU占用率、內存使用率、磁碟I/O、網絡I/O。
- 點擊率：指在單位時間內，用戶向Web伺服器提交的HTTP請求數。通過它可以評估虛擬用戶產生的負載量，將其與「平均響應時間」圖比較，可以查看點擊次數對事務性能產生的影響，可以判斷系統是否穩定。
- 並發用戶數：並發用戶數是指系統可以同時承載的正常使用系統功能的用戶的數量，並發用戶數用來度量伺服器並發容量和同步協調能力。
我們取其中某幾個性能指標，舉一個例子。我們先假設一個場景：XX查詢系統，其中一項產品規格（性能指標）為300用戶並發查詢，頁面首屏結果請求響應時間不超過3秒。
圖中 A、B、C、D四點表示：
- A： 產品規格（性能指標）
- B ：高於性能指標，接近系統資源臨界點
- C ：高於性能指標，達到最大，出現性能拐點（可理解為最大並發用戶數）
- D ：遠高於性能指標，系統崩潰
性能測試（狹義）
測試A點的系統性能。
性能測試是為了獲得系統在某種特定的條件下(包括特定的負載條件下)的性能指標數據，實現對系統某項性能指標進行定量、對比測試，主要目的是檢驗系統性能與相關性能標準的符合程度。
負載測試
測試 A點以上到C點系統性能。
負載測試的目標是測試在一定負載情況下系統性能（不關注穩定性，也就是說不關注長時間運行），實際中我們常從比較小的負載開始，逐漸增加模擬用戶的數量（增加負載）， 觀察不同負載下應用程式響應時間、數據吞吐量、系統資源使用率(如CPU、內存)等，直到到系統的某項或多項性能指標達到安全臨界值（如，系統內存已飽和），以發現系統可能存在的性能瓶預、內存泄漏、FGC、不能實時同步等問題(不關注穩定性，也就是說不關注長時間運行。它是測試系統的不同負載情況下的性能指標。）
穩定性測試
測試 A點以上 到 B 點之間
穩定性測試是一般在低於性能值的前提下進行測試的，一般穩定性測試時間持續為 n*24 小時。測試時，我們需要結合用戶實際情況控制測試中的負載量 ，使測試結果更具準確性和可靠性。
壓力測試
測試B 點到D 點之間系統性能。
一種破壞性測試，嘗試探測應用或者基礎設施的極限能力。壓力測試是在高於性能指標負載的前提下（超負載）對系統持續施加壓力進行測試的，查看應用系統在峰值使用情況下操作行為，從而有效地發現系統的某項功能隱惠、系統是否具有良好的容錯能力和可恢復能力。壓力測試能發現僅在高負載條件下出現的同步問題、競爭條件、內存泄漏等。通過壓力測試我們還可以確定應用服務在什麼條件下會變得不可用。
壓力測試分為高負載下的長時間(如24小時以上)的穩定性壓力測試 和 極限負載情況下導致系統崩潰的破壞性壓力測試。
- 穩定性壓力測試：在選定的壓力值下，長時間持續運行。通過這類壓力測試,可以考察各項性能指標是否在指定範圍內，有無內存泄漏、有無功能性故障等。
- 破壞性壓力測試：在穩定性壓力測試中可能會出現些問題 ，如系統性能明顯降低，但很難察露出其真實的原因。通過破壞性不斷加壓的手段(極限負載情況下導致系統崩潰)，往往能快速造成系統的崩潰。
壓力測試的幾點注意：
- 測試時，我們需要注意並不是負載超過了系統的最大處理能力， 系統功能都會失效。例如，OA簽到最多支持500用戶井發登錄，但某時550用戶同時進行登錄時，系統應保證550個用戶中，500用戶是可以正常登錄，而不是所有用戶都無法登錄。
- 用戶的業務負載並不是平均的，可能在極短時間內，出現超過負載的情況，如某寶雙十一。因此不建議用持續超過系統負載的測試方法進行壓力測試，只要負載足夠多，系統總會被搞掛，建議使用突發形態的負載模型。
另外，性能測試的需要注意以下幾點：
- 性能測試場景一定要基於真實環境來模擬，仿真的性能壓測環境，是執行有效性能壓測的前提。
- 性能測試場景一定要基於具體清晰的指標來設計。
- 性能測試，性能過程的監控分析是核心，包含硬體資源監控、應用服務監控、全鏈路監控。
性能測試場景的設計
在了解了相關背景之後，我們來了解一下性能測試場景的設計。性能場景的設計主要包括以下三個步驟：
- 業務場景建模
- 測試數據準備
- 監控指標確認
業務場景建模
首先明確壓測場景範圍。一般情況下我們需要關注的以下性能場景：
- 核心的業務場景
- 高頻的業務場景
- 高耗的業務場景
- 曾出現過問題的業務場景
通常通過需求優先級來確認核心的業務場景，通過對用戶使用日誌分析獲取高頻的業務場景，通過歷史問題明確高耗或者出現過問題的業務場景，這些業務場景是我們需要重點關注的。
然後，分析業務場景的操作軌跡。業務場景的操作軌跡可以用戶日誌分析和埋點，分析用戶使用習慣和用戶操作軌跡，進而得出業務場景的操作軌跡，同時獲取不用場景的用戶負載。對於新上線的應用，一般通過用戶需求和虛擬用戶（測試人員模擬）使用情況來確認業務場景的操作軌跡。
關於業務場景的操作軌跡還需要考慮思考時間、集合點、施壓模式。
關於思考時間的設置，思考時間模擬的是用戶在等待響應、瀏覽頁面、提交表單等延遲操作的場景。正是因為不用用戶的閱讀速度、輸入速度都存在較大的差異，也就決定了每個用戶的思考時間不一樣。性能思考時間常見的的設置思路如下：
- 固定時間：設置一個固定的思考時間。
- 隨機分布：在一定範圍內隨機獲取思考時間。
- 正態分布：在特定條件下，大量統計獨立的隨機變量的平均值的分布趨於正態分布，這就是中心極限定理。中心極限定理的重要意義在於，根據這一定理的結論，其他機率分布可以用正態分布作為近似。
一般，我們可以通過以下方式兩個途徑獲取思考時間設置依據：
- 若系統上線，則直接分析用戶使用日誌獲取思考時間。
- 若系統未上線，通過虛擬用戶（測試人員）模擬使用系統，然後評估虛擬用戶的思考時間。
關於集合點，集合點模擬的是指定用戶在同一時刻一起做同樣的操作（如，雙十一零點支付訂單），一般集合點通過達到指定 時間或 數量的形式觸發。
關於性能測試的 施壓模式，常見的施壓模式有以下兩種， 併發模式與 RPS 模式：
- 併發模式（虛擬用戶模式）：並發是指虛擬並發用戶數，從業務角度，也可以理解為同時在線的用戶數。
- RPS 模式（吞吐量模式）：RPS是指每秒請求數，通過設置每秒發出的請求數，從服務端的角度出發，直接衡量系統的吞吐能力。
測試數據準備
高質量的測試數據應當能真實的反映用戶的使用場景。我們一般會引流線上真實數據，經過採用、過濾、脫敏作為性能測試的測試數據。低質量的測試數據也許能夠測試出一些問題，但是更大的可能性是無效的測試結果。
同時需要注意，測試數據不僅數據的分布、數據的質量要模擬真實數據，數據量級也需要儘可能的真實情況，至少不能像功能測試那樣，僅使用少量的數據進行測試。
確認監控指標
在性能測試執行過程中，往往需要實時觀察各項指標是否正常，包括客戶端指標、應用伺服器、資料庫、中間件、網絡入口等各方面的指標。我們通常需要關注的監控指標包括：
- 業務接口指標：響應時間、RPS、成功率、失敗率等。
- 網絡指標：數據吞吐量、數據錯誤率等。
- 伺服器指標：CPU、內存、I/O、磁碟、連接數等。