1、和產品溝通，提供的核心功能是什麼 2、和開發溝通，通常效能存在哪些地方 3、檔案操作，資料庫操作注意 原則：模擬所有可能發生的最極端情況

效能測試實施步驟 1、規劃測試 2、建立vuser指令碼 3、建立方案 4、執行方案 5、監視方案 6、分析測試結果

效能測試範圍的定義 1、和整個開發團隊一起確認效能測試的範圍 2、系統中被頻繁使用的功能，呼叫的介面 3、系統中涉及到大量資料庫讀寫功能 4、大量讀寫系統快取部分的功能

效能測試目的 1、驗證改進的效能效果，需要和以前的測試結果進行比對 2、新的業務上線，驗證新系統能夠滿足系統的上線指標 3、驗證系統的穩定性 4、驗證系統的架構是否存在瓶頸

效能測試環境搭建 效能測試環境：     --硬體環境：參考實際生產環境搭建，考慮自身硬體成本     --軟體環境：儘量和生產環境使用的版本和配置保持一致，並儘可能採用最優配置     --網路環境：儘可能參考生產環境的網路結構和搭建，儘可能不要跨多個網段 最優的效能測試環境：     --就是即將正式上線使用的生產環境      資料庫中的基礎資料的準備 -基礎資料的內容和資料量：     -需要參考具體系統的業務內容和使用規模     -類似系統的資料量規模     -儘可能多增加一定比例的冗餘資料，資料庫直接新增，指令碼寫 基礎資料準備方法：     -資料庫儲存過程     -LoadRunner，selenium等自動化測試工具     

效能測試完成的目標 1、新上線的測試系統沒有明確的數字標準比對情況下，北側是系統已經被測試到了系統極限（系統的某些資源已經耗盡，cpu,控制代碼，記憶體，資料庫出現大量的slow query，系統有些處理已經變慢），比關切系統證明是可以水平擴充套件的，則可以上線 2、有以往測試結果進行比對，只要證明類似的測試條件下，此次的結果比以往的測試結果更好即可（每秒處理個數更多，單次請求的處理速度更快） 3、美喲可以比較的測試結果，但是產品已經上線一段時間（至少3個月），有一些運營資料，則需要分析運營的資料來作為比對的基準，只要被測系統達到3個月內系統併發峰值的4倍就可以認為是可接受的（如果是介面為測試物件，則需要混合主要的介面來進行效能測試） 4、開發人員提供經驗值作為比對的基準，則北側物件只要證明滿足開發人員提出的經驗值即可 如果選擇以上的某一種策略，則必須明確系統的每秒處理個數和每次請求的平均時間的具體數值，並出具最終的效能測試報告。

Loadrunner的指令碼工作 錄製基本的Vuser指令碼 增強並編輯指令碼：指令碼問題，如何修改，看日誌，檢查點，關鍵字檢查（對頁面某些變數檢查，因為每次請求返回200表示收到請求成功，但是不一定該執行的就執行了） 配置執行時設定 以獨立模式執行Vuser指令碼 指令碼整合到LoadRunner方案中

效能測試的指令碼除錯 1、錄製或者編寫效能測試指令碼 2、修改測試指令碼，使用隨機化策略 3、除錯和執行指令碼，檢視log和資料庫內容等方式驗證指令碼正確性

效能測試指令碼的執行 1、設計好特定的效能測試場景 2、初始的壓力執行緒數 3、逐步加壓的策略 4、測試執行結束條件 5、結束時的停止多執行緒的方式 注：加壓的壓力測試機器和被測試物件最好在一個區域網段

效能測試的資料收集 1、測試用例編號 2、測試時間 3、併發數 4、成功請求數 5、失敗請求數 6、平均每秒處理個數 7、平均每個請求處理時間 8、方差 9、備註：關閉防火牆考慮

10、響應時間小於1s的請求個數 11、響應時間超過1s小於2s的請求個數 12、響應時間超過2s小於3s的請求個數 13、響應時間超過3s小於4s的請求個數 14、響應時間超過4s小於5s的請求個數 15響應時間超過5s的請求個數

效能測試資料分析 1、分析系統性能瓶頸 2、驗證是否資料滿足效能測試完成條件 3、整理測試報告，彙總效能測試資料，整理效能測試結果，給出測試結論 4、和整個開發團隊確認測試結果 （當前cpu處理的併發請求個數，排隊，系統是否產生延時：load average<cpu核數*0.7，沒有排隊，來多少處理多少，load average>cpu核數*0.7，可能出現負載，延時）

經驗和教訓的總結 1、總結本次出現的效能問題的原因和問題解決方法，作為團隊的只是積累 2、總結測試過程中出現的流程，溝通，技術等問題，並進行相關流程的優化

----------個人學習筆記