對(duì)于 DevOps 來說,跟蹤軟件生命周期性能指標(biāo)(如響應(yīng)時(shí)間、吞吐量、每秒事務(wù)數(shù)、錯(cuò)誤率等)至關(guān)重要。這些參數(shù)很復(fù)雜,直接影響最終用戶體驗(yàn)。有效的性能測(cè)試有助于 DevOps 團(tuán)隊(duì)跟蹤質(zhì)量指標(biāo)并及早發(fā)現(xiàn)缺陷。它還通過跟蹤風(fēng)險(xiǎn)容忍度、用戶數(shù)量、并發(fā)請(qǐng)求、流量峰值以及其他可能導(dǎo)致崩潰的因素來幫助團(tuán)隊(duì)完善軟件。
一、為什么要進(jìn)行性能測(cè)試?
性能,在某種程度上,是與功能質(zhì)量完全不同的質(zhì)量衡量標(biāo)準(zhǔn)。如果軟件的功能方面出現(xiàn)問題,它通常會(huì)很快顯現(xiàn)出來——一旦有缺陷的產(chǎn)品發(fā)布,馬上就可以發(fā)現(xiàn)錯(cuò)誤并使用反饋來糾正問題。但是,性能問題、瓶頸和穩(wěn)定性缺陷可能會(huì)在數(shù)周或數(shù)月內(nèi)被忽視,直到下一個(gè)年度峰值或直到數(shù)據(jù)增長(zhǎng)到一定水平才會(huì)被發(fā)現(xiàn),這時(shí)候的損失往往是巨大的。但如果提前進(jìn)行軟件性能測(cè)試,開發(fā)人員的就可以提前找出軟件的性能癥狀和問題。以下這些都是很常見的癥狀和問題:
速度問題:例如響應(yīng)慢和加載時(shí)間長(zhǎng)——這很容易被觀察到并且解決。
瓶頸:當(dāng)數(shù)據(jù)流因沒有足夠的容量來處理工作負(fù)載而中斷或停止時(shí),就會(huì)發(fā)生這種情況。
可擴(kuò)展性差:如果軟件無法處理所需數(shù)量的并發(fā)任務(wù),結(jié)果可能會(huì)延遲,錯(cuò)誤可能會(huì)增加,或者可能會(huì)發(fā)生其他意外行為,從而影響磁盤使用情況和CPU使用率,導(dǎo)致內(nèi)存泄漏、操作系統(tǒng)限制、網(wǎng)絡(luò)配置不佳。
軟件配置問題:通常設(shè)置的級(jí)別不足以處理工作負(fù)載。
硬件資源不足:性能測(cè)試可能會(huì)顯示物理內(nèi)存限制或CPU性能。
二、性能測(cè)試七大類型
性能測(cè)試對(duì)于確?？蛻羝谕能浖€(wěn)定性、可擴(kuò)展性和可靠性至關(guān)重要。在制定全面的性能測(cè)試策略之前,要先了解性能測(cè)試類型。一般來說,分為以下幾大類:
負(fù)載測(cè)試:是通過逐漸增加系統(tǒng)的負(fù)載,測(cè)試系統(tǒng)性能的變化,并最終確定在滿足系統(tǒng)性能指標(biāo)的情況下,系統(tǒng)所能承受的最大負(fù)載量的測(cè)試。簡(jiǎn)而言之,負(fù)載測(cè)試時(shí)通過逐步加壓的方式來確定系統(tǒng)的處理能力和能夠承受的各項(xiàng)閾值。
壓力測(cè)試:是通過逐步增加系統(tǒng)的負(fù)載,測(cè)試系統(tǒng)性能的變化,并最終確定在什么負(fù)載條件下,系統(tǒng)性能處于失效狀態(tài),并獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測(cè)試。壓力測(cè)試是逐步增加負(fù)載,使系統(tǒng)某些資源達(dá)到飽和甚至失效。
配置測(cè)試:主要是通過對(duì)被測(cè)試軟件的軟硬件配置進(jìn)行測(cè)試,找到系統(tǒng)各項(xiàng)資源的最優(yōu)分配原則。配置測(cè)試能充分利用有限的軟硬件資源,發(fā)揮系統(tǒng)的最佳處理能力,同時(shí)可以將其與其他性能測(cè)試類型聯(lián)合應(yīng)用,從而為系統(tǒng)提供重要依據(jù)。
并發(fā)測(cè)試:測(cè)試多個(gè)用戶同時(shí)訪問同一個(gè)應(yīng)用、同一個(gè)模塊或者數(shù)據(jù)記錄時(shí)是否存在死鎖或者其他性能問題,幾乎所有的性能測(cè)試都會(huì)涉及一些并發(fā)測(cè)試。
容量測(cè)試:在一定的軟、硬件條件下,在數(shù)據(jù)庫中構(gòu)造不同數(shù)量級(jí)的記錄數(shù)量,通過運(yùn)行一種或多種業(yè)務(wù)場(chǎng)景在一定虛擬用戶數(shù)量的情況下,獲取不同數(shù)量級(jí)別的性能指標(biāo),從而得到數(shù)據(jù)庫能夠處理的最大會(huì)話能力、最大容量等。系統(tǒng)可處理同時(shí)在線的最大用戶數(shù),通常和數(shù)據(jù)庫有關(guān)。
可靠性測(cè)試:通過給系統(tǒng)加載一定的業(yè)務(wù)壓力(如CPU資源在70%～90%的使用率)的情況下,運(yùn)行一段時(shí)間,檢查系統(tǒng)是否穩(wěn)定,因?yàn)檫\(yùn)行時(shí)間較長(zhǎng),通?？梢詼y(cè)試出系統(tǒng)是否有內(nèi)存泄漏等問題。
失敗測(cè)試:對(duì)于有冗余備份和負(fù)載均衡的系統(tǒng),通過失敗測(cè)試來檢驗(yàn)如果系統(tǒng)局部發(fā)生故障,用戶能否繼續(xù)使用系統(tǒng),用戶受到多大的影響,如幾臺(tái)機(jī)器做均衡負(fù)載,一臺(tái)或幾臺(tái)機(jī)器垮掉后系統(tǒng)能夠承受的壓力。
三、如何選擇性能測(cè)試工具?
在 DevOps 中,軟件開發(fā)生命周期中的所有關(guān)鍵步驟都是自動(dòng)化的,包括測(cè)試,性能測(cè)試自然也不例外。
在選擇 DevOps 性能測(cè)試平臺(tái)時(shí),無論是開源工具還是商業(yè)工具,除了它本身的功能之外,這些因素都必須要考慮到:
許可限制——有的商業(yè)產(chǎn)品帶有許可限制,可能會(huì)影響使用該解決方案的方式。在某些情況下,協(xié)議允許或禁止外包人員/企業(yè)使用工具,并且在某些情況下不允許將性能測(cè)試工具部署在特定地理區(qū)域之外。
供應(yīng)商支持——除了單純的工具之外,供應(yīng)商是否提供技術(shù)支持、培訓(xùn)等也很重要,一錘子買賣通常會(huì)帶來很大的麻煩。即使在選擇開源工具的時(shí)候,也可以考慮是否有商業(yè)公司提供服務(wù)和支持。
社區(qū)支持——經(jīng)驗(yàn)表明,過多地依賴供應(yīng)商并不是一個(gè)好的選擇,因此,構(gòu)建自己的 IT 能力很重要,而社區(qū)支持是必須考慮的另一個(gè)因素。一個(gè)可以尋求支持的在線論壇,可以讓技術(shù)團(tuán)隊(duì)緊跟最新發(fā)展、補(bǔ)丁、漏洞、功能更新。
市場(chǎng)流行——了解市場(chǎng)偏好,緊跟市場(chǎng)趨勢(shì),即使在遇到不能解決的問題的時(shí)候,也能很快找到技術(shù)支援。如果預(yù)算有限,選擇在小眾工具上構(gòu)建功能,那也應(yīng)該將這一風(fēng)險(xiǎn)考慮進(jìn)去。
與監(jiān)控和診斷工具的集成——如果能將性能測(cè)試工具與企業(yè)內(nèi)部的監(jiān)控和診斷工具集成,那最好不過。因此,要了解監(jiān)控和診斷工具的內(nèi)部環(huán)境,然后與性能測(cè)試工具供應(yīng)商確認(rèn)是否支持,以及可集成程度,最好能嘗試一下集成再做決定。
與需求管理和缺陷管理工具的集成——大多數(shù)企業(yè)提供的性能測(cè)試工具都能夠與行業(yè)領(lǐng)先的缺陷管理和需求管理工具集成。相反,性能測(cè)試工具供應(yīng)商無法支持所有商業(yè)缺陷管理平臺(tái)。如果要與缺陷管理平臺(tái)集成,那就要考慮這些工作量是否會(huì)過大。雖然從實(shí)施的角度來看,這不是主要問題,但如果在評(píng)估階段沒有將其考慮進(jìn)去,那么它可能會(huì)成為一大阻礙。
對(duì)于 DevOps 實(shí)施團(tuán)隊(duì)來說,選擇一個(gè)集成性能測(cè)試的開發(fā)平臺(tái),可以省去許多不必要的麻煩。以飛算SoFlu軟件機(jī)器人為例,它將開發(fā)、測(cè)試、運(yùn)維三大流程全部打通,并且自動(dòng)化執(zhí)行,無需考慮與第三方平臺(tái)的集成成本,而且由于平臺(tái)使用可視化開發(fā),簡(jiǎn)單易上手,人力資源投入大幅減少,開發(fā)效率快速提升。
目前,飛算SoFlu軟件機(jī)器人正在不斷更新和優(yōu)化中。值得一提的是,在性能測(cè)試方面,飛算SoFlu軟件機(jī)器人全自動(dòng)測(cè)試平臺(tái)新增了并發(fā)數(shù)自動(dòng)分配功能。在性能測(cè)試計(jì)劃導(dǎo)入測(cè)試用例之后,可以自定義將并發(fā)數(shù)量分配到哪臺(tái)資源的服務(wù)器上執(zhí)行,不僅可以合理利用資源,同時(shí)還能測(cè)試其他資源的情況,執(zhí)行報(bào)告和性能結(jié)果會(huì)整合在測(cè)試報(bào)告中一并查看。
