介紹
任何特定軟件即將發布并投入生產期間，其性能一直備受關注。盡管一軟件已被用戶證明如預期的正常運作（通過功能測試后），故障仍可能會發生，尤其當它無法承擔用戶生成的大量loads， volumes， transactions等時。評估軟件的質量和適用性時，很少認真考慮這種非功能需求。因此，謹慎和周密的策劃分析和性能測試用例設計是防止軟件性能故障的關鍵。有了正確的性能場景，就可以系統地進行測試執行和軟件性能評估，從而可以對性能改進做出詳細的分析和建議。
本文通過展示一個實際的案例研究（關于如何為一個基于云的系統規劃和設計性能測試用例）解決了這個問題。性能測試結果對性能測試執行的分析，被證為測試用例設計的有效性的證據。
關于被測的基于云的系統的概述
開發被測系統的目的是：通過（最初是上網本上的）移動設備上的統一智能平臺為大眾提供各種在線服務。
該系統主要包括幾個子系統：安裝在上網本上的客戶端系統，智能服務門戶，位置感知服務，內容整合服務，以及承載所有在線服務系統的云或虛擬平臺。
.jpg)
圖1．被測系統的邏輯結構
客戶端系統是使用Java語言開發，Java網絡啟動協議（ JNLP ）執行的。為了獲取所需在線服務，客戶端系統到智能服務門戶網提出服務請求。存儲所有服務的門戶網還結合了內容整合服務和位置感知服務。所有這些使得合適的內容根據所請求的服務被推送到客戶端系統的最終用戶那兒。除此之外，門戶網站還能夠簡介并結合適合服務的相關內容。另一方面，多個虛擬機上的云平臺承載了所有子系統（智能服務門戶網站，內容整合，以及位置感知），可以運行虛擬機實例并提供虛擬機負載的可擴展性。
該系統的邏輯結構如圖1所示。從部署的角度去看，圖2展示了整個系統的操作環境。
根據這兩個圖，很明顯本系統的性能測試需要覆蓋終端用戶場景及服務器場景。
這是因為一個成功的服務器性能測試并不能保證在客戶端運用該系統時，最終用戶也會同樣成功。
性能測試
這只是常用來衡量任何被測系統性能的一個概括。通常，我們設計并執行一次性能測試以弄清系統是如何響應特定load的，無論load有沒有被定義為許多并發用戶，volumes或 transactions。
如下表1描述了性能測試各個領域的重點。
.jpg)
表1．性能測試重點
上述重點保證了被測系統應對用戶不斷增長的loads時是可延展的，且一旦它被發布并投入生產就沒有任何意想不到的問題，長遠來看還有助于提高最終用戶的滿意度。這也將會使該系統比市場上的其它相似系統更具競爭優勢。
設計性能測試用例
評估系統的測試用例的設計主要是受早前在規劃和分析階段設置的性能標準制約的。該系統需要足夠快的響應速度，或者至少要達到規定的通過性能測試的最低性能標準。
.jpg)
圖2.被測系統的物理架構
如果系統可以表現得超出這些標準，即比最低標準值更快，該系統則被認為具有更好的性能及未來可以應對更多用戶的可擴展性。另一個重要方面是確保性能測試用例的目的是建立真實世界模擬測試。現實世界測試用例將大幅度提高測試結果的可靠性。確定要模擬的測試用例時的重點是“最常見使用場景”和“業務關鍵使用場景”。測試用例一度不得不預測最常見的場景，因為系統還未上市且唯一知道的信息是：要求的程度。一旦系統上市，例如β測試中，就應有足夠的關于用戶如何使用系統的信息。該系統在Apache Web服務器上，因此可以訪問日志，上面提供所有游客到過系統的記錄。日志可以用“流量分析器”跟蹤一直以來的用戶的模式和習慣。因此測試用例可用于反映真實世界場景。系統擁有者或利益相關者為使該系統通過性能測試而設置的標準規范是：系統需要在1到100個并發用戶的負載下5秒內做出響應。
然而，該標準應當通過設計正確的、運行系統的、可能的場景而被進一步分解。最根本的是把性能測試一分為二：客戶端性能和服務器端（云計算）性能。原因是，一個成功的測試服務器端并不等同于成功的客戶端，反之亦然。
利益相關者都同意，要測試的用戶數目為1 ，100，200 ，300，400 ，500，1000 ， 1500和3000個并發（虛擬）用戶。這些數字與下面表2中給出的各場景相關：
.jpg)
表2.性能測試場景和相關虛擬用戶
設計性能測試用例時通常會被忽略的一方面是：將表2中的場景和一個網速測試或網絡延遲連接以獲得更逼真的測試用例，像對客戶端系統所做的一樣。這是為了模擬用戶將如何體驗不同互聯網連接速度下系統的響應。選定的匹配性能測試的速度是標準LAN速度（這種情況下，1GbpsLAN速度），無線LAN速度，1 Mbps的有線寬帶和0.44 Mbps的無線寬帶。
對于云平臺，只用局域網速度進行性能測試。因此，這一基于云的系統的用以執行性能測試的完整測試用例如表3所示：
.jpg)
表3.性能測試用例
案例研究 –把設計放入執行
一個開源性能測試工具被用來執行所有性能測試的云系統測試用例，因為相對于其他性能測試工具，它允許越來越多的user loads且沒有虛擬用戶許可證限制。
然而，手動執行被用于客戶端系統，因為客戶端系統只能在上網本上運行，所以手動測試更實用。
分布式性能測試方法被用于執行測試，以便工具可以有效地管理代理。
工具的環境設置如圖3所示：
.jpg)
圖3. 分布式性能測試執行的環境設置
性能測試結果分為兩組：云平臺的測試結果和客戶端的測試結果。
表4詳述了云平臺的性能測試結果，而表5顯示了客戶端的性能測試結果。
此外，為了更好地理解，圖4以圖表形式展示了云性能結果。
.jpg)
表4.云平臺性能的響應時間結果
.jpg)
圖4.云平臺性能測試結果
.jpg)
表5.客戶端性能的響應時間結果
從給出的結果，可以進一步解釋幾個研究發現。
研究發現如下：
▪云平臺或（客戶端可從其獲得在線服務的）服務器端系統能夠在性能標準的5秒內響應1到100個虛擬用戶而無任何中斷。
▪雖然云平臺仍然可以成功響應3000個虛擬用戶，但響應時間延遲了，超出性能標準的5秒。
▪在客戶端，最終用戶可能會遇到：在通過客戶端系統獲取在線服務時，云平臺的用戶負載過大，響應時間延遲。
▪比起那些更慢的互聯網獲取，通過使用一個更快的互聯網連接，最終用戶可以更快地獲取在線服務
結論
由于本文的重點是性能測試的測試用例設計，一個展示這些測試用例是如何被用于執行的案例研究為本文提供了論點。很顯然，正確的規劃對保證任何性能測試的成功都非常關鍵。性能測試不應該基于“想要時”或“要求時”。性能測試的測試場景和測試用例需盡可能早地被定義和設計，就和其他類型的測試一樣，比如功能測試。這將決定能否順利執行性能測試，其中包括：性能測試工具的選擇，測試環境的設置，如何做出性能衡量和分析應該做的選擇，性能結果不符合指定準則時擴大云平臺的行動計劃，以及執行測試的時間和資源。
這些到位了，任何經過了嚴格性能測試的系統，一旦置于生產環境中，都能夠應付日益增長的負載量，并且對服務其用戶更穩定，更反應靈敏。