最近看了《捉蟲記——大容量Web應用效能測試與LoadRunner實戰》，關於Web端測試和LoadRunner的基本使用做一點筆記，後面可以再補充學習。

強調一點，平臺測試也很重要，就是指不同作業系統下的不同版本，eg：windows下不同版本對於瀏覽器播放外掛的相容、支援方式等都會有差別，所以這不僅僅是瀏覽器的測試，平臺測試也很重要

Web效能測試方法（這裡是廣義的效能測試）

• 效能測試（這裡是狹義的效能測試）：
  
  1. 響應時間：業界標準——3/5/10原則，即在3s內響應並顯示是”不錯的“；在3-5s內響應並顯示是”好的“；在5-10s內是”勉強可以接受的“；超過10s一般使用者會放棄等待
  2.
• 壓力測試：對系統施壓，是系統資源佔有保持在一個事先約定的水平（eg：cup佔比：75%），來檢驗系統的表現
• 負載測試：不斷對系統增加負荷，直到找到系統不可用臨界點的過程，即找到系統處理能力的極限
• 併發測試：重點關注記憶體洩漏、資源爭用、執行緒控制（鎖）
• 配置測試：不斷調整軟硬體引數，最終定位最優配置
• 可靠性測試/耐久度測試
• 尖峰衝擊測試：針對某一時刻，使用者數量突然暴增的情形，一般用工具LoadRunner模擬
• 失敗恢復測試：針對網站突然訪問故障的情形，一般採用冗餘備份、負載均衡來改善

效能測試計數器

• windows下輸入perfmon，檢視效能計數器
• 記憶體洩漏：效能測試的重點
  
  • 使用效能計數器觀察資料變化
  • 專業軟體：CLRProfiler、Pfmon（page fault monitor）等
• 怎麼判斷是否產生記憶體洩漏？

LoadRunner的使用：VuGen + 控制器 + 分析器

• Virtual User Generator（VuGen）虛擬使用者生成器

  • 錄製Recording：記錄一個真實使用者的行為，會生成指令碼。提供兩個錄製協議：HttP/HTML、Click and Script；錄製過程要考慮Think Time，加入等待時間。
  • 驗證Replay：執行驗證錄製所得指令碼。可能會出現驗證失敗，原因：因為錄製時生成一個SessionID，錄製結束，會話失效，驗證播放時，使用錄製時的SessionID，會被系統拒絕，導致報錯。解決方案
    ：利用關聯Correlation，一般SessionID會以隱藏域的形式存在網頁中，通過關聯選取出此隱藏域的資料，並用指令碼引數的形式存放，避免成為硬編碼（“寫死”），當需要使用SessionID時，用指令碼引數替換即可。
  • 強化Enhancements：修改指令碼
  • 準備負載工作：模擬真實使用者，虛擬出多個使用者
    
    • 迭代：General 》 Run Logic node，同一個操作不斷迴圈
    • 併發：常用這個，通過設定不同的場景來完成，同時請求web應用的使用者數量，與場景密切相關
  • 完成階段

• 控制器Controller：場景和虛擬使用者組的生成和配置：設定場景並新增監控，為指令碼新增函式

  • Manual Scenario人工場景（自定義模式）和 Goal Oriented Scenario面向目標場景（嚮導模式）
  • 面向目標場景的測試目標：虛擬使用者數、每秒點選數、每秒事務數、每分鐘訪問頁面數、事務響應時間
  • 手工場景（先design設計再run執行）：兩種方式設定：使用者組方式、分佈百分比方式
    
    • 集合點：測試併發操作效能，直接在錄製後生成的指令碼中，對應action部分，放置游標，插入集合點。集合點發揮作用，一般是規定在這個集合點上要集合多少個虛擬使用者

• 分析器Analysis：用於分析場景執行結果：LoadRunner會自動生成測試結果概要Analysis Summary頁面並自動開啟分析器，分析概要包括SLA（服務質量協議，實際上是某項指標的期望值）概要、事務概要、HTTP響應概要等