性能基準(zhǔn)測試

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

性能基準(zhǔn)測試，會基于固定的硬件環(huán)境和部署架構(gòu)（比如專用的服務(wù)器、固定的專用網(wǎng)絡(luò)環(huán)境、固定大小的集群規(guī)模、相同的系統(tǒng)配置、相同的數(shù)據(jù)庫背景數(shù)據(jù)等），通過執(zhí)行固定的性能測試場景得到系統(tǒng)的性能測試報告，然后與上一版本發(fā)布時的指標(biāo)進行對比，如果發(fā)現(xiàn)指標(biāo)有“惡化”的趨勢，就需要進一步排查。

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

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

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

假設(shè)，通過性能基準(zhǔn)測試的比較結(jié)果得知，用戶登錄的響應(yīng)時間從 2 s 變成了 4 s。

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

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

如果沒有變慢，則說明我們必須嘗試在有壓力的情況下重現(xiàn)這個性能問題。為此，我們要基于用戶登錄的虛擬用戶腳本構(gòu)建并發(fā)測試的場景，但是我們并不清楚在這個場景設(shè)計中到底應(yīng)該采用多少并發(fā)用戶、加入多長的思考時間。這時，通常的做法是，直接采用性能基準(zhǔn)測試中的并發(fā)用戶數(shù)和思考時間，去嘗試重現(xiàn)問題。如果無法重現(xiàn)，我們可以適當(dāng)?shù)刂鸩郊哟鬁y試負(fù)載，并觀察響應(yīng)時間的變化趨勢。

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

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

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

很多大型的傳統(tǒng)軟件公司都有專門的性能測試團隊，這個團隊會建立標(biāo)準(zhǔn)的性能基準(zhǔn)測試場景，并把性能基準(zhǔn)測試的結(jié)果作為產(chǎn)品是否可以發(fā)布的依據(jù)之一。比如，我曾工作過的 HP 軟件，就由性能測試卓越中心負(fù)責(zé)維護、執(zhí)行性能基準(zhǔn)測試，并分析測試結(jié)果。

從性能基準(zhǔn)測試的設(shè)計角度來看，你需要特別注意以下三點：

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

總體的負(fù)載設(shè)計不宜過高，通常被測系統(tǒng)的各類占用率指標(biāo)需要控制在 30% 以內(nèi)，盡量避免由于資源瓶頸引入的操作延時；

每次性能基準(zhǔn)測試前，一般需要對系統(tǒng)資源以及網(wǎng)絡(luò)資源做一輪快速的基準(zhǔn)測試，以保證每次被測環(huán)境的一致性，同時也要保證數(shù)據(jù)庫的數(shù)據(jù)量在同一個級別上。總之，你需要采用一切可能的手段，來確保多次性能基準(zhǔn)測試之間的環(huán)境一致性。

穩(wěn)定性測試

穩(wěn)定性測試，又稱可靠性測試，主要是通過長時間（7*24 小時）模擬被測系統(tǒng)的測試負(fù)載，來觀察系統(tǒng)在長期運行過程中是否有潛在的問題。通過對系統(tǒng)指標(biāo)的監(jiān)控，穩(wěn)定性測試可以發(fā)現(xiàn)諸如內(nèi)存泄漏、資源非法占用等問題。

很多企業(yè)級的服務(wù)器端產(chǎn)品，在發(fā)布前往往都要進行穩(wěn)定性測試。穩(wěn)定性測試，通常直接采用性能基準(zhǔn)測試中的虛擬用戶腳本，但是性能測試場景的設(shè)計和性能基準(zhǔn)測試場景會有很大不同：

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

穩(wěn)定性測試成功完成的標(biāo)志，主要有以下三項：

• 系統(tǒng)資源的所有監(jiān)控指標(biāo)不存在“不可逆轉(zhuǎn)”的上升趨勢；
• 事務(wù)的響應(yīng)時間不存在逐漸變慢的趨勢；
• 事務(wù)的錯誤率不超過 1%。

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

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

最后，需要強調(diào)的一點是，雖然很多時候，尤其是產(chǎn)品版本已經(jīng)逐漸走向成熟期時，穩(wěn)定性測試并不會發(fā)現(xiàn)問題，但是千萬不要小看穩(wěn)定性測試帶來的價值。因為穩(wěn)定性測試一旦發(fā)現(xiàn)問題，那么這些問題都是很嚴(yán)重而且非常隱蔽的大問題。

所以，很多大型的企業(yè)級軟件企業(yè)都會執(zhí)行嚴(yán)格的穩(wěn)定性測試，并把穩(wěn)定性測試的結(jié)果作為產(chǎn)品是否可以發(fā)布的硬性要求。比如，我曾經(jīng)工作過的 HP 軟件研發(fā)中心，它每次產(chǎn)品發(fā)布前都會由專門的性能測試團隊完成嚴(yán)格的穩(wěn)定性測試，并以此來決定是否要發(fā)布這個產(chǎn)品。

并發(fā)測試

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

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

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

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

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

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

容量規(guī)劃測試

容量規(guī)劃測試，是為了完成容量規(guī)劃而設(shè)計執(zhí)行的測試。

那什么是容量規(guī)劃呢？所謂容量規(guī)劃，是軟件產(chǎn)品為滿足用戶目標(biāo)負(fù)載而調(diào)整自身生產(chǎn)能力的過程。

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

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

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

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

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

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

另外，容量規(guī)劃測試的測試結(jié)果還可以被用作系統(tǒng)容量設(shè)計的依據(jù)。比如，企業(yè)級軟件產(chǎn)品的目標(biāo)用戶規(guī)模通常是可以預(yù)估的，那么我們就可以通過這些預(yù)估的系統(tǒng)負(fù)載計算出軟件部署的集群規(guī)模，并且可以在具體實施后通過容量測試的方式進行驗證。

來源:圖文來自網(wǎng)絡(luò)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。