《JMeter實戰》第二章 效能測試初體驗 摘錄

• 設計模型：圈定效能測試範圍後，把業務模型對映成測試模型。什麼是測試模型呢？比如一個支付系統需要與銀行的系統要進行互動，由於銀行不能提供支援，我們就要開發程式去代替銀行系統功能（這就是擋板程式，Mock程式），保證此功能的效能測試能夠開展；這個過程就是設計測試模型。用例只關注業務，模型還需關注如何實現，是否具有可操作性，可驗證性，最後根據不同的測試目的組合成不同的測試場景。
• 計劃編寫：範圍，資源，時間，工作內容，風險。
• 測試資料準備：存量、歷史業務資料，考慮數量與分佈。
• 測試執行： 同樣指令碼不同執行人員得出的結果可能差異較大，差異主要體現在場景設計與測試執行上。

效能測試成功與失敗要素

• 效能測試有幾大難點：需求分析，場景設計，效能診斷調優，環境搭建和模擬
• 失敗原因：需求分析方面沒有做到位，不能準確地預估使用者行為，在場景上不能復現使用者操作，無法把需求體現在指令碼和場景設計上，無法模擬真實的系統負載。
• 效能測試要點：

1. 評估系統，需求分析: 對於初次上線的系統，需要用同行的系統資料，進行使用者行為分析和商業資料結構的估演算法推算出要驗證的模型的能力對於已經上線的系統，通過運維人員獲取TPS和時間的比例分佈圖，使用者數和時間的分佈圖，資料庫ER關係圖，容量資料等精確得出效能需求。

2. 場景設計、用例設計: 如何有效地組織測試用例？按業務分佈，業務量，業務時段，業務角色來綜合分配使用者數、執行時間、執行比例等。

3.   測試執行、是否通過

4. 效能診斷優化

不同角色看效能

1. 黑盒測試只關心應用程式的單步響應時間：操作應用介面->資料請求經過網路傳送->伺服器前端接收處理->在DB Server獲取相關資料->前端處理後返回資料->應用介面收到資料響應下一步。

2. 開發：架構合理性，資料庫設計合理性，程式碼，系統裡記憶體的使用方式，系統裡執行緒使用方式，系統資源是否有惡性，不合理競爭

3. 系統管理員：硬體資源利用率，JVM, DB,換哪些硬體能提高系統效能，系統能否支援7*24的服務，擴充套件性、相容性、最大容量、可能的瓶頸

4. 效能測試：伺服器硬體效能，根據需求和歷史資料制定效能目標，建立效能通過模型，對開發程式碼框架和硬體框架進行效能分析，針對開發釋出版本的基準測試，執行軟體效能驗收及穩定性測試，生產環境的配置和優化，制定效能測試的場景設計，協調各部門配合，特定的效能分析

效能測試工具選擇

專業、穩定、高效，簡單易上手，在測試指令碼上不用花太多時間，有技術支援，文件完善，不用在疑難問題上花費時間，集中精力在效能分析上，要考慮投入產出比。

效能測試相關術語

1. 負載：模擬業務操作對伺服器造成壓力的過程。
2. 效能測試：模擬使用者負載來測試系統在負載情況下，系統的響應時間、吞吐量等指標是否滿足效能要求。
3. 負載測試：在一定軟體環境下，通過不斷加大負載來確定在滿足效能指標情況下能夠承受的最大使用者數。
4. 配置測試：為了合理地調配資源，提高系統執行效率，通過測試手段來獲取、驗證、調整配置資訊的過程。
5. 壓力/強度測試：在一定軟硬體環境下，通過高負載的手段來使伺服器資源處於極限狀態，測試系統在極限狀態下長時間執行是否穩定，確定是否穩定的指標包括TPS, RT, CPU Using, Mem Using等。
6. 穩定性測試： 在一定軟硬體環境下，長時間執行一定負載，確定系統在滿足效能指標的前提下是否執行穩定。
7. TPS：每秒完成的事務數（成功）
8. RT/ART: 響應時間/平均響應時間，指一個事務花費多長時間完成。
9. PV(Page View）：每秒使用者訪問頁面的次數
10. Vuser虛擬使用者：模擬真實業務邏輯步驟的虛擬使用者。
11. 併發：狹義的併發即所有的使用者在同一時刻做同一件事情或操作。廣義的併發即多個使用者對系統發出了請求或者進行了操作，但這些請求或操作可以是不同的。

效能測試通過標準