性能測試的幾個術語
1. 響應時間
我把“響應時間”的概念確定為“對請求作出響應所需要的時間”,把響應時間作`為用戶視角的軟件性能的主要體現。響應時間劃分為“呈現時間”和“系統響應時間”兩個部分。
其中“呈現時間”取決于數據在被客戶端收到響應數據后呈現頁面所消耗的時間、而“響應時間”指J2EE應用服務器從請求發出開始到客戶端接受到數據所消耗的時間。性能測試一般不關注“呈現時間”,因為呈現時間很大程度上取決于客戶端的表現。在這里我們沒有使用很多性能測試定義中的概念——“系統響應時間”定義為“應用系統從請求發出開始到客戶端接收到最后一個字節數據所消耗的時間”,沒有使用這種標準的原因是,可以使用一些編程技巧在數據尚未完全接收完成時進行呈現來減少用戶感受到的響應時間,對于HNDLZCGLXT的這個項目中,我們針對C/S系統采用前者標準,對于B/S我們依然采用后一種標準。
2. 并發用戶數
我把“并發用戶數”與“同時在線數”進行區別對待,我的“并發用戶數”的標準是:并發用戶數取決于測試對象的目標業務場景,因此,在確定這個“并發用戶數”前,必須(必要)先對用戶的業務進行分解、分析出典型的業務場景(也就是用戶最常使用、最關注的業務操作),然后基于場景采用某些方法(有多種計算并發用戶數的數學模型與公式)獲得“并發用戶數”。
這樣做的原因是:假設一個應用系統、最高峰有500人同時在線、但這500人卻不是并發用戶數、因為假設在一個時間點上、有50%的人在填寫復雜的表格(填寫表格動作對服務器沒有任何負擔、只有在“提交”動作的時候才會對服務器系統構成壓力)、有40%的人在不停的從一個頁面跳轉到另外一個頁面(不停發出請求與回應、產生服務器壓力)、還有10%的人掛在線上,沒有任何操作在發呆:)(沒有對服務器構成壓力的動作)。因此只有那40%的人真正對服務器產生了壓力,從這里例子可以看出、并發用戶數關心的是不但是業務并發用戶數、還取決于業務邏輯、業務場景。因此我們需要本文第六部分性能測試文檔4、5、6。
3. 吞吐量
我把吞吐量定義為“單位時間內系統處理的客戶請求的數量”,直接體現軟件系統的性能承載能力,對于交互式應用系統來說、吞吐量反映的是服務器承受的壓力、在容量規劃的測試中、吞吐量是一個重要指標、它不但反映在中間件、數據庫上、更加體現在硬件上。我們在以下方面利用這個指標:
(1) 用來協助設計性能測試場景,衡量性能測試是否達到了預計的設計目標、比如J2EE應用系統的連接池、數據庫事務發生頻率、事務發生次數。
(2) 用來協助分析性能瓶頸、參照本文第二部分總的RBI方法。
4. 性能計數器
性能計數器式描述服務器或操作系統性能的一些數據指標、例如對WINDOWS來說使用內存數、CPU使用率、進程時間等都是常見的計數器。
對于性能計數器這個指標來說、需要考慮到的不但有硬件計數器、web服務器計數器、Weblogic服務器計數器、Servlet性能計數器、EJB2的性能計數器、JSF性能計數器、JMS性能計數器。找到這些指標是使用性能計數器的第一步、關鍵是找到性能瓶頸、確定系統閥值、提供優化建議才是性能計數器使用的關鍵。性能計數器復雜而繁多、與代碼上下文環境、系統配置情況、系統架構、開發方式、使用到的規范實現、工具、類庫版本都有緊密的聯系、在此不作贅述。
5. 思考時間
我把思考時間確定為“休眠時間”。從業務系統的角度來說,這個時間指的是用戶在驚醒操作時、每個請求之間的時間間隔、從自動化測試的角度來說、要真實的測試模擬用戶操作、就必須在測試腳本中讓各個操作之間等待一段時間、體現在腳本上就是在操作之間放置一個Think的函數,體現為腳本中兩個請求語句之間的間隔時間、不同的測試工具提供了不同的函數或方法來實現思考時間、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。
性能測試方法論
1. SEI負載測試計劃過程
目標:產生一個清晰、好理解、可驗證的負載測試計劃
內容:關注6個區域:目標、用戶、用例、生產環境、測試環境、測試場景
工具:IBM、HP、OpenSource工具都支持。需有文檔配合
2. RBI方法
目標:快速識別性能瓶頸
內容:重點測試“吞吐量”指標,因為RBI認定80%的系統性能瓶頸由吞吐量造成。
按照網絡、硬件、數據庫、應用服務器、代碼的順序自上而下分析性能
工具:IBM、HP、OpenSource工具都支持。需使用分析模塊、根據Weblogic、Oracle區別有專門的工具實現RBI。
3. 性能下降曲線分析法
目標:性能隨著用戶數的增加而出現下降趨勢的曲線分析、查看性能下降的環境點與上下文。確定性能閥值。
內容:通過單用戶區域、性能平坦區域、壓力區域、性能拐點進行監控和分析。
工具:IBM、HP、OpenSource工具都支持。IBM報表功能更強。
4. HP(LoadRuner)性能分析法
特點:側重于該廠商的性能分析方法、主要體現在需求收集、VU腳本。
缺點:沒有對測試計劃階段、測試設計階段的具體行為、方法、目的進行描述。方法局限于LoadRuner產品的特性上。不能通用。
5. IBM(Rational UP)軟件測試方法
特點:軟件產品生命周期RUP的實現、側重于迭代測試、寬廣的方法論?蛇m合任意測試環境及方法、工具。
缺點:需要根據測試環境進行剪裁、難以掌握、但掌握后非常成熟、高品質。
工具:涉及到IBM Rational 測試環境的所有軟件、功能強大。
6. PTGM性能測試模型
內容:一個非常適合行業用戶(電力、金融、政務、制造)的性能測試過程模型。規范化的測試模型、每個環節都做到迭代測試、每一個過程的工作產品明顯可察、測
試流程、測試上下文方面很優秀。包括以下環節:前期準備、工具引入、測試計劃、測試設計與開發、測試執行與管理、測試分析。
工具:可以使用任意商業工具全新部署測試流程、不限于任何廠商工具的局限、也可以使用部分工具即可完成整個流程、或結合自己需要基于OpenSource工具進行定
制。個人傾向使用多個產品的整合、綜合使用、揚長避短。
性能測試方法
1. 性能測試
性能測試方法通過模擬生產運行的業務壓力量和使用場景組合測試性能是否能夠滿足需要。具備三個特點:
(1) 這種方法的目的是驗證系統是否具有系統宣稱具有的能力。
(2) 這種方法需要事先了解被測試系統典型場景、并確定性能目標。
(3) 這種方法要求在已確定的環境下運行
使用IBM Rational Performance Tester、HP Mercury LoadRuner、OpenSTA、Apache ab、Jmeter、QALoad 、TagUnit、Java Test Runner。
2. 負載測試
負載測試用來測定系統飽和狀態、確定閥值。其特點有:
(1) 這種方法的目的是找到系統處理能力的極限;通過“檢測、加壓、閥值”手段找到如“響應時間不超過10秒”,“服務器平均CPU利用率低于65%”等指標。
(2) 這種性能測試方法需要在給定的測試環境下進行,通常也需要考慮被測系統的業務壓力量和典型場景、另外HP Mercury LoadRuner在使用該方法進行“加壓”的時候必須選擇典型場景。
(3) 這種性能測試方法一般用來了解系統的性能容量,或者是配合性能調優的時候來使用。特別是該項目的Weblogic Server和Oracle數據庫的性能調優。
3. 壓力測試
壓力測試方法測試目標系統在一定飽和狀態下,例如CPU、內存等在飽和狀態下、系統能夠處理的session的能力,以及系統是否會出現錯誤。該方法需要在系統cache調優與pool優化方面著手。該方法具備以下特點:
(1) 該方法的目的是檢查系統處于壓力情況下的,應用的表現。如增加VU數量、節點數量、并發用戶數量等使應用系統的資源使用保持一定的水平,這種方法的主要目的是檢驗此時的應用表現,重點在于有無錯誤信息產生,系統對應用的響應時間等。
(2) 該方法通過模擬負載在實現壓力。這種模擬需要考慮的層面很多、首先、模擬必須是有效的,我的經驗是需要結合業務系統和軟件架構來定制模擬指標、我測試過一些國內生產的壓力測試工具、他們使用通用的指標來考量、造成很多信息反饋有很大的水分。需要考慮的層面如:Oracle I/O、JVM GC、Conn Pool等。
(3) 該方法還可以測試系統的穩定性。這里的技巧在于“什么樣的平臺定義一個多長的壓力測試時間讓其穩定運行才是科學的?”
文章來源于領測軟件測試網 http://www.kjueaiud.com/