丨性能看護(hù)如何更好地守護(hù)產(chǎn)品

不過我也要說明一點(diǎn)，就是這節(jié)課我并不是要講解具體的工具和技術(shù)，幫你建立起高效實(shí)施性能測試與看護(hù)的價(jià)值觀。這是因?yàn)榭蓮?fù)用的方法，往往會(huì)比具體的工具和技術(shù)使用技巧重要許多，它可以幫你把有限的精力用到刀刃上，這樣你就可以花費(fèi)更少的成本獲得更佳的性能測試與看護(hù)效果。所謂的自動(dòng)化，就是把所有重復(fù)性的手動(dòng)工作，盡量交給機(jī)器去自動(dòng)執(zhí)行，這樣就可以把人解放出來，做更有價(jià)值的事情。而我們知道，在對(duì)軟件系統(tǒng)進(jìn)行性能測試的過程中，中間潛在的繁瑣、重復(fù)性的工作會(huì)非常多，所以如果可以把這部分工作都自動(dòng)化，就可以大大提高性能測試的效率。我剛開始參加工作不久，有一段時(shí)間主要是負(fù)責(zé)項(xiàng)目的性能攻關(guān)測試工作。在每一輪性能測試的過程中，我都需要同時(shí)操作十幾臺(tái)電腦，并在每臺(tái)電腦上啟動(dòng)一個(gè)測試程序，然后記錄不同時(shí)間段的，并重新修改測試配置，一直重復(fù)這個(gè)過程直到完成下一輪的測試。自動(dòng)化地進(jìn)試，從而讓我省下了很多時(shí)間去學(xué)習(xí)業(yè)務(wù)代碼。實(shí)際上，在進(jìn)行性能測試的過程中，不僅中間會(huì)包含很多像我這樣非常繁瑣的重復(fù)性工作，而且很多時(shí)候，有些重復(fù)性工作還比較隱蔽，它們會(huì)偷偷消耗你的時(shí)間，而你還無法及時(shí)發(fā)現(xiàn)。雖然不同軟件產(chǎn)品在性能測試的過程中，獲取和準(zhǔn)備測試數(shù)據(jù)的方法都是不一樣的，但是中間的大部分工作都應(yīng)該盡量做到自動(dòng)化，比如說自動(dòng)生成數(shù)據(jù)、通過代碼抓取現(xiàn)網(wǎng)數(shù)據(jù)等。MongoDB中dump出來的JSON文件，但它與性能測試接口的請(qǐng)求格式并不一樣。當(dāng)碰到這種情況時(shí)，聰明一點(diǎn)的性能測試人員可能會(huì)找一個(gè)IDE那么我認(rèn)為最佳的方式，就是通過代碼來實(shí)現(xiàn)這個(gè)數(shù)據(jù)的轉(zhuǎn)換過程，這樣一次的代碼開發(fā)其實(shí)，不光是按照測試需求來生成數(shù)據(jù)，在現(xiàn)網(wǎng)中數(shù)據(jù)等環(huán)節(jié)，也都有很多重復(fù)性的工作。就拿這個(gè)例子來說，從MongoDB中ump文件也是重復(fù)性工作，它也可以做到代碼自動(dòng)化。所以，從項(xiàng)目管理的視角出發(fā)，你更應(yīng)該關(guān)注這個(gè)階段的自動(dòng)化。其實(shí)，在測試環(huán)境準(zhǔn)備階段也有很多工作可以自動(dòng)化，比如測試軟件、測試部署、系統(tǒng)環(huán)境變量設(shè)置等工作，這些都可以通過代碼化管理。我就舉個(gè)簡單的例子，比如你可以將測試工具安裝標(biāo)準(zhǔn)化到Docerfile中，然后基于容器化運(yùn)行，并且將環(huán)境變量配置都通過S 然后就是測試執(zhí)行階段，對(duì)于基于網(wǎng)絡(luò)服務(wù)的很多性能測試工作來說，你就可以選擇上節(jié)課我介紹的代碼化性能測試工具（如Locust、6），來更好地支持代碼自動(dòng)化執(zhí)行。對(duì)于很多嵌入式設(shè)備來說，定制化的性能測試工具其實(shí)也可以朝著自動(dòng)化逐步演進(jìn)，這樣就不僅可以提升測試效率，還可以降低人力成本。最后，就是的記錄工作。由于手動(dòng)記錄比較方便，所以這個(gè)環(huán)節(jié)經(jīng)常容易被忽視。但在我之前參與的性能測試項(xiàng)目的分析過程中，就出現(xiàn)過不少次因?yàn)橛涗泚G失或者出錯(cuò)，導(dǎo)致整個(gè)性能測試返工的情況?？偠灾?，這里我總結(jié)的是在性能測試的過程中，你應(yīng)該從哪些環(huán)節(jié)去盡量挖掘可以自動(dòng)化的點(diǎn)。你在做性能測試的時(shí)候，就可以參考這些要點(diǎn)，去尋找和分析那些影響測試效率的重復(fù)性工作，并將它們自動(dòng)化。測試前置的意思就是在軟件生命周期中，盡早啟動(dòng)性能測試，盡早獲取反饋，而不是把性能測試只作為產(chǎn)品發(fā)布上線前的最后一個(gè)動(dòng)作。我估計(jì)這里你可能要問了：性能測試前置很早之前，我參與過一個(gè)嵌入式系統(tǒng)的性能主導(dǎo)重構(gòu)項(xiàng)目，在項(xiàng)目的開發(fā)階段，我們團(tuán)隊(duì)就搭建了針對(duì)該子系統(tǒng)的基準(zhǔn)性能測試工程。雖然這套性能測試工程運(yùn)行在通用PC上，與真實(shí)的嵌入式系統(tǒng)的硬件存在一定差異，但并不妨礙我們通過這套工程，來提前識(shí)別出很多系統(tǒng)在設(shè)計(jì)與實(shí)現(xiàn)的過程中潛在的性能問題。就比如說，你可能也遇到過在代碼中添加了SQL操作，引入慢查詢的性能問題，而你應(yīng)該所以，也就是從那個(gè)時(shí)候開始，我在參與接下來的性能優(yōu)化項(xiàng)目時(shí)，就開始思考如何突破在軟件后期才開展性能測試的傳統(tǒng)思維。后來我發(fā)現(xiàn)，其實(shí)我們可以把性能測試工作盡快提前和盡量拆小，也就是說將的性能測試拆分成組件/服務(wù)級(jí)的性能測試，與模塊的單元級(jí)性能測試一起來實(shí)現(xiàn)。而實(shí)現(xiàn)這個(gè)過程的指導(dǎo)原是測試前置，由此我就推導(dǎo)出了一個(gè)性能測試體系，可以幫助我更加高效地對(duì)系統(tǒng)進(jìn)行性能測試與看護(hù)。傳統(tǒng)功能測試從上到下大致可以分為三層，分別是系統(tǒng)級(jí)測試、組件級(jí)測試、單元機(jī)測試。而你可以看到，在圖中的左邊，功能測試的呈現(xiàn)層次的是金字塔形，也就是說其理想的軟件測試分布規(guī)模為：大規(guī)模的單元級(jí)測試，僅次于單元測試規(guī)模的組件或服務(wù)級(jí)的測試，最后是少量規(guī)模的系統(tǒng)級(jí)測試。這是因?yàn)?，?duì)于全系統(tǒng)級(jí)別的性能測試來說，受制于系統(tǒng)的業(yè)務(wù)復(fù)雜性，容易導(dǎo)致測試場景和執(zhí)行性能測試的成本非常大。就比如說，在我曾經(jīng)參與的性能測試項(xiàng)目中，有些團(tuán)隊(duì)在全系統(tǒng)級(jí)別性能測試上投入了很大的精力，但最后的收益并不夠理想。而對(duì)于單元模塊級(jí)別的性能測試（也就是第17講提到的微基準(zhǔn)測試）統(tǒng)中的大部分業(yè)務(wù)代碼并不是熱點(diǎn)代碼（依據(jù)2/8原則），所以對(duì)性能影響并不關(guān)鍵的業(yè)實(shí)際上，我在第18講中就提到過，如果將系統(tǒng)級(jí)的性能測試指標(biāo)，分解到組件或服務(wù)級(jí)的性能測試上，可以降低測試的復(fù)雜度和成本，實(shí)現(xiàn)以大拆小的效果。而這樣做，其實(shí)也更容易通過測試前置，更早地識(shí)別和發(fā)現(xiàn)性能問題（具體的分解方法步驟，你可以再去回顧復(fù)習(xí)下上節(jié)課的知識(shí)點(diǎn)）。但是，目前大部分的軟件研發(fā)團(tuán)隊(duì)，目光只聚焦在系統(tǒng)級(jí)的性能測試，而組件或服務(wù)級(jí)性能測試和單元模塊級(jí)的性能測試這塊是空白的，因此就比較容易陷入到系統(tǒng)級(jí)性能測試的各種復(fù)雜問題之中，花費(fèi)很大的成本，但是收益并不高。這就是因?yàn)?，團(tuán)隊(duì)沒有采用性能測試前置的原則，去構(gòu)筑更高效的性能測試體系。在一般情況下，我們都會(huì)認(rèn)為性能測試最主要的目標(biāo)，就是獲取產(chǎn)品的基線性能，這樣在基線性能出現(xiàn)的時(shí)候，我們就可以第一時(shí)間發(fā)現(xiàn)問題。那么除此之外，性能測試還有別的用處嗎？事實(shí)上，由于軟件需求的不斷演進(jìn)和變化，為了保證軟件的性能可以長期保持競爭力，我們需要從高性能設(shè)計(jì)、高性能編碼實(shí)現(xiàn)、性能調(diào)優(yōu)等多個(gè)維度一起入手，而所有這些優(yōu)化都應(yīng)該基于性能測試來驅(qū)動(dòng)進(jìn)行。點(diǎn)。比如在第7講數(shù)據(jù)庫選型設(shè)計(jì)中，我提到篩選的依據(jù)往往需要基于數(shù)據(jù)庫的性能；在第2果來分解，而不是隨便一刀切；第 11講針對(duì)數(shù)據(jù)結(jié)構(gòu)和算法的選擇，我也明確點(diǎn)出需所以首先，我們?cè)诖_定高性能設(shè)計(jì)的關(guān)鍵決策點(diǎn)時(shí)，都應(yīng)該有針對(duì)性地開發(fā)性能測試用例，并不同軟件版本變更后的性能表現(xiàn)差異，這樣才可以決策是否需要在軟件設(shè)計(jì)上做調(diào)整。而對(duì)于高性能編碼實(shí)現(xiàn)來說，也是同樣的道理。比如數(shù)據(jù)結(jié)構(gòu)和算法的性能，也會(huì)隨著業(yè)務(wù)數(shù)據(jù)的特性和規(guī)模改變而發(fā)生變化。因此，我們也應(yīng)該針對(duì)這些模塊，開發(fā)微基準(zhǔn)測試用例，來分析性能的變化趨勢。我舉個(gè)例子。有的研發(fā)團(tuán)隊(duì)業(yè)務(wù)數(shù)據(jù)量規(guī)模非常小，查詢計(jì)算邏輯比較復(fù)雜，因此開發(fā)人員就分析認(rèn)為，使用Elasicsearch可以提升查詢速度，然后就花費(fèi)比較大的成本將業(yè)務(wù)數(shù)據(jù)都遷移到了Elasisearh中，結(jié)果性能也并沒有明顯的改善。但其實(shí)，如果該研發(fā)團(tuán)隊(duì)在決定遷移數(shù)據(jù)之前，先做能測試分析工作，可能就會(huì)發(fā)現(xiàn)今天這節(jié)課，我給你總結(jié)了曾經(jīng)在很多的性能優(yōu)化項(xiàng)目中，我實(shí)現(xiàn)高效性能測試的實(shí)踐經(jīng)驗(yàn)，我把它稱之為高效性能看護(hù)的價(jià)值觀。那么，在學(xué)習(xí)完今天的課程后，我希望你就可以借鑒這些經(jīng)驗(yàn)來觀察和思考下，在你的軟件性能測試與看護(hù)過程中，是否也有一些環(huán)節(jié)可以改進(jìn)，以此幫助提升自己的工作效率。當(dāng)然，我總結(jié)的可能并不全面，所以我更希望你可以在學(xué)完課程之后，主動(dòng)去思考和總結(jié)下，在性能測試的過程中還有哪些要點(diǎn)對(duì)工作效率也很關(guān)鍵。然后，你可以提煉出一套獨(dú)立的心得和經(jīng)驗(yàn)，來指導(dǎo)自己或團(tuán)隊(duì)的工作。在你參與的性能測試工作過程中，有沒有哪些工作也是比較繁瑣的，