模板
教程
環境
性能
功能
管理
軟件性能測試初步了解
軟件性能測試初步了解
什么是軟件性能
首先澄清的第一個概念是什么是軟件性能，作者分別從用戶視角，管理員視角和開發人員的視角列出下面的問題，這些就是所謂的軟件性能。你有過其中的疑問就是在考慮軟件性能的范疇了，尋求解決方案的過程及其結論(report)就是軟件性能測試
1. 用戶所體會到的系統響應時間是否夠快?
2. 應用服務器的資源使用情況是否合理？
3. 數據庫服務器的資源使用情況是否合理？
4. 系統能最多支持多少用戶的訪問？最大的業務處理量是多少?
5. 系統是否支持 7*24小時的業務訪問？
6. 系統是否能夠實現擴展？更換那些設備可以提高系統性能？
7. 系統的架構設計是否合理？
8. 數據庫設計是否合理？
9. 代碼是否存在性能問題？
10. 內存使用是否合理？
11. 線程同步是否合理？
12. 資源競爭是否合理？
13. 如果存在性能瓶頸，應該如何調整？
幾個主要術語
1. 響應時間 : 響應時間分解為 網絡傳輸時間， 應用延遲時間，數據庫延遲時間，呈現時間。對響應時間的分解是為了方便定位性能瓶頸的所在。
2. 并發用戶數 : 并發用戶數一定要區別于同時在線用戶數。在我們進行測試計劃和測試目標的階段通常會有明確的系統用戶數和同時在線人數的參考依據，但并發用戶數是不確定的。并發是針對某一個或某幾個業務的行為，所以并發用戶數取決于用戶的行為即業務模式。所以確定用戶的行為建立真實的模擬業務場景在性能測試中尤為重要。
3. 吞吐量 : 單位時間內系統處理的客戶請求的數量。 通常以請求數/秒或者頁面數/秒衡量
軟件性能測試方法論
1. SEI Load Testing Planning Process: 是一個關注于負載測試計劃的方法，目標是產生 “清晰，易理解，可驗證的負載測試計劃”. 區別生產環境和測試環境的不同，分析用戶的行為以產生用戶和用戶場景.
2. RBI (Rapid Bottleneck Identify) : 是 Empirix 公司提出的快速識別系統性能瓶頸的方法。首先確定是由并發還是吞吐量引發的性能瓶頸，通過不斷增加并發用戶數和吞吐量觀察系統的性能表現，然后從網絡，數據庫，應用服務器和代碼本身4個環節確定系統性能的瓶頸。
3. 性能下降曲線分析法: 分析隨著用戶數增長響應時間或吞吐量下降的曲線，通過定位性能拐點找到性能瓶頸產生的地方.
4. Load Runner 性能測試過程 : 計劃測試-->測試設計-->創建VU腳本-->創建測試場景-->運行測試場景-->分析結果
5. Segue 性能測試過程: 從確定性能基線開始，通過單用戶訪問獲取性能取值基線，然后設定可接受的性能目標，用不同的并發用戶數進行 Try-Check的重復測試.
軟件性能測試分類
1. 性能測試 : Performance Testing 這是一個容易混淆的概念，通常泛指所有的性能測試。本文特指在特定條件下驗證性能是否達到預期指標的測試為性能測試。
2. 負載測試 : Load Testing 是指模擬真實的用戶行為，通過不斷加壓直到性能出現瓶頸或資源達到飽和。負載測試是我們最經常進行的性能測試，用于測量系統的容量，發現系統瓶頸并配合性能調優。有時候也稱為可量性測試 Scalability Testing.
3. 壓力測試 : Stress Testing 是指測試系統在一定的飽和狀態下系統的處理能力。負載測試的不斷加壓到一定階段即是壓力測試，兩者沒有明確的界限。壓力測試通常設定到CPU使用率達到75%以上，內存使用率達到 70%以上，用于測試系統在壓力環境下的穩定性。此處是指過載情況下的穩定性，略微不同于7*24長時間運行的穩定性。
4. 可靠性測試 : Reliability Testing 是指加載一定的業務壓力，同時讓此壓力持續運行一段時間，測試系統是否可以穩定運行. 可以理解為壓力測試關注的是過載壓力，可靠性測試關注的是持續時間。
5. 并發測試 : Concurrency Testing 是模擬用戶并發訪問同一應用的測試，用于發現并發問題諸如內存泄漏，線程鎖，資源爭用，數據庫死鎖。
6. 配置測試 : Configuration Testing 驗證各種軟,硬件配置對系統性能的影響，用于性能調優和規劃能力.
7. 失效恢復測試 : Failover Testing 針對有冗余備份和負載均衡的系統，檢驗系統局部故障時用戶所受到的影響.
