性能基準測試

性能基準測試，通常被稱為 Performance Benchmark Test，是每次對外發布產品版本前必須要完成的測試類型。

性能基準測試，會基于固定的硬件環境和部署架構（比如專用的服務器、固定的專用網絡環境、固定大小的集群規模、相同的系統配置、相同的數據庫背景數據等），通過執行固定的性能測試場景得到系統的性能測試報告，然后與上一版本發布時的指標進行對比，如果發現指標有“惡化”的趨勢，就需要進一步排查。

典型的“惡化”趨勢，主要表現在以下幾個方面：

• 同一事務的響應時間變慢了。比如，上一版本中，用戶登錄的響應時間是 2 s，但是在最新的被測版本中這個響應時間變成了 4 s；
• 系統資源的占用率變高了。比如，上一版本中，平均 CPU 占用率是 15%，但是在最新的被測版本中平均 CPU 占用率變成了 30%；
• 網絡帶寬的使用量變高了。比如，上一版本中，發送總字節數是 20 MB，接收總字節數是 200 MB，但是在最新的被測版本中發送總字節數變成了 25 MB，接收總字節數變成了 250 MB。

這里需要注意的是，這些“惡化”趨勢的前提是：完全相同的環境以及測試負載。不同“惡化”指標的排查，有不同的方法。我以最常見的事務響應時間變慢為例，和你說明一下排查方法。

假設，通過性能基準測試的比較結果得知，用戶登錄的響應時間從 2 s 變成了 4 s。

那么，我們首先要做的是驗證在單用戶的情況下，是否會出現響應時間變長的問題。具體做法是，將用戶登錄的虛擬用戶腳本單獨拿出來，建立一個單用戶運行的性能測試場景并執行，觀察用戶登錄的響應時間是否變慢。

如果變慢了，就說明這是單用戶登錄場景就可重現的性能問題，后續的處理也相對簡單了。解決方法是：分析單用戶登錄的后端日志文件，看看完成登錄操作的時間具體都花在了哪些步驟上，相比之前哪些步驟花費的時間變長了，或者是多出了哪些額外的步驟。

如果沒有變慢，則說明我們必須嘗試在有壓力的情況下重現這個性能問題。為此，我們要基于用戶登錄的虛擬用戶腳本構建并發測試的場景，但是我們并不清楚在這個場景設計中到底應該采用多少并發用戶、加入多長的思考時間。這時，通常的做法是，直接采用性能基準測試中的并發用戶數和思考時間，去嘗試重現問題。如果無法重現，我們可以適當地逐步加大測試負載，并觀察響應時間的變化趨勢。

這里需要注意的是，千萬不要使用過大的測試負載。因為測試負載過大的話，系統資源也會成為性能瓶頸，一定會使響應時間變長。但這時，響應時間變長主要是由資源瓶頸造成的，而不是你開始要找的那個原因。

如果此時可以重現問題，那就可以進一步去分析并發場景下，用戶登錄操作的時間切片，找到具體的原因。如果此時還是不能重現問題的話，情況就比較復雜了，也就是登錄操作的性能可能和其他的業務操作存在依賴，或者某種資源競爭關系，這就要具體問題具體分析了。

一般來說，當定位到性能“惡化”的原因并修復后，我們還會再執行一輪性能基準測試，以確保系統對外發布前的性能基準測試指標沒有“變壞”。可以說，通過對每個預發布版本的性能基準測試，我們可以保證新發布系統的整體性能不會下降，這也就是性能基準測試最終要達到的目的。

很多大型的傳統軟件公司都有專門的性能測試團隊，這個團隊會建立標準的性能基準測試場景，并把性能基準測試的結果作為產品是否可以發布的依據之一。比如，我曾工作過的 HP 軟件，就由性能測試卓越中心負責維護、執行性能基準測試，并分析測試結果。

從性能基準測試的設計角度來看，你需要特別注意以下三點：

性能基準測試中虛擬用戶腳本的選擇以及配比，需要盡可能地匹配實際的負載情況；

總體的負載設計不宜過高，通常被測系統的各類占用率指標需要控制在 30% 以內，盡量避免由于資源瓶頸引入的操作延時；

每次性能基準測試前，一般需要對系統資源以及網絡資源做一輪快速的基準測試，以保證每次被測環境的一致性，同時也要保證數據庫的數據量在同一個級別上。總之，你需要采用一切可能的手段，來確保多次性能基準測試之間的環境一致性。

穩定性測試

穩定性測試，又稱可靠性測試，主要是通過長時間（7*24 小時）模擬被測系統的測試負載，來觀察系統在長期運行過程中是否有潛在的問題。通過對系統指標的監控，穩定性測試可以發現諸如內存泄漏、資源非法占用等問題。

