1.3.1 goal（定義目標）
制定乙個明確而詳細的測試目標是效能測試開始的第一步，也是效能測試成功的關鍵。
本步驟的輸入：效能需求意向
本步驟的輸出：明確的效能測試目標和效能測試策略
常規的效能測試目標有以下幾種：
（1）度量終端使用者響應時間
檢視使用者執行業務流程以及從伺服器得到響應所花費的時間。例如，假設我們想要檢測：系統在正常的負載情況下執行時，終端使用者能否在20秒內得到所有請求的響應。圖1-6顯示了乙個銀行應用程式的負載和響應時間度量之間的關係。
圖1-6 使用者數-響應時間關係圖
（2）定義最優的硬體配置
檢測各項系統配置（記憶體、cpu速度、快取、介面卡、數據機）對效能的影響。了解系統體系結構並測試了應用程式響應時間後，您可以度量不同系統配置下的應用程式響應時間，從而確定哪一種設定能夠提供理想的效能級別。
例如，您可以設定三種不同的伺服器配置，並針對各個配置執行相同的測試，以確定效能上的差異：
配置1：1.2ghz、1gb ram
配置2：1.2ghz、2gb ram
配置3：2.4ghz、1gb ram
（3）檢查可靠性
確定系統在連續的高工作負載下的穩定性級別。強制系統在短時間內處理大量任務，以模擬系統在數週或數月的時間內通常會遇到的活動型別。
（4）檢視硬體或軟體公升級
執行回歸測試，以便對新舊版本的硬體或軟體進行比較。您可以檢視軟體或硬體公升級對響應時間（基準）和可靠性的影響。注意：此回歸測試的目的不是驗證公升級版的新功能，而是檢視新版本的效率和可靠性是否與舊版本相同。
（5）確定瓶頸
您可以執行測試以確定系統的瓶頸，並確定哪些因素導致效能下降，例如，檔案鎖定、資源爭用和網路過載。將loadrunner與新的網路和計算機監視工具結合使用以生成負載，並度量系統中不同點的效能，最終找出瓶頸所在的位置。
（6）度量系統容量
度量系統容量，並確定系統在不降低效能的前提下能提供多少額外容量。如圖1-7所示，要檢視容量，您可以檢視現有系統中效能與負載間的關係，並確定出現響應時間顯著延長的位置。該處通常稱為響應時間曲線的「拐點」。
圖1-7 使用者數-響應時間拐點圖
我們根據不同的測試目標去選擇合適的效能測試設計策略。比如，「度量終端使用者響應時間」可以採用負載測試策略，「檢查可靠性」就可以用壓力測試策略，等等。
1.3.2 analysis（分析）
本步驟的輸入：效能需求
本步驟的輸出：達成一致的效能指標列表，效能測試案例文件
1．分析效能需求
在這裡，要定義效能測試的內容，細化效能需求。
客戶、需求分析人員和測試工程師一起起草乙個效能需求標準，對此標準獲得一致認同。此標準將使用者的需求細化、量化，並能在測試中作為判斷依據。
比如，對於負載測試來說，可以從以下角度來細化需求，逐步找出測試關鍵點。
測試的物件是什麼，例如「被測系統中有負載壓力需求的功能點包括哪些？」；「測試中需要模擬哪些部門使用者產生的負載壓力？」等問題。
系統配置如何，例如「預計有多少使用者併發訪問？」；「使用者客戶端的配置如何？」；「使用什麼樣的資料庫」；「伺服器怎樣和客戶端通訊？」。
應用系統的使用模式是什麼，例如「使用在什麼時間達到高峰期？」；「使用者使用該系統是採用b/s執行模式嗎？」；「網路裝置的吞吐能力如何，每個環節承受多少併發使用者？」等問題。
最後得出的效能測試指標標準至少要包含測試環境、業務規則、期望響應時間等。
2．分析系統架構
對硬體和軟體元件、系統配置以及典型的使用模型有乙個透徹的了解。結合效能測試指標標準，生成效能測試用例。（可參看第10章「高階loadrunner高手」的用例設計部分。）
1.3.3 metrics（度量）
本步驟的輸入：細化的效能指標和效能測試案例
度量是非常重要的一步，它把效能測試本身量化。這個量化的過程因測試工具的不同而異。
（1）場景的定義，pass/fail的標準
測試場景包含了效能測試的巨集觀資訊，有測試環境、執行規則和監控資料等。具體可表現為歷史資料記錄數、虛擬使用者數、虛擬使用者載入方式、監控指標等。
（2）事務（transaction）的定義，pass/fail的標準
事務用來度量伺服器的處理能力。事務定義應該從效能指標標準而來，是效能指標的具體體現。事務的定義是很重要的，不同的定義會導致不同的tps結果。
使用效能測試工具執行效能測試之後，我們能看到的是pass/fail的使用者數、pass/fail的事務數。而這些pass/fail的標準應該 在執行效能測試之前就應該被定義好。比如，loadrunner預設的pass/fail標準是基於協議層的，而我們要的pass/fail可能是業務級 的，需要在業務層上進行判斷來決定是pass還是fail。另外，還可能由於案例的關聯性引起的pass/fail，如果兩個案例之間有關聯，a指令碼負責 向資料庫插入資料，b指令碼負責查詢資料，a要是fail了，導致b也會fail，雖然b本身不一定有錯。解決這個問題，一方面可以削弱指令碼之間的關聯性， 另一方面也可以通過增強指令碼的健壯性來達到。
（3）虛擬使用者pass/fail的標準
虛擬使用者是效能測試工具中的乙個普遍的概念，虛擬使用者負責執行效能測試指令碼，在這裡應該定義虛擬使用者遇到何種情況，選擇fail或pass，即退出或通過。
1.3.4 execution（執行）
本步驟的輸入：場景、交易、虛擬使用者等設定資訊
本步驟的輸出：測試報告
執行測試包含兩個工作：
1．準備測試環境、資料和指令碼
測試環境：硬體平台和軟體平台。
測試資料：包括初始測試資料和測試用例資料兩部分。表現為sql指令碼、excel檔案等。
測試環境直接影響測試效果，所有的測試結果都是在一定軟硬體環境約束下的結果，測試環境不同，測試結果可能會有所不同。需要注意：如果是完全真實的 應用執行環境，要盡可能降低測試對現有業務的影響；如果是建立近似的真實環境，要首先達到伺服器、資料庫以及中介軟體的真實，並且要具備一定的資料量，客戶 端可以次要考慮。實施負載壓力測試時，需要執行系統相關業務，這時需要一些資料支援才可執行業務，這部分資料即為初始測試資料。有時為了模擬不同的虛擬用 戶的真實負載，需要將一部分業務資料引數化，這部分資料為測試用例資料。
測試指令碼：用效能測試工具生成指令碼。
2．執行場景和監控效能
執行效能測試場景，並監控設定好的資料指標，最終生成測試報告。按照定義好的場景pass/fail標準來判斷效能測試是否通過。如果未能通過，進入步驟5（adjust）。
1.3.5 adjust（調整）
本步驟的輸入：測試報告和測試結果資料
本步驟的輸出：效能問題解決方案
調整包含兩個意思：應用程式修改和中介軟體調優。
中介軟體調優可考慮如下因素作業系統調優：
資料庫調優；
記憶體公升級；
cpu數量；
**調優；
cache調優。
解決乙個效能瓶頸，往往又會出現另外的瓶頸或者其他問題，所以效能優化更加切實的目標是做到在一定範圍內使系統的各項資源使用趨向合理和保持一定的平衡。
系統執行良好的時候恰恰也是各項資源達到了乙個平衡體，任何一項資源的過度使用都會造成平衡體系破壞，從而造成系統負載極高或者響應遲緩。比如 cpu過度使用會造成大量程序等待cpu資源，系統響應變慢，等待會造成程序數增加，程序增加又會造成記憶體使用增加，記憶體耗盡又會造成虛擬記憶體使用，使用 虛擬記憶體又會造成磁碟io增加和cpu開銷增加（用於程序切換、缺頁處理的cpu開銷）。
從以上內容可以看出，目前game（a）模型有兩個優勢：第一，靈活，每個過程都有自己的關注點，可以根據不同的專案特點增加或刪除關注點；第二， 通用，不依賴於具體的工具。目前game（a）關注效能測試技術，比較簡單，將來可以進行擴充套件，同樣使用game（a）模型關注效能測試的時間、人力等資 源問題。
通用效能測試過程模型GAME（A）
1.3.1 goal 定義目標 制定乙個明確而詳細的測試目標是效能測試開始的第一步，也是效能測試成功的關鍵。本步驟的輸入 效能需求意向 本步驟的輸出 明確的效能測試目標和效能測試策略 常規的效能測試目標有以下幾種 1 度量終端使用者響應時間 檢視使用者執行業務流程以及從伺服器得到響應所花費的時間。例...
PGTM通用效能測試模型
ptgm通用效能測試模型 一 測試前期準備階段 目標 1.保證系統穩定性 2.建立合適的測試團隊。活動 1.系統基礎功能驗證 類似於bvt測試，確保被測系統已具備進行效能測試的條件。a.效能測試屬於驗收測試一部分 效能測試安排在功能驗收測試之後。b.效能測試不屬於驗收測試 測試之前至少進行一次系統的...
效能測試過程模型
自動化測試生命週期方法，我們稱之為 效能測試過程通用模型 具體如下 1.測試的前期準備階段 a.系統基礎功能驗證，該活動主要確保當前需要進行效能測試的應用已經具備了進行測試的條件 b.組建測試團隊 c.測試工具需求確認 2.測試工具引入階段 a.選擇工具 b.工具應用的技能培訓 c.確定工具的應用過...