性能測試規劃建議書(3)
發表于:2014-09-02來源:uml.org.cn作者:不詳點擊數:
標簽:性能測試
4. 配置測試 配置測試方式是指在測試前、測試中、測試后三個時間段通過對被測系統的軟件/硬件環境的調整,了解各個不同環境對系統性能影響的程度,
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能力?”。這里強調以下內容:
原文轉自:http://www.uml.org.cn/Test/200704233.asp