性能測試的幾個術語
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） 該方法還可以測試系統的穩定性。這里的技巧在于“什么樣的平臺定義一個多長的壓力測試時間讓其穩定運行才是科學的？”
4. 配置測試
配置測試方式是指在測試前、測試中、測試后三個時間段通過對被測系統的軟件/硬件環境的調整，了解各個不同環境對系統性能影響的程度，從而找到系統各個資源的最優分配原則。它具備以下特點：
（1） 該方法的目的是了解各個不同的因素對系統性能影響的程度、從而判斷出最值得進行的調優操作。該方法不同于與“功能測試”中涉及到的“配置測試”。
（2） 該方法存在很大的靈活性、可以在測試環節的各個時間進行、但是什么時候開始、什么時候暫停、什么時候結束才是運用這個方法的關鍵。同時也是HNDLZCGLXT考量性能測試服務供應商的關鍵。
5. 并發測試
該方法通過模擬用戶的并發訪問，測試多用戶環境并發訪問同一個應用、同一個模塊或者數據記錄時系統是否存在死鎖或者其他性能問題。該方法特點是：
（1） 可以發現應用系統的全局性性能問題。
（2） 該方法可以在開發工作的各個環節使用可以使用多個工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。
（3） 并發測試一般關注的問題是：
|
MILY: 宋體" twffan="done">問 題 類 別 |
問 題 描 述 |
|
內存問題 |
是否有內存泄露（COM+，JAVA） |
|
是否有太多的臨時對象（JAVA） | |
|
是否有太多不合理聲明的超過設計生命周期的對象 | |
|
數據庫問題 |
是否有數據庫死鎖 |
|
是否經常出現長事務 | |
|
線程/進程問題 |
是否出現線程/進程同步失敗 |
|
其他問題 |
是否出現資源爭用導致的死鎖 |
|
是否沒有正確處理異常（如超時）導致的系統死鎖 |
6. 可靠性測試
這里說的“可靠性測試”并不等同于“獲得軟件的可靠性”，軟件的可靠性是一個很大的命題，這里指的可靠性測試是通過給系統加載一定的業務壓力（例如：資源在80%~90%的使用率），讓應用系統運行一段時間、測試系統是否穩定運行。這里有三點需要注意：
（1） 在使用該測試前需要目的系統的資源使用率已經達到70%~90%。即在這樣的苛刻環境下運行該應用系統。
（2） 應用系統運行起來后，加載業務壓力使應用系統資源達到90%。比如：該J2EE系統中設置的JDBC數據庫連接池定義為30，那么加載業務壓力使連接達到27。
（3） 應用系統運行起來后結合業務情況來設定一個運行時間。比如：電力資產系統要求MTBF（平均無故障時間）達到10000小時、那么我們可以認定該系統的運行時間至少需要達到三年重新啟動一次。超過這個數字我們就可以認為“不可靠”。一般情況下對于這個要求、我們讓J2EE系統在資源使用率90%~100%狀態連續穩定的運行3天左右沒有錯誤就可以認定該MTBF指標已經達到。
7. 失效恢復測試
該方法是針對有HACMP等冗余備份和Edge Server for LB等負載均衡的J2EE系統設計的。該方法考量系統失效恢復的時間、用戶受到多大程度、多大范圍的影響，并將其量化。該方法有以下特點：
（1） 一般的關鍵業務都會采用雙機熱備或負載均衡方式來實現。
（2） 該方法回答兩個問題：當問題發生的時候“能支持多少用戶訪問”，“有多少功能不能使用”
（3） 需要說明的是，對于HNDLZCGLXT的這個項目來說，負載均衡需要仔細考慮其實現方式，這影響到性能的調優�？梢钥紤]使用F5等硬件技術方式、也可以考慮使用 IBM WebSphere Edge Server等商業版本的軟件技術方式。否則單純對EJB 容器Weblgoic Server作集群沒有意義。
性能測試分析方法
該部分著重于PTGM方法論
1. 能力驗證
能力驗證一般采用這樣的描述：“該系統是否能在A條件下具備B能力？”。這里強調以下內容：
（1） 充分準備以下內容：硬件設備、軟件環境、網絡條件、基礎數據
（2） 充分準備測試場景、典型的場景包括操作序列、并發用戶數量條件、用例。
該部分包括使用到上述測試方法：性能測試方法、可靠性測試、壓力測試、失效恢復測試
2. 規劃性能
該分析方法關心的是“應該如何才能使系統具有我們要求的性能能力”，“應該如何調整系統配置，使系統能夠滿足增長的用戶數的需要”等問題。這個部分常常使用到的測試方法是：負載測試、配置測試、壓力測試。
3. 性能調優
一個標準的性能調優過程是：
（1） 確定基準環境、基準負載和基準性能指標。
（2） 調整系統運行環境和實現方法，執行測試。
（3） 記錄測試結果、進行分析
在J2EE性能測試中有很多常見的錯誤，比如：對于某些建立在J2EE/EJB技術上的應用，在服務啟動的時候，沒有注意到測試之前首先進行一段時間的預熱。這是因為JAVA語言的hot-spot技術特性決定的，這種技術允許weblogic第一次運行應用的時候將字節碼編譯為本地代碼并執行，這樣在后續的執行過程中執行過程會大大加快，但第一次由于存在一個編譯過程會比較慢。如果使用這個時間來作為基準那么就容易得出錯誤的結論。
我對第2個過程比較擅長、具體下來包括硬件環境的調優、Weblogic調優、Oracle調優。這個過程中也是使用工具最多的測試環節。
4. 發現缺陷
這個環節中是交付給用戶的主要工作成果。需要多和開發人員作溝通、多次迭代發現問題、根據用戶的需求定義與缺陷的涉及范圍、制定一個解決缺陷的優先級。由于軟件永遠有BUG這一真理，所以發現缺陷不是一次就能結束的工作。比較適合作為服務外包。持續進行。
性能測試文檔
以下作為我對性能測試完整內容的建議，表格模板不作贅述
1. 《性能測試成員職責技能描述表》
2. 《性能測試工具需求規劃表》
3. 《性能測試環境調查表》
4. 《典型業務邏輯列表》
5. 《業務用例描述表》
6. 《測試場景列表》
7. 《測試計劃》
8. 《測試環境檢查表》
9. 《測試執行記錄日志》
10. 《性能測試分析報告》
文章來源于領測軟件測試網 http://www.kjueaiud.com/