軟件性能測(cè)試平臺(tái)的建設(shè)說(shuō)明

軟件性能測(cè)試平臺(tái)的建設(shè)說(shuō)明一、組織架構(gòu)這里我依據(jù)每個(gè)不同系統(tǒng)歸屬的工程組為橫向，性能測(cè)試團(tuán)隊(duì)作為職能部門為縱向的矩陣式組織架構(gòu)為例，來(lái)介紹性能測(cè)試治理平臺(tái)的構(gòu)思。二、思維導(dǎo)圖三、任務(wù)治理1、任務(wù)申請(qǐng)一般來(lái)說(shuō)，性能測(cè)試需求的來(lái)源有2個(gè)方面：①、工程組提需求工程組主動(dòng)提性能測(cè)試需求，需要一個(gè)統(tǒng)一的性能測(cè)試任務(wù)治理的模塊，其中包括被測(cè)系統(tǒng)歸屬的工程條線、系統(tǒng)名稱、系統(tǒng)架構(gòu)圖、網(wǎng)絡(luò)拓?fù)鋱D、相關(guān)設(shè)計(jì)文檔及相關(guān)環(huán)境的配置信息，以及工程經(jīng)理、開(kāi)發(fā)、運(yùn)維、DB等聯(lián)系方式，還有被測(cè)系統(tǒng)交付測(cè)試時(shí)間，deadline時(shí)間等信息。這種狀況又可以分為三種類型：系統(tǒng)公布：的系統(tǒng)公布上線，需要對(duì)功能，性能，安全等各方面做一個(gè)完整的測(cè)試，評(píng)估是否到達(dá)業(yè)務(wù)、產(chǎn)品既定的上線要求。老系統(tǒng)迭代：已有系統(tǒng)進(jìn)展某些優(yōu)化，功能的增加或者的業(yè)務(wù)渠道引入，可能帶來(lái)更高的流量沖擊，這時(shí)候工程經(jīng)理或者開(kāi)發(fā)經(jīng)理睬提出相關(guān)的性能需求，期望驗(yàn)證已有系統(tǒng)是否滿足上線需要。生產(chǎn)事故修復(fù)驗(yàn)證：系統(tǒng)在生產(chǎn)環(huán)境遇到性能問(wèn)題帶來(lái)了某些損失，經(jīng)過(guò)調(diào)優(yōu)或修復(fù)后需要進(jìn)展一輪全面的性能測(cè)試來(lái)評(píng)估是否滿足已有的實(shí)際業(yè)務(wù)需求。②、性能組提需求針對(duì)工程的迭代、需求的引入帶來(lái)的可能存在的性能瓶頸主動(dòng)提出，然后經(jīng)過(guò)評(píng)估，打算是否進(jìn)展測(cè)試，來(lái)評(píng)估系統(tǒng)的穩(wěn)定性可用性等。2、任務(wù)審批性能測(cè)試任務(wù)申請(qǐng)?zhí)峤缓?，就需要工程組、性能組甚至其他相關(guān)人員依據(jù)現(xiàn)有狀況，工作安排，工期等進(jìn)展綜合評(píng)估，來(lái)打算是否進(jìn)展性能測(cè)試以及何時(shí)開(kāi)頭，資源安排的工作。其中需要涉及到多個(gè)團(tuán)隊(duì)多個(gè)人員的協(xié)作和參與，還有不能按期交付帶來(lái)的風(fēng)險(xiǎn)預(yù)估等；關(guān)于性能測(cè)試需求評(píng)審，后續(xù)我會(huì)特地寫(xiě)篇博客來(lái)分析其中的一些細(xì)節(jié)。3、任務(wù)排期性能測(cè)試任務(wù)經(jīng)過(guò)評(píng)估后打算進(jìn)展，接下來(lái)就是依據(jù)具體的工作安排，資源調(diào)配，進(jìn)展工作排期等進(jìn)一步的工作。四、用例治理這里的用例，我指的是性能測(cè)試中包括基于任務(wù)類型，資源等各方面狀況來(lái)建立的業(yè)務(wù)模型來(lái)抽象治理，具體可分為下面三種業(yè)務(wù)模型：1、常規(guī)任務(wù)常規(guī)任務(wù)，指的是系統(tǒng)迭代或者系統(tǒng)公布提出的性能需求，其中包括工程條線、系統(tǒng)名稱、架構(gòu)、拓?fù)鋱D、相關(guān)人員信息、業(yè)務(wù)模型等具體信息。依據(jù)上述的狀況進(jìn)展具體的被測(cè)系統(tǒng)場(chǎng)景建模分析，然后制定具體的測(cè)試用例。2、日常輪詢這一類型可以參考持續(xù)集成中的自動(dòng)執(zhí)行和條件觸發(fā)等狀況，設(shè)立定時(shí)任務(wù)對(duì)范圍內(nèi)的系統(tǒng)進(jìn)展性能測(cè)試，測(cè)試類型主要包括并發(fā)、多節(jié)點(diǎn)等測(cè)試類型。3、全鏈路壓測(cè)全鏈路壓測(cè)，主要是生產(chǎn)環(huán)境進(jìn)展的整體業(yè)務(wù)線的性能測(cè)試，具體內(nèi)容，可以參考我之前的博客：聊聊全鏈路壓測(cè)。五、環(huán)境治理性能測(cè)試開(kāi)頭的前提是有一個(gè)穩(wěn)定可滿足性能測(cè)試的環(huán)境，一般來(lái)說(shuō)都是在下面兩種環(huán)境進(jìn)展：1、UATUAT環(huán)境即我們俗稱的用戶驗(yàn)收測(cè)試環(huán)境，相對(duì)來(lái)說(shuō)環(huán)境穩(wěn)定，且配置各方面和生產(chǎn)一樣或者可以進(jìn)展等量代換，能滿足常規(guī)的性能測(cè)試需要。2、FATFAT環(huán)境可理解為生產(chǎn)驗(yàn)證測(cè)試環(huán)境，系統(tǒng)版本，配置、數(shù)據(jù)量等和生產(chǎn)保持全都，這樣從可測(cè)試性和真實(shí)性上更符合實(shí)際的生產(chǎn)狀況。PS：還有全鏈路壓測(cè)是在真實(shí)的生產(chǎn)環(huán)境進(jìn)展，但是生產(chǎn)環(huán)境進(jìn)展性能測(cè)試的風(fēng)險(xiǎn)太大，且對(duì)現(xiàn)有系統(tǒng)的改造工作較多，是否進(jìn)展還需要經(jīng)過(guò)具體的評(píng)估才能打算。全鏈路壓測(cè)的挑戰(zhàn)在于這幾點(diǎn)：①、業(yè)務(wù)模型梳理②、數(shù)據(jù)問(wèn)題，包括數(shù)據(jù)的真實(shí)可用性、數(shù)據(jù)隔離和數(shù)據(jù)脫敏；③、環(huán)境隔離，不能影響到實(shí)際的生產(chǎn)業(yè)務(wù)；④、效勞集群負(fù)載均衡，測(cè)試策略和效勞間通信的問(wèn)題；⑤、容災(zāi)問(wèn)題，包括某些效勞宕機(jī)或者不行用時(shí)，不能對(duì)實(shí)際生產(chǎn)業(yè)務(wù)運(yùn)行造成影響，系統(tǒng)可用性等；六、壓測(cè)機(jī)治理1、壓測(cè)機(jī)調(diào)度實(shí)際的流量沖擊較高時(shí)，單個(gè)壓力機(jī)可能無(wú)法支持，這時(shí)候就需要多個(gè)壓力執(zhí)行機(jī)來(lái)分布式的進(jìn)展壓測(cè)。在實(shí)際生產(chǎn)環(huán)境，流量的變化很有可能是隨機(jī)的，如何做好壓測(cè)執(zhí)行機(jī)的增加和縮小，合理利用資源，是需要考慮和解決的問(wèn)題。2、狀態(tài)治理這里主要包括壓測(cè)機(jī)的狀態(tài)變化，包括閑置、使用〔甚至推測(cè)何時(shí)可釋放出來(lái)供其他壓測(cè)任務(wù)使用等〕、不行用〔損壞或其他緣由〕等。3、特別治理當(dāng)性能測(cè)試進(jìn)展過(guò)程中，由于某些緣由導(dǎo)致效勞不行用，就需要準(zhǔn)時(shí)的停頓性能壓測(cè)，一般來(lái)說(shuō)主要是下面幾種手段：①、手動(dòng)停頓：從治理界面的功能按鈕來(lái)停頓壓測(cè)執(zhí)行；②、熔斷措施：即通過(guò)監(jiān)控報(bào)警措施，當(dāng)系統(tǒng)不行用或超過(guò)某個(gè)閾值時(shí)，自動(dòng)停頓壓測(cè)；③、兜底手段：當(dāng)手動(dòng)停頓或者自動(dòng)熔斷措施都不行用時(shí)，從外部的某些手段來(lái)停頓壓測(cè)執(zhí)行，這也算一種容災(zāi)措施；相關(guān)資料可參考餓了么全鏈路壓測(cè)平臺(tái)的實(shí)現(xiàn)與原理。七、數(shù)據(jù)治理測(cè)試是需要數(shù)據(jù)來(lái)驅(qū)動(dòng)的，那么在性能測(cè)試中，需要預(yù)備哪些數(shù)據(jù)呢？1、根底數(shù)據(jù)根底數(shù)據(jù)包括系統(tǒng)業(yè)務(wù)正常運(yùn)行所必需的數(shù)據(jù)，比方：電商平臺(tái)的SKU信息、庫(kù)存數(shù)據(jù)等，還有銀行的用戶信息、某些業(yè)務(wù)的相關(guān)數(shù)據(jù)等，可以通過(guò)從生產(chǎn)備份等手段來(lái)解決。2、預(yù)埋數(shù)據(jù)預(yù)埋數(shù)據(jù)主要指的是DB層面，即性能測(cè)試需要模擬實(shí)際的環(huán)境，包括數(shù)據(jù)量等，從DB層面來(lái)說(shuō)，同一個(gè)庫(kù)表，數(shù)據(jù)量不同在同樣的業(yè)務(wù)模型下，其性能表現(xiàn)也是不同的。預(yù)埋數(shù)據(jù)的預(yù)備，可以通過(guò)從生產(chǎn)備份，或者通過(guò)腳本、SQL語(yǔ)句來(lái)自定義預(yù)備一些可用的數(shù)據(jù)。3、測(cè)試數(shù)據(jù)測(cè)試腳本運(yùn)行所必需的數(shù)據(jù)，通?？梢酝ㄟ^(guò)參數(shù)化的方式來(lái)解決。固然，從測(cè)試平臺(tái)的角度，解決這個(gè)問(wèn)題的方法可以通過(guò)統(tǒng)一的數(shù)據(jù)池來(lái)做治理，界面通API八、監(jiān)控治理性能測(cè)試中，監(jiān)控是必不行少的重要一環(huán)，通常來(lái)說(shuō)，需要監(jiān)控的包括以下幾個(gè)方面：1、前端性能前端展現(xiàn)、資源渲染所花費(fèi)的時(shí)間，哪些資源消耗了最多的時(shí)間和資源，都是需要通過(guò)監(jiān)控來(lái)得到相關(guān)信息。2、中間件①、Redis有些系統(tǒng)架構(gòu)利用Redis來(lái)做長(zhǎng)久層或者緩沖區(qū)，那么對(duì)于緩存的可用性和緩存失效、緩存穿透等信息，也是必需要監(jiān)控的。②、MQMQ是一個(gè)異步的通信框架，類似的還有kafka等框架，對(duì)于消息隊(duì)列的生產(chǎn)和消費(fèi)速率，資源占用，可能的堵塞等狀況進(jìn)展監(jiān)控，也是必不行少的。③、其他3、容器現(xiàn)在越來(lái)越多的企業(yè)開(kāi)頭將效勞容器化〔特別是在微效勞的架構(gòu)中，容器化是必要的一種手段〕，包括環(huán)境、腳本、效勞都放在容器中。那么對(duì)容器資源的監(jiān)控，也是格外必需的。4、效勞器效勞器的監(jiān)控，主要是內(nèi)存、CPU、IO等方面，包括占比、使用率、閾值和提示等。5、DB數(shù)據(jù)庫(kù)層面，主要監(jiān)控的內(nèi)存、CPU等信息，固然也包括SQL語(yǔ)句執(zhí)行消耗時(shí)間、鎖等狀況。6、網(wǎng)絡(luò)網(wǎng)絡(luò)是必不行少的一環(huán)，不穩(wěn)定的網(wǎng)絡(luò)環(huán)境對(duì)測(cè)試結(jié)果的影響很大，可能會(huì)帶來(lái)一些隱蔽的問(wèn)題；網(wǎng)絡(luò)監(jiān)控一般關(guān)注這幾個(gè)方面：穩(wěn)定性、網(wǎng)關(guān)、CDN、防火墻等方面。PS：實(shí)際上從上面的幾種監(jiān)控來(lái)看，都是從用戶層到最終的效勞處理層，層層進(jìn)展監(jiān)控，做到一切用數(shù)據(jù)說(shuō)話。九、日志治理在測(cè)試過(guò)程中，有時(shí)候不能從測(cè)試數(shù)據(jù)直觀的看到隱蔽的問(wèn)題，就需要查看對(duì)應(yīng)的日志，從詳盡的日志中分析爆發(fā)問(wèn)題的節(jié)點(diǎn)，然后進(jìn)展針對(duì)性的分析。日志監(jiān)控，或許分下面幾個(gè)層級(jí)：1、web這里可以理解為用戶層的日志，包括資源的本地加載、緩存等信息〔由于某些狀況下詳盡的日志包較大，承受了日志寫(xiě)入用戶層的操作〕。2、app這里代指應(yīng)用層，有時(shí)候消滅性能問(wèn)題的緣由發(fā)生在應(yīng)用層，那么對(duì)應(yīng)用層的監(jiān)控，日志分析也是很重要的。3、service后臺(tái)效勞層，日志包括處理了哪些操作，哪個(gè)懇求甚至哪里調(diào)用等。4、DB數(shù)據(jù)庫(kù)日志，同理，哪些操作消耗的時(shí)間長(zhǎng)、資源多等，都是需要對(duì)應(yīng)的監(jiān)控和必要的日志分析，才能看出問(wèn)題。PS：上述的幾種日志治理，從性能測(cè)試平臺(tái)角度來(lái)說(shuō)，都是期望將日志更直觀的進(jìn)展展現(xiàn)、篩選，否則我們需要通過(guò)命令或者其他工具的方式，到具體的層級(jí)去查找分析日志，這樣無(wú)疑會(huì)鋪張肯定的時(shí)間。十、報(bào)表治理報(bào)表治理主要包括下面幾個(gè)方面：1、實(shí)時(shí)結(jié)果將測(cè)試的實(shí)時(shí)監(jiān)控結(jié)果存入數(shù)據(jù)庫(kù)，然后通過(guò)grafana等工具展現(xiàn)在界面上，更直觀的對(duì)測(cè)試結(jié)果進(jìn)展治理。2、測(cè)試報(bào)告每輪測(cè)試完畢，都需要對(duì)測(cè)試結(jié)果進(jìn)展統(tǒng)計(jì)分析，以便于作為一個(gè)基點(diǎn)，對(duì)下一次測(cè)試供給參考和評(píng)估依據(jù)；測(cè)試報(bào)告界面可以通過(guò)自定義的樣式來(lái)呈現(xiàn)。3、性能基線這里的性能基線，指的是：將每次性能測(cè)試的最終結(jié)果作為一共性能參考基線，后續(xù)的每次迭代，以上次性能測(cè)試結(jié)果為評(píng)估點(diǎn)，然后持續(xù)更性能基線，作為下一次的評(píng)估依據(jù)?？梢酝ㄟ^(guò)數(shù)據(jù)折線、樹(shù)狀圖等多種方式來(lái)呈現(xiàn)，目的是為長(zhǎng)期的系統(tǒng)穩(wěn)定性、可用性做一個(gè)監(jiān)控，為系統(tǒng)調(diào)優(yōu)或重構(gòu)供給多種維度的參考依據(jù)。十一、配置治理1、擋板一般來(lái)說(shuō)，性能測(cè)試都是通過(guò)調(diào)用不同的效勞接口來(lái)進(jìn)展模擬并發(fā)，進(jìn)展測(cè)試，但有時(shí)候由于某些緣由，導(dǎo)致一局部效勞臨時(shí)不行用，或者次數(shù)限制，這種狀況急需要用到mock效勞。①、Mock是最常見(jiàn)的一種協(xié)議，而且隨著微效勞的流行，restful風(fēng)格架構(gòu)設(shè)計(jì)的運(yùn)用，Mock②、SocketMockTCP連接也是某些業(yè)務(wù)系統(tǒng)效勞實(shí)現(xiàn)通信的方式，為了便利的進(jìn)展性能測(cè)試而降低對(duì)其他某些效勞的依靠，SocketMock③、其他包括dubbo接口等其他類型的接口調(diào)用，可以針對(duì)性的進(jìn)展設(shè)計(jì)，將mock變?yōu)橐环N效勞。PS：從測(cè)試治理平臺(tái)的角度來(lái)說(shuō)，將Mock對(duì)象編程效勞，通過(guò)界面進(jìn)展增刪改查的治理，更便利了治理和直觀的理解。2、容器①、docker容器化，是這幾年越來(lái)越流行的一個(gè)趨勢(shì)，對(duì)不同的測(cè)試環(huán)境的docker容器治理，也是必不行少的。②、虛機(jī)限于不同工程不同技術(shù)架構(gòu)的狀況，虛擬機(jī)治理這一項(xiàng)，可以依據(jù)具體的需要來(lái)進(jìn)展設(shè)計(jì)，假設(shè)全部容器