性能測試的一些常見術語
-
響應時間我把“響應時間”的概念確定為“對請求作出響應所需要的時間”，把響應時間作`為用戶視角的軟件性能的主要體現。響應時間劃分為“呈現時間”和“系統響應時間”兩個部分。其中“呈現時間”取決於數據在被客戶端收到響應數據後呈現頁面所消耗的時間、而“響應時間”指J2EE應用服務器從請求發出開始到客戶端接受到數據所消耗的時間。軟件性能測試一般不關註“呈現時間”，因為呈現時間很大程度上取決於客戶端的表現。在這裏我們沒有使用很多軟件性能測試定義中的概念——“系統響應時間”定義為“應用系統從請求發出開始到客戶端接收到最後一個字節數據所消耗的時間”，沒有使用這種標準的原因是，可以使用一些編程技巧在數據尚未完全接收完成時進行呈現來減少用戶感受到的響應時間，對於HNDLZCGLXT的這個項目中，我們針對C/S系統采用前者標準，對於B/S我們依然采用後一種標準。
-
並發用戶數我把“並發用戶數”與“同時在線數”進行區別對待，我的“並發用戶數”的標準是：並發用戶數取決於測試對象的目標業務場景，因此，在確定這個“並發用戶數”前，必須(必要)先對用戶的業務進行分解、分析出典型的業務場景(也就是用戶最常使用、最關註的業務操作)，然後基於場景采用某些方法(有多種計算並發用戶數的數學模型與公式)獲得“並發用戶數”。這樣做的原因是：假設一個應用系統、最高峰有500人同時在線、但這500人卻不是並發用戶數、因為假設在一個時間點上、有50%的人在填寫復雜的表格(填寫表格動作對服務器沒有任何負擔、只有在“提交”動作的時候才會對服務器系統構成壓力)、有40%的人在不停的從一個頁面跳轉到另外一個頁面(不停發出請求與回應、產生服務器壓力)、還有10%的人掛在線上，沒有任何操作在發呆：)(沒有對服務器構成壓力的動作)。因此只有那40%的人真正對服務器產生了壓力，從這裏例子可以看出、並發用戶數關心的是不但是業務並發用戶數、還取決於業務邏輯、業務場景。因此我們需要本文第六部分軟件性能測試文檔4、5、6。
-
吞吐量我把吞吐量定義為“單位時間內系統處理的客戶請求的數量”，直接體現軟件系統的性能承載能力，對於交互式應用系統來說、吞吐量反映的是服務器承受的壓力、在容量規劃的測試中、吞吐量是一個重要指標、它不但反映在中間件、數據庫上、更加體現在硬件上。我們在以下方面利用這個指標：(1)
用來協助設計軟件性能測試場景，衡量軟件性能測試是否達到了預計的設計目標、比如J2EE應用系統的連接池、數據庫事務發生頻率、事務發生次數。(2) 用來協助分析性能瓶頸、參照本文第二部分總的RBI方法。 -
性能計數器性能計數器式描述服務器或操作系統性能的一些數據指標、例如對WINDOWS來說使用內存數、CPU使用率、進程時間等都是常見的計數器。
[Page]對於性能計數器這個指標來說、需要考慮到的不但有硬件計數器、web服務器計數器、Weblogic服務器計數器、Servlet性能計數器、EJB2的性能計數器、JSF性能計數器、JMS性能計數器。找到這些指標是使用性能計數器的第一步、關鍵是找到性能瓶頸、確定系統閥值、提供優化建議才是性能計數器使用的關鍵。性能計數器復雜而繁多、與代碼上下文環境、系統配置情況、系統架構、開發方式、使用到的規範實現、工具、類庫版本都有緊密的聯系、在此不作贅述。 -
思考時間我把思考時間確定為“休眠時間”。從業務系統的角度來說，這個時間指的是用戶在驚醒操作時、每個請求之間的時間間隔、從自動化測試的角度來說、要真實的測試模擬用戶操作、就必須在測試腳本中讓各個操作之間等待一段時間、體現在腳本上就是在操作之間放置一個Think的函數，體現為腳本中兩個請求語句之間的間隔時間、不同的測試工具提供了不同的函數或方法來實現思考時間、比如HP
LoadRuner和IBM Rational Performance Tester的方式就完全不同。
性能測試的一些常見術語