在性能測試過程中，性能測試場景如何設計？

在性能測試過程中，在測試資料、測試腳本設計、測試環境準備之後，還需要進行一個重要的工作：性能測試場景設計。那如何設計性能測試場景呢？什麼樣的性能測試場景是有效的呢？

随着類似雲服務、容器等這類技術的成熟，一個系統越來越大，分析難度越來越大，監測名額越來越多，那麼如何用最少的性能測試場景，擷取最有效的分析資料呢？

性能測試需求方

一個系統為什麼要做性能測試呢？肯定有需求驅動它，那麼這個需求方有哪些人呢？這些人關注系統的哪些方面呢？

如果是業務人員：他們常用的業務場景是哪些呢？他們不常用的業務場景有哪些？他們最大忍受系統響應是多少時間？最好的系統響應是多少時間？

如果是運維人員：系統部署耗時是多少？系統極限狀态下CPU與記憶體使用率是多少？當記憶體或CPU達到什麼數值值，需要重點關注呢？

如果是開發人員：不同業務的TPS值是多少呢？滿足了他們的預期嗎？

上述隻列出了常用的三個角色，這種角色可能有多種，隻有了調研的足夠充分，才能確定使用者關注的場景不被遺漏。

性能測試場景設計

目前大多數公司都是業務驅動的，那業務人員的需求，屬于核心需求，需要重點關注。這部分需求屬于性能測試場景的主要關注點。在做這部分性能測試場景設計主要由如下幾種測試類型：

• 基準測試：目前系統已有使用者、已有資料量、指定的業務操作配比。比如，論壇系統，目前系統通常線上人數在100人，大約60人浏覽文章，40人編寫文章。比如如下的一個場景：

使用者數	浏覽文章人數	編寫文章人數	目前系統資料量
100	60	40	100萬

目前系統這裡需要基于系統了解，建構測試資料模型。該模型要貼合目前測試場景。

• 壓力測試：基于基準測試場景，增加使用者數。基于基準測試場景，該場景主要是擷取系統在常用業務配比，随着使用者增加，系統的各項名額是否符合使用者需求、最大負載使用者數是多少、最大負載時系統的CPU、記憶體使用率是多少。與此同時，通過使用者與響應時間圖，可以擷取到目前系統瓶頸。當随着使用者數增加時，響應時間波動比較大而不發生比較大的波動。找到那個拐點，系統使用者數，該使用者數用于後續穩定性測試。比如，論壇系統，目前系統通常線上人數在100人，大約60人浏覽文章，40人編寫文章。比如如下的一個場景：

使用者數	浏覽文章人數	編寫文章人數	目前系統資料量
100	60	40	100萬
200	120	80	100萬
300	180	120	100萬

這裡資料模型保持不變，通過調整使用者數，來觀察系統監測名額。一般影響系統性能名額的有多個方面，當某個性能測試場景，性能測試資料存在異常時，再去進行分析定位。先發現問題，在定位問題。

• 穩定測試：基于壓力測試，擷取的比較合理的使用者數，使用者數設定為該值，讓系統長時間跑，觀察系統的監測名額。比如數，基于壓力測試，得出的響應時間出現拐點的使用者數為200，那壓力測試的場景可以設定為：

使用者數	浏覽文章人數	持續運作時間	編寫文章人數	目前系統資料量
200	120	7小時	80

• 常用業務配比、正常線上人數、正常資料模型
• 常用業務配比、正常線上人數的幾何倍、正常資料模型
• 常用業務配比、正常線上人數、調整資料模型(如數量增加幾何倍)
• 常用業務配比、正常線上人數的幾何倍、調整資料模型(如數量增加幾何倍)