性能測試規劃建議書

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的實現、側重於迭代測試、寬廣的方法論。可適合任意測試環境及方法、工具。
缺點：需要根據測試環境進行剪裁、難以掌握、但掌握後非常成熟、高品質。
工具：涉及到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） 併發測試一般關注的問題是：

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. 《性能測試分析報告》