性能測試案例與經(jīng)驗(yàn)分享
性能基準(zhǔn)測試
性能基準(zhǔn)測試，通常被稱為 Performance Benchmark Test，是每次對(duì)外發(fā)布產(chǎn)品版本前必須要完成的測試類型。
性能基準(zhǔn)測試，會(huì)基于固定的硬件環(huán)境和部署架構(gòu)（比如專用的服務(wù)器、固定的專用網(wǎng)絡(luò)環(huán)境、固定大小的集群規(guī)模、相同的系統(tǒng)配置、相同的數(shù)據(jù)庫背景數(shù)據(jù)等），通過執(zhí)行固定的性能測試場景得到系統(tǒng)的性能測試報(bào)告，然后與上一版本發(fā)布時(shí)的指標(biāo)進(jìn)行對(duì)比，如果發(fā)現(xiàn)指標(biāo)有“惡化”的趨勢，就需要進(jìn)一步排查。
典型的“惡化”趨勢，主要表現(xiàn)在以下幾個(gè)方面：
①同一事務(wù)的響應(yīng)時(shí)間變慢了。
比如，上一版本中，用戶登錄的響應(yīng)時(shí)間是 2 s，但是在最新的被測版本中這個(gè)響應(yīng)時(shí)間變成了 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í)間變慢為例，和你說明一下排查方法。
假設(shè)，通過性能基準(zhǔn)測試的比較結(jié)果得知，用戶登錄的響應(yīng)時(shí)間從 2 s 變成了 4 s。
那么，我們首先要做的是驗(yàn)證在單用戶的情況下，是否會(huì)出現(xiàn)響應(yīng)時(shí)間變長的問題。具體做法是，將用戶登錄的虛擬用戶腳本單獨(dú)拿出來，建立一個(gè)單用戶運(yùn)行的性能測試場景并執(zhí)行，觀察用戶登錄的響應(yīng)時(shí)間是否變慢。
如果變慢了，就說明這是單用戶登錄場景就可重現(xiàn)的性能問題，后續(xù)的處理也相對(duì)簡單了。解決方法是：分析單用戶登錄的后端日志文件，看看完成登錄操作的時(shí)間具體都花在了哪些步驟上，相比之前哪些步驟花費(fèi)的時(shí)間變長了，或者是多出了哪些額外的步驟。
如果沒有變慢，則說明我們必須嘗試在有壓力的情況下重現(xiàn)這個(gè)性能問題。為此，我們要基于用戶登錄的虛擬用戶腳本構(gòu)建并發(fā)測試的場景，但是我們并不清楚在這個(gè)場景設(shè)計(jì)中到底應(yīng)該采用多少并發(fā)用戶、加入多長的思考時(shí)間。這時(shí)，通常的做法是，直接采用性能基準(zhǔn)測試中的并發(fā)用戶數(shù)和思考時(shí)間，去嘗試重現(xiàn)問題。如果無法重現(xiàn)，我們可以適當(dāng)?shù)刂鸩郊哟鬁y試負(fù)載，并觀察響應(yīng)時(shí)間的變化趨勢。
這里有一點(diǎn)需要注意，千萬不要使用過大的測試負(fù)載。因?yàn)闇y試負(fù)載過大的話，系統(tǒng)資源也會(huì)成為性能瓶頸，一定會(huì)使響應(yīng)時(shí)間變長。但這時(shí)，響應(yīng)時(shí)間變長主要是由資源瓶頸造成的，而不是你開始要找的那個(gè)原因。
如果此時(shí)可以重現(xiàn)問題，那就可以進(jìn)一步去分析并發(fā)場景下，用戶登錄操作的時(shí)間切片，找到具體的原因。如果此時(shí)還是不能重現(xiàn)問題的話，情況就比較復(fù)雜了，也就是登錄操作的性能可能和其他的業(yè)務(wù)操作存在依賴，或者某種資源競爭關(guān)系，這就要具體問題具體分析了。
一般來說，當(dāng)定位到性能“惡化”的原因并修復(fù)后，我們還會(huì)再執(zhí)行一輪性能基準(zhǔn)測試，以確保系統(tǒng)對(duì)外發(fā)布前的性能基準(zhǔn)測試指標(biāo)沒有“變壞”。可以說，通過對(duì)每個(gè)預(yù)發(fā)布版本的性能基準(zhǔn)測試，我們可以保證新發(fā)布系統(tǒng)的整體性能不會(huì)下降，這也就是性能基準(zhǔn)測試最終要達(dá)到的目的。
很多大型的傳統(tǒng)軟件公司都有專門的性能測試團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)會(huì)建立標(biāo)準(zhǔn)的性能基準(zhǔn)測試場景，并把性能基準(zhǔn)測試的結(jié)果作為產(chǎn)品是否可以發(fā)布的依據(jù)之一。比如，我曾工作過的 HP 軟件，就由性能測試卓越中心負(fù)責(zé)維護(hù)、執(zhí)行性能基準(zhǔn)測試，并分析測試結(jié)果。
從性能基準(zhǔn)測試的設(shè)計(jì)角度來看，你需要特別注意以下三點(diǎn)：
①性能基準(zhǔn)測試中虛擬用戶腳本的選擇以及配比，需要盡可能地匹配實(shí)際的負(fù)載情況；
②總體的負(fù)載設(shè)計(jì)不宜過高，通常被測系統(tǒng)的各類占用率指標(biāo)需要控制在 30% 以內(nèi)，盡量避免由于資源瓶頸引入的操作延時(shí)；
③每次性能基準(zhǔn)測試前，一般需要對(duì)系統(tǒng)資源以及網(wǎng)絡(luò)資源做一輪快速的基準(zhǔn)測試，以保證每次被測環(huán)境的一致性，同時(shí)也要保證數(shù)據(jù)庫的數(shù)據(jù)量在同一個(gè)級(jí)別上。總之，你需要采用一切可能的手段，來確保多次性能基準(zhǔn)測試之間的環(huán)境一致性。
穩(wěn)定性測試
穩(wěn)定性測試，又稱可靠性測試，主要是通過長時(shí)間（7*24 小時(shí)）模擬被測系統(tǒng)的測試負(fù)載，來觀察系統(tǒng)在長期運(yùn)行過程中是否有潛在的問題。通過對(duì)系統(tǒng)指標(biāo)的監(jiān)控，穩(wěn)定性測試可以發(fā)現(xiàn)諸如內(nèi)存泄漏、資源非法占用等問題。
很多企業(yè)級(jí)的服務(wù)器端產(chǎn)品，在發(fā)布前往往都要進(jìn)行穩(wěn)定性測試。穩(wěn)定性測試，通常直接采用性能基準(zhǔn)測試中的虛擬用戶腳本，但是性能測試場景的設(shè)計(jì)和性能基準(zhǔn)測試場景會(huì)有很大不同：
一般是采用“波浪式”的測試負(fù)載，比如先逐漸加大測試負(fù)載，在高負(fù)載情況下持續(xù) 10 多個(gè)小時(shí)，然后再逐漸降低負(fù)載，這樣就構(gòu)成了一個(gè)“波浪”，整個(gè)穩(wěn)定性測試將由很多個(gè)這樣的波浪連續(xù)組成。
穩(wěn)定性測試成功完成的標(biāo)志，主要有以下三項(xiàng)：
①系統(tǒng)資源的所有監(jiān)控指標(biāo)不存在“不可逆轉(zhuǎn)”的上升趨勢；
②事務(wù)的響應(yīng)時(shí)間不存在逐漸變慢的趨勢；
③事務(wù)的錯(cuò)誤率不超過 1%。
實(shí)際工程項(xiàng)目中，由于穩(wěn)定性測試執(zhí)行的時(shí)間成本很高，往往需要花費(fèi) 3~7 天的時(shí)間，所以我們一般是在其他所有測試都已經(jīng)完成，并且所有問題都已經(jīng)修復(fù)之后才開始穩(wěn)定性測試。
另外，有些企業(yè)為了縮短穩(wěn)定性測試的執(zhí)行時(shí)間，往往還會(huì)采用“時(shí)間軸壓縮”的方法，具體的做法就是：在加大測試負(fù)載的前提下，適當(dāng)縮短每個(gè)“波浪”的時(shí)間，從而減少整體的測試執(zhí)行時(shí)間。
最后，需要強(qiáng)調(diào)的一點(diǎn)是，雖然很多時(shí)候，尤其是產(chǎn)品版本已經(jīng)逐漸走向成熟期時(shí)，穩(wěn)定性測試并不會(huì)發(fā)現(xiàn)問題，但是千萬不要小看穩(wěn)定性測試帶來的價(jià)值。因?yàn)榉€(wěn)定性測試一旦發(fā)現(xiàn)問題，那么這些問題都是很嚴(yán)重而且非常隱蔽的大問題。
所以，很多大型的企業(yè)級(jí)軟件企業(yè)都會(huì)執(zhí)行嚴(yán)格的穩(wěn)定性測試，并把穩(wěn)定性測試的結(jié)果作為產(chǎn)品是否可以發(fā)布的硬性要求。比如，我曾經(jīng)工作過的 HP 軟件研發(fā)中心，它每次產(chǎn)品發(fā)布前都會(huì)由專門的性能測試團(tuán)隊(duì)完成嚴(yán)格的穩(wěn)定性測試，并以此來決定是否要發(fā)布這個(gè)產(chǎn)品。
并發(fā)測試
并發(fā)測試，是在高并發(fā)情況下驗(yàn)證單一業(yè)務(wù)功能的正確性以及性能的測試手段。高并發(fā)測試一般使用思考時(shí)間為零的虛擬用戶腳本來發(fā)起具有“集合點(diǎn)”的測試。
并發(fā)測試，往往被當(dāng)作功能測試的補(bǔ)充，主要用于發(fā)現(xiàn)諸如多線程、資源競爭、資源死鎖之類的錯(cuò)誤。要執(zhí)行并發(fā)測試，就需要加入“集合點(diǎn)”，所以往往需要修改虛擬用戶腳本。
加入“集合點(diǎn)”一般有兩種做法：
①在虛擬用戶腳本的錄制過程中直接添加；
②在虛擬用戶腳本中，通過加入 lr_rendezvous() 函數(shù)添加。
容量規(guī)劃測試
容量規(guī)劃測試，是為了完成容量規(guī)劃而設(shè)計(jì)執(zhí)行的測試。
那什么是容量規(guī)劃呢？所謂容量規(guī)劃，是軟件產(chǎn)品為滿足用戶目標(biāo)負(fù)載而調(diào)整自身生產(chǎn)能力的過程。
所以，容量規(guī)劃的主要目的是，解決當(dāng)系統(tǒng)負(fù)載將要達(dá)到極限處理能力時(shí)，我們應(yīng)該如何通過垂直擴(kuò)展（增加單機(jī)的硬件資源）和水平擴(kuò)展（增加集群中的機(jī)器數(shù)量）增加系統(tǒng)整體的負(fù)載處理能力的問題。
目前來講，容量規(guī)劃的主要方法是基于水平擴(kuò)展。但是，具體應(yīng)該增加多少機(jī)器，以及增加后系統(tǒng)的負(fù)載處理能力是否會(huì)線性增長，這些問題都需要通過容量規(guī)劃測試進(jìn)行驗(yàn)證。
那么，容量規(guī)劃測試具體要怎么做呢？
我們可以使用性能基準(zhǔn)測試中的虛擬用戶腳本，以及各個(gè)業(yè)務(wù)操作腳本的百分比，壓測單機(jī)部署的被測系統(tǒng)。我們會(huì)采用人工的方式不斷增加測試負(fù)載直到單機(jī)系統(tǒng)的吞吐量指標(biāo)到達(dá)臨界值，由此就可以知道單臺(tái)機(jī)器的處理能力。
理論上講，整個(gè)集群的處理能力將等于單臺(tái)機(jī)器的處理能力乘以集群的機(jī)器數(shù)，但是實(shí)際情況并不是這樣。實(shí)際的集群整體處理能力一定小于這個(gè)值，但具體小多少就是要靠實(shí)際的測試驗(yàn)證了。
理想的狀態(tài)是，集群整體的處理能力能夠隨著集群機(jī)器數(shù)量的增長呈線性增長。但是，隨著機(jī)器數(shù)量的不斷增長，總會(huì)在達(dá)到某個(gè)臨界值之后，集群的整體處理能力不再繼續(xù)呈線性增長。這個(gè)臨界值是多少，我們也需要通過容量規(guī)劃測試找出來了。
另外，容量規(guī)劃測試的測試結(jié)果還可以被用作系統(tǒng)容量設(shè)計(jì)的依據(jù)。比如，企業(yè)級(jí)軟件產(chǎn)品的目標(biāo)用戶規(guī)模通常是可以預(yù)估的，那么我們就可以通過這些預(yù)估的系統(tǒng)負(fù)載計(jì)算出軟件部署的集群規(guī)模，并且可以在具體實(shí)施后通過容量測試的方式進(jìn)行驗(yàn)證。
最新資訊: 由狂師老師主講的「全棧測試開發(fā)技能訓(xùn)練營」2期下周即將進(jìn)入性能測試版塊，課程內(nèi)容、課程質(zhì)量得到學(xué)員們一致好評(píng)！
END
長按二維碼/微信掃碼 添加作者
閱讀原文