介紹
任何特定軟件即將發布并投入生產期間,其性能一直備受關注。盡管一軟件已被用戶證明如預期的正常運作(通過功能測試后),故障仍可能會發生,尤其當它無法承擔用戶生成的大量loads, volumes, transactions等時。評估軟件的質量和適用性時,很少認真考慮這種非功能需求。因此,謹慎和周密的策劃分析和性能測試用例設計是防止軟件性能故障的關鍵。有了正確的性能場景,就可以系統地進行測試執行和軟件性能評估,從而可以對性能改進做出詳細的分析和建議。
本文通過展示一個實際的案例研究(關于如何為一個基于云的系統規劃和設計性能測試用例)解決了這個問題。性能測試結果對性能測試執行的分析,被證為測試用例設計的有效性的證據。
關于被測的基于云的系統的概述
開發被測系統的目的是:通過(最初是上網本上的)移動設備上的統一智能平臺為大眾提供各種在線服務。
該系統主要包括幾個子系統:安裝在上網本上的客戶端系統,智能服務門戶,位置感知服務,內容整合服務,以及承載所有在線服務系統的云或虛擬平臺。
圖1.被測系統的邏輯結構
客戶端系統是使用Java語言開發,Java網絡啟動協議( JNLP )執行的。為了獲取所需在線服務,客戶端系統到智能服務門戶網提出服務請求。存儲所有服務的門戶網還結合了內容整合服務和位置感知服務。所有這些使得合適的內容根據所請求的服務被推送到客戶端系統的最終用戶那兒。除此之外,門戶網站還能夠簡介并結合適合服務的相關內容。另一方面,多個虛擬機上的云平臺承載了所有子系統(智能服務門戶網站,內容整合,以及位置感知),可以運行虛擬機實例并提供虛擬機負載的可擴展性。
該系統的邏輯結構如圖1所示。從部署的角度去看,圖2展示了整個系統的操作環境。
根據這兩個圖,很明顯本系統的性能測試需要覆蓋終端用戶場景及服務器場景。
這是因為一個成功的服務器性能測試并不能保證在客戶端運用該系統時,最終用戶也會同樣成功。
性能測試
這只是常用來衡量任何被測系統性能的一個概括。通常,我們設計并執行一次性能測試以弄清系統是如何響應特定load的,無論load有沒有被定義為許多并發用戶,volumes或 transactions。
如下表1描述了性能測試各個領域的重點。
表1.性能測試重點
上述重點保證了被測系統應對用戶不斷增長的loads時是可延展的,且一旦它被發布并投入生產就沒有任何意想不到的問題,長遠來看還有助于提高最終用戶的滿意度。這也將會使該系統比市場上的其它相似系統更具競爭優勢。
設計性能測試用例
評估系統的測試用例的設計主要是受早前在規劃和分析階段設置的性能標準制約的。該系統需要足夠快的響應速度,或者至少要達到規定的通過性能測試的最低性能標準。
圖2.被測系統的物理架構
如果系統可以表現得超出這些標準,即比最低標準值更快,該系統則被認為具有更好的性能及未來可以應對更多用戶的可擴展性。另一個重要方面是確保性能測試用例的目的是建立真實世界模擬測試?,F實世界測試用例將大幅度提高測試結果的可靠性。確定要模擬的測試用例時的重點是“最常見使用場景”和“業務關鍵使用場景”。測試用例一度不得不預測最常見的場景,因為系統還未上市且唯一知道的信息是:要求的程度。一旦系統上市,例如β測試中,就應有足夠的關于用戶如何使用系統的信息。該系統在Apache Web服務器上,因此可以訪問日志,上面提供所有游客到過系統的記錄。日志可以用“流量分析器”跟蹤一直以來的用戶的模式和習慣。因此測試用例可用于反映真實世界場景。系統擁有者或利益相關者為使該系統通過性能測試而設置的標準規范是:系統需要在1到100個并發用戶的負載下5秒內做出響應。
然而,該標準應當通過設計正確的、運行系統的、可能的場景而被進一步分解。最根本的是把性能測試一分為二:客戶端性能和服務器端(云計算)性能。原因是,一個成功的測試服務器端并不等同于成功的客戶端,反之亦然。
原文轉自:http://www.uml.org.cn/Test/201406175.asp?artid=1812