目前僅限於容量測試場景設計。
場景模型的設計過程其實就是根據預期目標tps和測試模型計算出每乙隻交易的併發使用者數和迭代間隔時間。選擇固定間隔時間方式，詳細方法請看7.3節中的pacing選項的說明，不同的預期目標tps將會得到不同的併發使用者數和間隔時間。
首先，假定乙個總的目標tps，然後通過測試模型中每只交易的交易佔比，計算出每只交易的目標tps，然後預估每只交易目標併發使用者數，但需要滿足兩個原則：
1、保證每只交易至少1個使用者，
2、交易目標併發使用者數與交易目標tps的比值大於參考響應時間（前乙個預期目標場景的art結果）
具體原型請看下面的公式：
其中：「固定間隔時間」即為使用者在每個固定間隔時間內進行傳送請求；推薦均使用固定間隔時間來代替以前新增延時的策略，這個間隔時間在loadrunner controller工具中的表示和體現，請看如下圖示：
採用上述標準流程進行場景設計：
當目標tps與實際測試出的tps出現較大背離時，如果非某只交易影響，則說明拐點出現；否則表明某只交易的目標tps沒有達到其目標tps，可能此交易有問題。
我們通過具體例項來講解，總目標tps=100筆/秒的容量場景模型，如下**：
交易名稱
交易佔比
交易目標tps(筆/秒)
參考響應時間(秒)
目標使用者數
間隔時間
a20%
200.45
100.50
b10%
100.28
30.30c5%
50.36
20.40
d20%
200.22
50.25
e25%
250.56
140.56f8%
80.26
30.38
g12%
120.27
40.33
效能測試場景
執行緒數 需要設定的併發使用者數 併發使用者數 受cpu的主頻 分配的記憶體大小 作業系統 允許開啟檔案數量 開放的埠數量 的影響，一台電腦，大概能支援 1500併發使用者數以內 http協議 ramp up時間 在多長時間內啟動所有的執行緒。注意 只是說明，在第n秒結束時，會產生m個併發使用者數，...
效能測試場景分析設計
效能測試工作多年，經歷大小專案上千個，說起效能測試可能一千個人眼中就有一千個哈姆雷特。有人會說效能測試就是搞個壓測工具壓下就行，有人會說效能測試是瓶頸定位，有人說效能測試是保障大促的測試，有人說效能測試是容量規劃等等。其實這都是片面的不完整的，效能測試是乙個複雜的系統工程，真正做一次完整的效能測試要...
測試場景設計 杯子測試
一種 測試專案 杯子 1.需求測試 檢視杯子使用說明書 2.介面測試 檢視杯子外觀 3.功能度 用水杯裝水看漏不漏 水能不能被喝到 4.安全性 杯子有沒有毒或細菌，檢查水杯被破壞後，是否會造成使用者傷害 5.可靠性 杯子從不同高度落下的損壞程度 6.可移植性 杯子再不同的地方 溫度等環境下是否都可以...