模板
教程
環境
性能
功能
管理
性能測試從零開始：LoadRunner入門(10)
實際上，當我們做過的性能測試項目越多，就會發現越多的因素可能會影響性能測試項目的成敗，甚至可以是千奇百怪的。
在本節中，我們主要是尋找出不同性能測試項目的共性，而總結出一個具有普遍意義的性能測試過程。遵循過程做性能測試，在大多數情況下可以有效地規避風險，并能取得比較好的性能測試結果。這當然不是意味著我們有了這個過程，就不考慮其他因素了，只是說每個項目都會有自己的獨特因素要考慮，盡管這些因素可能很重要，但它們并不在本節的討論范圍內。
在給出此過程模型之前，我們要澄清兩點事實：
第一，性能測試過程從何時開始，又在何時結束?
這是一個基本而重要的問題。
在各種書籍和資料中，有關性能測試過程的描述不盡一樣：
比如LoadRunner手冊中提供的過程是：計劃測試→測試設計→創建VU腳本→創建測試場景→運行測試場景→分析結果。
而在Segue中提供的性能測試過程，是一個try-check過程，即：評估需求→開發測試→建立基線→執行測試→分析結果→回歸測試→測試結束。
上面LoadRunner和Segue描述各自的性能測試過程最大的區別不在于工具部分，而是在于兩者過程的入口和出口條件不一致。這使得它們其實在描述兩件事情，或者說是在描述一個事情的兩個部分。
在CMM中，軟件測試和軟件設計、編碼一樣，隸屬于軟件工程過程，而需求分析過程在軟件工程過程之前。這就隱含著一個默認的先決條件：在CMM這個體系下，產品在進入軟件測試階段的時候，軟件需求是已經明確下來并文檔化了的。
實際情況卻經常并非如此，同樣是軟件需求，軟件功能需求在進入測試階段就已經產生了各種文檔，包括需求文檔和設計文檔，確保功能需求是詳細、明確、無二義性的;而軟件性能需求往往進入了性能測試階段還不明確(可參見Controller一章開篇的例子)。這會給性能測試項目帶來很大的風險。
因此，我們應該突破已有的理論束縛，尋找更合適的性能測試過程模型。經過對多個性能測試項目的實踐經驗總結，我們在本節提出GAME(A)性能測試過程模型，其開始于軟件需求分析階段，非常符合目前國內的性能測試實踐。
第二，性能測試本身有沒有質量?
以前我們總是討論軟件產品的質量、開發代碼的質量，但對軟件測試的質量卻鮮有提及。我們知道“一個好的測試用例是發現了一個原先未發現的bug”，這其實是對用例質量的度量。軟件性能測試項目也有質量，并可以度量。下面是部分度量的方法：
(1)性能測試耗費的資源，包括時間、人力、物力。
(2)性能測試中發現的bug數目，以及各自的級別。
(3)軟件系統交付用戶，在生產環境運行后發現的性能bug數目、級別。
而一個好的性能測試過程模型對提高性能測試質量是很有幫助的。
GAME(A)性能測試過程模型：
Ÿ G：Goal，目標
Ÿ A：Analysis，分析
Ÿ M：Metrics，度量
Ÿ E：Execution，執行
Ÿ (A)：Adjust，調整。E執行失敗后才進入A階段，并且涉及的大多是有關開發和系統管理工作，因此A設為隱式。
性能測試過程模型如圖1-5所示。
圖1-5 性能測試GAME(A)模型
1.3.1 Goal(定義目標)
制定一個明確而詳細的測試目標是性能測試開始的第一步，也是性能測試成功的關鍵。
本步驟的開始時間：需求獲取階段
本步驟的輸入：性能需求意向
本步驟的輸出：明確的性能測試目標和性能測試策略
常規的性能測試目標有以下幾種：
(1)度量最終用戶響應時間
查看用戶執行業務流程以及從服務器得到響應所花費的時間。例如，假設我們想要檢測：系統在正常的負載情況下運行時，最終用戶能否在20秒內得到所有請求的響應。圖1-6顯示了一個銀行應用程序的負載和響應時間度量之間的關系。