很多企業級的服務器端產品，在發布前往往都要進行穩定性測試。穩定性測試，通常直接采用性能基準測試中的虛擬用戶腳本，但是性能測試場景的設計和性能基準測試場景會有很大不同：

一般是采用“波浪式”的測試負載，比如先逐漸加大測試負載，在高負載情況下持續 10 多個小時，然后再逐漸降低負載，這樣就構成了一個“波浪”，整個穩定性測試將由很多個這樣的波浪連續組成。

穩定性測試成功完成的標志，主要有以下三項：

• 系統資源的所有監控指標不存在“不可逆轉”的上升趨勢；
• 事務的響應時間不存在逐漸變慢的趨勢；
• 事務的錯誤率不超過 1%。

實際工程項目中，由于穩定性測試執行的時間成本很高，往往需要花費 3~7 天的時間，所以我們一般是在其他所有測試都已經完成，并且所有問題都已經修復之后才開始穩定性測試。

另外，有些企業為了縮短穩定性測試的執行時間，往往還會采用“時間軸壓縮”的方法，具體的做法就是：在加大測試負載的前提下，適當縮短每個“波浪”的時間，從而減少整體的測試執行時間。

最后，需要強調的一點是，雖然很多時候，尤其是產品版本已經逐漸走向成熟期時，穩定性測試并不會發現問題，但是千萬不要小看穩定性測試帶來的價值。因為穩定性測試一旦發現問題，那么這些問題都是很嚴重而且非常隱蔽的大問題。

所以，很多大型的企業級軟件企業都會執行嚴格的穩定性測試，并把穩定性測試的結果作為產品是否可以發布的硬性要求。比如，我曾經工作過的 HP 軟件研發中心，它每次產品發布前都會由專門的性能測試團隊完成嚴格的穩定性測試，并以此來決定是否要發布這個產品。

并發測試

并發測試，是在高并發情況下驗證單一業務功能的正確性以及性能的測試手段。高并發測試一般使用思考時間為零的虛擬用戶腳本來發起具有“集合點”的測試。

“集合點”的概念，我已經在《聊聊性能測試的基本方法與應用領域》中解釋過了。如果你不清楚的話，可以再回顧一下這篇文章。如果你還有不理解的地方，也歡迎和我留言討論。

并發測試，往往被當作功能測試的補充，主要用于發現諸如多線程、資源競爭、資源死鎖之類的錯誤。要執行并發測試，就需要加入“集合點”，所以往往需要修改虛擬用戶腳本。

加入“集合點”一般有兩種做法：

在虛擬用戶腳本的錄制過程中直接添加；

在虛擬用戶腳本中，通過加入 lr_rendezvous() 函數添加。

容量規劃測試

容量規劃測試，是為了完成容量規劃而設計執行的測試。

那什么是容量規劃呢？所謂容量規劃，是軟件產品為滿足用戶目標負載而調整自身生產能力的過程。

所以，容量規劃的主要目的是，解決當系統負載將要達到極限處理能力時，我們應該如何通過垂直擴展（增加單機的硬件資源）和水平擴展（增加集群中的機器數量）增加系統整體的負載處理能力的問題。

目前來講，容量規劃的主要方法是基于水平擴展。但是，具體應該增加多少機器，以及增加后系統的負載處理能力是否會線性增長，這些問題都需要通過容量規劃測試進行驗證。

那么，容量規劃測試具體要怎么做呢？

我們可以使用性能基準測試中的虛擬用戶腳本，以及各個業務操作腳本的百分比，壓測單機部署的被測系統。我們會采用人工的方式不斷增加測試負載直到單機系統的吞吐量指標到達臨界值，由此就可以知道單臺機器的處理能力。

理論上講，整個集群的處理能力將等于單臺機器的處理能力乘以集群的機器數，但是實際情況并不是這樣。實際的集群整體處理能力一定小于這個值，但具體小多少就是要靠實際的測試驗證了。

理想的狀態是，集群整體的處理能力能夠隨著集群機器數量的增長呈線性增長。但是，隨著機器數量的不斷增長，總會在達到某個臨界值之后，集群的整體處理能力不再繼續呈線性增長。這個臨界值是多少，我們也需要通過容量規劃測試找出來了。

另外，容量規劃測試的測試結果還可以被用作系統容量設計的依據。比如，企業級軟件產品的目標用戶規模通常是可以預估的，那么我們就可以通過這些預估的系統負載計算出軟件部署的集群規模，并且可以在具體實施后通過容量測試的方式進行驗證。

來源:圖文來自網絡

總結

以上是生活随笔為你收集整理的怎么测试网络带宽_性能测试案例与经验分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。