性能測試負載目標探討 軟件測試
一、 前提
近期我跟蹤了2個外協人員參與的性能測試項目，溝通中發現大家在制定測試策略時對如何確定負載目標、計算并發用戶數量等方面有很多不同方法，本文希望能對各種方法進行探討，并根據已有經驗對策略制定方面給出一些自己的建議。本文被測應用以銀行系統為主，壓力發起工具以LoadRunner為例。
二、 術語
l 單位時間：本文中以1秒為單位時間。
l 在線用戶數量：訪問被測應用的用戶數量，但單位時間內用戶不會同時對被測服務器發送請求，產生壓力。
l 并發用戶數量：部分書中分狹義和廣義兩種，狹義指單位時間內同時執行一種操作的用戶數量，廣義指單位時間內同時執行多種不同操作的用戶數量，廣義的并發用戶操作更接近實際業務環境。但本文中的并發用戶數量僅指狹義而言，因為廣義是多種狹義的組合。
l TPS：Transaction per Second，每秒事務數量，單位是事務/秒。
l TRT：Transaction Response Time，事務響應時間，指TPS穩定時的平均事務響應時間，單位是秒。
三、 負載目標
1. 負載視角
制定測試策略是性能測試的重點，包括測試范圍、場景提取、負載目標、發起方式、通過標準等。而負載目標關系整個測試的場景設計、并發配比、結果評判，因此確定負載目標也決定了測試的總體方向。通過了解業務需求，負載目標都會轉化為一系列具體的數值，一般可從兩方面來劃分：
l 前端：業務人員更關注前端并發用戶數量或在線用戶數量，以人數衡量;
l 后端：技術人員更關注后端應用服務器和數據庫服務器的負載能力，以TPS衡量;
前端并發用戶數量的計算在業界中有很多公式和原則，如2/8原則、10%在線用戶數量估算、(在線用戶數量*session時間)/監控時間等，但各公式和原則計算出的并發用戶數量并不精確，如有10萬在線用戶的系統不能說僅測試10萬*10%=1萬并發用戶即可。
后端TPS反應被測應用的實際負載能力，對已有具體業務量的應用可以計算精確，如銀行系統中某省行對公交易量日均10萬筆，則可精確計算出TPS均值=10萬/(6*3600)=4.63筆/秒(對公業務按6小時計算)，若被測應用達不到TPS要求則完成不了當日業務。
同一個被測應用以不同視角估算負載目標，得到的數值可能會有很大差異，因此如何正確選擇負載目標，將會直接影響之后的測試方法和場景設計。
2. 負載指標
拋開視角的選擇，單從最終測試指標來說，對于一個軟硬件環境固定的應用程序，只有一個負載指標是固定的，那就是最大事務處理能力–通常以TPS衡量。隨著負載的增加，被測應用將會逐漸達到最大事務處理能力，若應用足夠健壯，則負載繼續增加，應用的事務處理能力也不會驟然下降。因此性能測試的目標就是確定被測應用的最大事務處理能力。以事務處理能力反推，將逐漸捋清TPS、TRT、并發用戶數量、在線用戶數量等負載目標的關系和估算。
TPS
Transaction的粒度會直接影響TPS的計算，因此Transaction定義時要保證粒度適當：
l C/S架構聯機類應用中一筆交易往往會流經多層前置應用，需要確定壓力發起工具所在位置，建議跨過前端直壓被測應用，此時一個Transaction代表一支后臺交易。
l B/S架構經管類應用中一個頁面操作可能會和后臺有多次交互，建議以頁面上的操作為Transaction劃分基準，但要保證Transaction內的交互操作在前端是不可再拆分的。
l LoadRunner發起壓力時Action內的語句是反復迭代的，而LR計算TPS僅看1秒內執行了幾次Transaction，如果Action內有多個Transaction則各事務的TPS都一樣，反應不出各事務的真實處理能力，因此建議Action內只定義一個或盡量精簡的Transaction。
由此TPS才可以準確表示被測應用的事務處理能力。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
