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） 并發測試一般關注的問題是：
問 題 類 別 問 題 描 述 內存問題是否有內存泄露（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/
