通過獲取生產日志、參考相似系統等方式能夠得到具體交易(事務)數量的被測應用程序，以TPS為負載目標是直接也最準確的。但要注意，若以TPS為目標，則前端配置的并發數量就不再代表并發人數，而是并發提交事務的數量。TPS和TRT的計算關系將在下面詳述。
TRT
TRT指TPS穩定時(不一定是最大時)的平均事務響應時間，不關注個別事務，它和TPS關系緊密，隨TPS的變化而變化。當負載增加時TRT會逐漸增大，直至事務阻塞，交易超時。
TPS×TRT =并發提交事務的數量。如果以TPS=20為目標，且此時TRT=2秒，則并發提交事務的數量=20×2=40筆。如果1個用戶單位時間內提交1筆事務，則可等于有40個并發用戶數量。
設定好目標TPS后要同時兼顧TRT的表現，若TRT明顯超出業務要求，即使達到負載目標也是無效的。TRT無固定的好壞標準，一般來說對OLTP的聯機應用，從前端提交到返回不應高于3秒，后臺應用程序和數據庫的處理應在1秒左右。對OLAP的在線分析系統或一般網站可遵循3/5/8原則，或更長。
并發用戶數量
通常理解并發用戶數量就是LoadRunner里設置的VUser數量，通過梯度增加VUser，對比TPS變化即可找到被測應用的最大并發用戶。但我卻認為并發用戶數量不等于LoadRunner中設置的VUser數量。受交易響應時間、thinktime、pacing和集合點等因素影響，VUser數量不能直接體現被測應用負載能力。假設同樣10個VUser并發一次，如果A程序的響應時間是1秒，則A程序的TPS=10/1=10。而B程序的響應時間是5秒，則B程序的TPS=10/5=2。同樣在混合場景中用VUser比例體現不同應用的負載比例也是錯誤的，混合場景下由于各交易相互影響，單交易負載時響應快的很可能現在出現阻塞，前端VUser的比例根本無法準確控制后端應用的壓力。
因此我更愿意將“并發用戶數量”和“并發提交事務數量”掛鉤，體現被測應用實際負載：單位時間內n個用戶并發向被測應用提交n個事務請求(n是相同的)。VUser的數量和發起設置只是實現并發用戶數量的一種手段。
在線用戶數量
在線用戶數量與并發用戶數量、TPS、TRT間沒有固定的換算公式，我不提倡10%這樣的粗糙比例，對聯機類應用在線用戶就是每天簽到的柜員數量，對經管類應用就是月末、季末時所有登錄系統的用戶數量。在線用戶數量可以從需求人員或生產管理員處獲得大概數值，但不能通過性能測試倒推出在線數量。
四、 負載目標選擇
1. 有明確交易量的應用
通過上面對各種典型負載指標的分析可以看出，以TPS衡量的事務處理能力是最準確的負載目標。通過生產日志或相似系統的交易量可以算出TPS均值、峰值。根據2/8原則和業務擴展可估算更高的峰值。銀行的聯機類應用屬于典型的有明確交易量的應用系統。
LoadRunner中可以通過設置Run-Time Settings的Pacing為At fixed intervals, every 1 sec，來控制每次迭代執行時間為1秒。如果迭代腳本里只定義一個Transaction，且TRT小于1秒，則VUser數量=并發用戶數量=TPS，可以通過調節VUser數量方便控制負載目標。注意，如果迭代中包含多個Transaction，或TRT隨著TPS目標的增加而變大，則需以TPS目標為基礎，實時調整VUser數量和這里every N sec里的間隔時間。
2. 無明確交易量的應用
無明確交易量的被測應用建議以確定最大事務處理能力為目標。設置Pacing為As soon as the previous iteration ends，刪除thinktime，部署發壓工具和被測應用在同一網段，無網絡瓶頸，讓VUser能對被測應用產生最大負載。弱化VUser數量聽上去的意義，遞增直到達到被測應用的最大事務處理能力或其他性能指標閥值(如成功率或TRT)。新業務和經管類Web應用屬于無明確交易量的應用系統。
3. VUser的意義
盡管建議在確定負載目標時弱化VUser的意義，但測試中還要注意一種情況，如果被測應用有具體的操作用戶數量，如只有簽到或登錄的用戶才能提交交易，則VUser的數量不能高于實際注冊用戶數量。就按照最大用戶數量加壓，以需求要求的TRT為目標調優被測應用，盡量提高TPS。
上面對性能測試中負載目標的探討和建議只是我個人的觀點，希望大家能在制定策略時多問一些為什么，多論證下目標是否合理，而不是人云亦云。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
