第九、十、十一、十二這四章是資源監控，因為目前都是開發在協助監控，所以有待后續加強學習。
13.1 性能測試過程概述
在實際的測試過程中，性能測試工具 LoadRunner 只是將性能測試策略轉化為可執行的腳本并產生壓力，但在進行測試前還需要確定性能測試策略，即性能測試設計和構建。整個性能測試過程主要包括4個階段：
性能測試設計：定義待測試的事務流程、事務的平均處理量、事務處理量的最高峰值、組合事務流程、系統的整體用戶和響應時間目標
性能測試構建：涉及設置和配置測試系統及基礎設施、使用自動化性能測試解決方案構建測試腳本和附在方案
性能測試執行：包括運行負載方案和測量系統性能
性能測試分析、診斷、調節：主要測量系統性能并使負載測試進入下一級別，重點查找問題原因以幫助開發工程師解決問題，并實時調節系統參數以提高性能
13.2 性能測試設計
設計階段是性能測試團隊與事務領域的精力合作以收集性能要求的主要事務響應時間。可以將需要關注的問題分為4個方面：事務需求、技術需求、系統要求和團隊要求，分析時主要從5個方面：需求調研、事務模型、場景模型、數據設計和環境設計，其中事務模型是該階段中最重要的。
13.2.1 需求調研
確定本次性能測試的對象以及被測對象的一些屬性，主要包括及部分工作：
（1）測試系統預研
根據被測系統的資料，了解相關知識，技術架構、業務架構等。這個階段需要完成的工作有：
? ? 確定被測系統的開發組織和負責人
? ? 向項目經理申請被測試系統相關資料
? ? 一些其他的例外情況溝通
（2）與項目經理訪談
獲取性能測試實施工作開展的相關信息、當前開發狀態和期望的性能目標，包括性能測試實施起止時間和被測系統所處的生命周期。
（3）與業務專家訪談
獲取性能測試業務模型設計的相關數據，如：關鍵業務、主要用戶場景、交易發生概率、期望響應時間等業務層面信息，此外還需要從業務團隊獲得相關業務工程師來支持后續腳本開發，避免開發失敗或出現錯誤。
關鍵業務的判斷：
a. 使用頻率：指客戶操作該業務的頻率，該值越大說明失效的概率越大；
b. 優先級：指業務的等級，該值越高說明客戶操作該業務的概率越大，從業務角度來說，核心業務和基本業務的優先級比較高；
c. 占用資源情況：操作一次該業務對系統資源消耗的情況，如果消耗高，那么可能讓系統處于高負荷的運行狀態，這樣業務失效的風險就變大了；
（4）與技術專家訪談
a. 獲取關鍵業務的技術路徑；
b. 獲取合適的支持工程師；
c. 請技術專家確定關鍵業務是否覆蓋到被測試系統的所有業務請求點；
d. 確定這些業務所使用到的關鍵數據庫表；
e. 監控階段，技術支持人員配合實施監控配置工作；
f. 一些特殊技術的支持，如加解密等；
（5）與數據庫管理員訪談
獲取數據準備和測試數據建模的建議，主要包括：
a. DBA 輔助進行數據庫的備份與恢復工作；
b. 為數據建模提供建議；
c. 為建基礎數據模型做準備；
（6）與客戶代表訪談
獲取用戶在業務建模上的支持，保證業務流程的正確性。
13.2.2 業務模型
主要用于指導如何將具體的業務變成可重復運行的代碼，主要從以下3個方面分析：
業務流程列表：
創建關鍵業務流程列表，以反映最終用戶在系統上執行的活動。業務流程表需要反映每個業務在高峰期時操作的用戶數，主要來源于后臺的歷史數據。
交易列表：
交易業務流程需要確定關鍵業務的負載情況、交易量等相關信息。通過交易列表可以確定業務的優先級。
日常業務：可以通過后臺數據來統計，可以分析3個月、半年或一年的數據，得到這些業務每小時或每秒操作的筆數。
高峰期業務：選擇峰值情況下，單位時間內業務操作的筆數。
風險：是指當該業務失效或發生錯誤時對客戶的影響。
百分比模型：
指被測試的業務交易筆數所占整個業務交易筆數的百分比
交易量評估：
通過歷史數據來估算系統負載能力，通常使用80/20原理。指的是每個工作日中80%的業務在20%的時間內完成。每年業務集中在8個月，每個月集中在20個工作日完成，每個工作日8h，每天80%的業務在1.6h完成。
13.2.3 場景模型
主要用于指導在控制器中如何進行場景設計和場景監控。
場景設計需要確定的內容主要包括：使用的場景設計類型（手動場景或目標場景）、并發用戶數、虛擬用戶加載過程、腳本持續運行時間、虛擬用戶釋放過程、使用的負載機、IP欺騙技術和 RTS 的設置。
13.2.4 數據設計
確定在整個性能測試過程中需要使用的數據，一是性能測試前需要準備的基礎數據；二是性能測試過程中參數化所需要用到的數據。
基礎數據的不同直接影響到性能測試的結果，如查詢功能，數據庫中已存在100條記錄和已存在100萬條記錄，查詢的響應時間肯定是不同的，所以這需要在測試前確定。
參數化需要使用到的數據也分兩種：一是為自己構建的數據；二是歷史數據。構建數據是測試過程中通過一些方法生成批量數據，通常用 Ultraedit 結合 Excel 制作、數據庫獲取、Shell 編程和 Java 編程，目前我們只用到前兩種方法。
歷史數據則是真實存在的數據，可調用客戶的真實數據，也可以事先制作，它們一般都是存儲在 DB 里的，所以需要用 SQL 關聯參數的方式來獲取。
不管是哪種數據，我們都應該遵循幾個原則：
1、全面性
指設計的數據應該包含所有類型的數據，需要覆蓋客戶操作過程中所有類型的數據。
2、無約束性
指數據與數據之間不能存在相互約束的現象。
3、正確性
指設計的數據應該保證業務能被正確地運行，因為性能測試的目的是測試業務的響應時間，而非測試功能測試，所以設計數據時，不能因為人為的原因導致業務操作失敗，如果是數據導致業務失敗，那么在結果分析過程中分析事務的成功率就不準確了，導致影響整個性能測試的結果。
4、數據量充足
準備的數據是否充足也會影響到性能測試結果，比如在一些業務場景中，因為數據量不夠，導致準備的數據比腳本迭代的次數少，那么將會重新循環或一直使用最后一個數據，這樣就容易導致一些業務失敗。
5、無敏感數據
安全性是軟件特性中的一個很重要的維度，在設計數據進行性能測試時，需要注意避免一些敏感數據，即使使用，也應該用密文顯示而非明文。
13.2.5 環境設計
環境設計主要是確定性能測試執行過程中服務器和測試機所處的環境，包括三部分內容：
系統運行的拓撲結構圖：用于指導如何搭建測試環境
服務器和測試機環境：一是服務器和測試機的硬件配置；二是服務器和測試機的軟件配置；服務器的硬件配置是一個基準環境，而負載機的硬件測試配置則受每個VUser 運行時所消耗的內存資源的影響；
環境的備份與恢復：需要這么做有兩個原因：
（1）測試前如果環境不確定，可能會導致一些數據運行失敗，進而導致一些業務運行失敗；
（2）如果不及時恢復環境，會影響到手工測試的數據，所以建議性能測試環境和手工測試環境剝離開來，我們目前就是用虛擬機作為手工測試環境，物理機環境用于性能測試；
13.3 性能測試構建
性能測試設計完成后，需要將設計的策略變成現實，這樣才能執行性能測試。構建階段需要完成以下幾個方面的工作：
13.3.1 腳本開發
下面這個表是腳本開發檢查點，在實際應用中，可以將它與腳本規范檢查合二為一。
13.3.2 場景設計
場景設計就是將場景模型轉化為場景策略的過程。主要包括：場景策略、負載機、RTS、集合點設置。該過程也可以采用 Checklist 方式保證質量。
13.3.3 搭建測試環境
根據環境設計策略搭建需要執行測試時的環境，一是搭建環境，二是審核環境。
13.3.4 準備數據
指根據數據設計的策略生成測試過程中需要的數據，其中包含兩類數據：一是基礎數據；二是測試過程中需要參數化的數據。基礎數據一般都存在數據庫中，但對于參數化過程中需要使用的數據則不一定是存儲在數據庫中，可能存儲在不同的載體中，那么在存儲這些參數化過程中使用的數據時，選擇的載體很重要，因為不同的載體會影響到參數化的技術。
13.4 性能測試過程執行
根據性能測試的策略不同，性能測試執行策略也有所不同，并且一般需要執行多次才能達到目的。
13.5 性能測試分析、診斷、調節
在完成負載測試的設計、構建和執行階段后，項目將進入分析、診斷和調節階段，這一階段是實時和反復進行的，負載測試解決方案應該提供有關最終用戶、系統級別和代碼性能數據的全面信息，同時查找導致性能降低的可能原因，這些信息能使你確定是否已經達到性能目標。
（1）監控。可顯示基礎設備每個層上所發生的一切，同時會更清晰地提供有關測試中數據庫服務器、Web服務器、應用程序服務器、單個應用程序或流程的信息。
（2）分析。將各種指標關聯起來，以獲取有關應用程序行為的其他信息。
（3）診斷。高效的性能測試解決方案應該向性能工程師提供有關層、組件、SQL語句是如何影響負載業務流程整體性能的單個統一視圖，性能工程師能看到由最終用戶交易所接觸到的所有組件，然后確定各組件使用的處理時間及調用次數。
（4）有些自動化性能測試解決方案可系統地識別并分離基礎設施性能瓶頸，然后通過修改系統配置設定來解決它們，通過反復解決基礎設施性能瓶頸，可以不斷改進配置。
