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

1、軟件性能測(cè)試平臺(tái)的建設(shè)說(shuō)明一、組織架構(gòu)這里我按照每個(gè)不同系統(tǒng)歸屬的項(xiàng)目組為橫向，性能測(cè)試團(tuán)隊(duì)作為職能部門(mén)為縱向的矩陣式組織架構(gòu)為例，來(lái)介紹性能測(cè)試管理平臺(tái)的構(gòu)思。二思維導(dǎo)圖料爵申埔柱務(wù)申批4F呼卄IU1中IM件DB業(yè)務(wù)捲楓汀試也未-I繭輪曲webJRPsnriccUBJATPA1訓(xùn)度停止吶-并常氾底4、圧測(cè)機(jī)管理性能測(cè)試骨即平臺(tái)宜吋鮎果側(cè)試槪汕HITPMo匚klife-10,毎辦悴理百門(mén)匚kerMnrk其他dtocker虛機(jī)用戶(hù)評(píng)利限習(xí)艸三、任務(wù)管理1、任務(wù)申請(qǐng)一般來(lái)說(shuō)，性能測(cè)試需求的來(lái)源有2個(gè)方面： 、項(xiàng)目組提需求項(xiàng)目組主動(dòng)提性能測(cè)試需求，需要一個(gè)統(tǒng)一的性能測(cè)試任務(wù)管理的模塊，其中包括被測(cè)系

2、統(tǒng)歸屬的項(xiàng)目條線、系統(tǒng)名稱(chēng)、系統(tǒng)架構(gòu)圖、網(wǎng)絡(luò)拓?fù)鋱D、相關(guān)設(shè)計(jì)文檔及相關(guān)環(huán)境的配置信息，以及項(xiàng)目經(jīng)理、開(kāi)發(fā)、運(yùn)維、DB等聯(lián)系方式，還有被測(cè)系統(tǒng)交付測(cè)試時(shí)間,deadline時(shí)間等信息。這種情況又可以分為三種類(lèi)型：新系統(tǒng)發(fā)布：新的系統(tǒng)發(fā)布上線，需要對(duì)功能，性能，安全等各方面做一個(gè)完整的測(cè)試，評(píng)估是否達(dá)到業(yè)務(wù)、產(chǎn)品既定的上線要求。老系統(tǒng)迭代：已有系統(tǒng)進(jìn)行某些優(yōu)化，新功能的增加或者新的業(yè)務(wù)渠道引入，可能帶來(lái)更高的流量沖擊，這時(shí)候項(xiàng)目經(jīng)理或者開(kāi)發(fā)經(jīng)理會(huì)提出相關(guān)的性能需求，希望驗(yàn)證已有系統(tǒng)是否滿(mǎn)足上線需要。生產(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è)

3、試來(lái)評(píng)估是否滿(mǎn)足已有的實(shí)際業(yè)務(wù)需求。 、性能S提需求針對(duì)項(xiàng)目的迭代、新需求的引入帶來(lái)的可能存在的性能瓶頸主動(dòng)提出，然后經(jīng)過(guò)評(píng)估，決定是否進(jìn)行測(cè)試，來(lái)評(píng)估系統(tǒng)的穩(wěn)定性可用性等。2、任翁審批性能測(cè)試任務(wù)申請(qǐng)?zhí)峤缓?，就需要?xiàng)目組、性能組甚至其他相關(guān)人員根據(jù)現(xiàn)有情況，工作安排，工期等進(jìn)行綜合評(píng)估，來(lái)決定是否進(jìn)行性能測(cè)試以及何時(shí)開(kāi)始，資源分配的工作。其中需要涉及到多個(gè)團(tuán)隊(duì)多個(gè)人員的配合和參與，還有不能按期交付帶來(lái)的風(fēng)險(xiǎn)預(yù)估等；關(guān)于性能測(cè)試需求評(píng)審，后續(xù)我會(huì)專(zhuān)門(mén)寫(xiě)篇博客來(lái)分析其中的一些細(xì)節(jié)。3、任翁腕性能測(cè)試任務(wù)經(jīng)過(guò)評(píng)估后決定進(jìn)行，接下來(lái)就是根據(jù)具體的工作安排，資源調(diào)配，進(jìn)行工作排期等進(jìn)一步的工作。四、用

4、例管理這里的用例，我指的是性能測(cè)試中包括基于任務(wù)類(lèi)型，資源等各方面情況來(lái)建立的業(yè)務(wù)模型來(lái)抽象管理，具體可分為下面三種業(yè)務(wù)模型：常規(guī)任務(wù)，指的是系統(tǒng)迭代或者新系統(tǒng)發(fā)布提出的性能需求，其中包括項(xiàng)目條線、系統(tǒng)名稱(chēng)、架構(gòu)、拓?fù)鋱D、相關(guān)人員信息、業(yè)務(wù)模型等具體信息。根據(jù)上述的情況進(jìn)行具體的被測(cè)系統(tǒng)場(chǎng)景建模分析，然后制定具體的測(cè)試用例。2、日常輪詢(xún)這一類(lèi)型可以參考持續(xù)集成中的自動(dòng)執(zhí)行和條件觸發(fā)等情況，設(shè)立定時(shí)任務(wù)對(duì)范圍內(nèi)的系統(tǒng)進(jìn)行性能測(cè)試，測(cè)試類(lèi)型主要包括并發(fā)、多節(jié)點(diǎn)等測(cè)試類(lèi)型。3、全鏈路壓測(cè)全鏈路壓測(cè)，主要是生產(chǎn)環(huán)境進(jìn)行的整體業(yè)務(wù)線的性能測(cè)試，具體內(nèi)容，可以參考我之前的博客：聊聊全鏈路壓測(cè)。五、環(huán)境管理

5、性能測(cè)試開(kāi)始的前提是有一個(gè)穩(wěn)定可滿(mǎn)足性能測(cè)試的環(huán)境，一般來(lái)說(shuō)都是在下面兩種環(huán)境進(jìn)行：1、UATUAT環(huán)境即我們俗稱(chēng)的用戶(hù)驗(yàn)收測(cè)試環(huán)境，相對(duì)來(lái)說(shuō)環(huán)境穩(wěn)定，且配置各方面和生產(chǎn)相同或者可以進(jìn)行等量代換，能滿(mǎ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ò)詳細(xì)的評(píng)估才能決定。全鏈路壓測(cè)的挑戰(zhàn)在于這幾點(diǎn)： 、業(yè)務(wù)模型梳理 、數(shù)據(jù)問(wèn)題，包括數(shù)據(jù)的真實(shí)可用性、數(shù)據(jù)隔離和數(shù)據(jù)脫敏；

6、 、環(huán)境隔離，不能影響到實(shí)際的生產(chǎn)業(yè)務(wù)； 、服務(wù)集群負(fù)載均衡，測(cè)試策略和服務(wù)間通信的問(wèn)題； 、容災(zāi)問(wèn)題，包括某些服務(wù)宕機(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)變化，包括閑置、使用（甚至預(yù)測(cè)何時(shí)可釋放出來(lái)供其他壓測(cè)任務(wù)使用等）、不可用（損壞或其他原因）等。3、異常管理當(dāng)性能測(cè)試進(jìn)行過(guò)程中，由于某些原因?qū)е路?wù)不

7、可用，就需要及時(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è)試中，需要準(zhǔn)備哪些數(shù)據(jù)呢？1、基礎(chǔ)數(shù)據(jù)基礎(chǔ)數(shù)據(jù)包括系統(tǒng)業(yè)務(wù)正常運(yùn)行所必須的數(shù)據(jù)，比如：電商平臺(tái)的SKU信息、庫(kù)存數(shù)據(jù)等，還有銀行的用戶(hù)信息、某些業(yè)務(wù)的相關(guān)數(shù)據(jù)等，可以通過(guò)從生產(chǎn)備份等手段來(lái)解決。2、預(yù)埋數(shù)據(jù)預(yù)埋數(shù)

8、據(jù)主要指的是DB層面，即性能測(cè)試需要模擬實(shí)際的環(huán)境，包括數(shù)據(jù)量等，從DB層面來(lái)說(shuō)，同一個(gè)庫(kù)表，數(shù)據(jù)量不同在同樣的業(yè)務(wù)模型下，其性能表現(xiàn)也是不同的。預(yù)埋數(shù)據(jù)的準(zhǔn)備，可以通過(guò)從生產(chǎn)備份，或者通過(guò)腳本、SQL語(yǔ)句來(lái)自定義準(zhǔn)備一些可用的數(shù)據(jù)。3、測(cè)試數(shù)據(jù)測(cè)試腳本運(yùn)行所必需的數(shù)據(jù)，通常可以通過(guò)參數(shù)化的方式來(lái)解決。當(dāng)然，從測(cè)試平臺(tái)的角度，解決這個(gè)問(wèn)題的方法可以通過(guò)統(tǒng)一的數(shù)據(jù)池來(lái)做管理，界面通過(guò)不同的選擇項(xiàng)，調(diào)用API來(lái)生成測(cè)試可用的數(shù)據(jù)。八、監(jiān)控管理性能測(cè)試中，監(jiān)控是必不可少的重要一環(huán)，通常來(lái)說(shuō)，需要監(jiān)控的包括以下幾個(gè)方面：1、前端性能前端展示、資源渲染所花費(fèi)的時(shí)間，哪些資源耗費(fèi)了最多的時(shí)間和資源，都是需

9、要通過(guò)監(jiān)控來(lái)得到相關(guān)信息。2、中間件 、Redis有些系統(tǒng)架構(gòu)利用Redis來(lái)做持久層或者緩沖區(qū)，那么對(duì)于緩存的可用性和緩存失效、緩存穿透等信息，也是必須要監(jiān)控的。 、MQMQ是一個(gè)異步的通信框架，類(lèi)似的還有kafka等框架，對(duì)于消息隊(duì)列的生產(chǎn)和消費(fèi)速率，資源占用，可能的堵塞等情況進(jìn)行監(jiān)控，也是必不可少的。 、其他3、容器現(xiàn)在越來(lái)越多的企業(yè)開(kāi)始將服務(wù)容器化（特別是在微服務(wù)的架構(gòu)中，容器化是必要的一種手段），包括環(huán)境、腳本、服務(wù)都放在容器中。那么對(duì)容器資源的監(jiān)控，也是非常必須的。4、服務(wù)器服務(wù)器的監(jiān)控，主要是內(nèi)存、CPU、10等方面，包括占比、使用率、閾值和提醒等。5、DB數(shù)據(jù)庫(kù)層面，主要監(jiān)控的

10、內(nèi)存、CPU等信息，當(dāng)然也包括SQL語(yǔ)句執(zhí)行耗費(fèi)時(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)看，都是從用戶(hù)層到最終的服務(wù)處理層，層層進(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這里可以理解為用戶(hù)層的日志，包括資源的本地加載、緩存等信息（由于某些情況下詳盡的日志包較大，

11、采用了日志寫(xiě)入用戶(hù)層的操作）。2、app這里代指應(yīng)用層，有時(shí)候出現(xiàn)性能問(wèn)題的原因發(fā)生在應(yīng)用層，那么對(duì)應(yīng)用層的監(jiān)控，日志分析也是很重要的。3、service后臺(tái)服務(wù)層，日志包括處理了哪些操作，哪個(gè)請(qǐng)求甚至哪里調(diào)用等。4、DB數(shù)據(jù)庫(kù)日志，同理，哪些操作耗費(fèi)的時(shí)間長(zhǎng)、資源多等，都是需要對(duì)應(yīng)的監(jiān)控和必要的日志分析，才能看出問(wèn)題。PS:上述的幾種日志管理，從性能測(cè)試平臺(tái)角度來(lái)說(shuō)，都是希望將日志更直觀的進(jìn)行展示、篩選，否則我們需要通過(guò)命令或者其他工具的方式，到具體的層級(jí)去查找分析日志，這樣無(wú)疑會(huì)浪費(fèi)一定的時(shí)間。十、報(bào)表管理報(bào)表管理主要包括下面幾個(gè)方面：1、實(shí)時(shí)結(jié)果將測(cè)試的實(shí)時(shí)監(jiān)控結(jié)果存入數(shù)據(jù)庫(kù)，然后通過(guò)g

12、rafana等工具展示在界面上，更直觀的對(duì)測(cè)試結(jié)果進(jìn)行管理。2、測(cè)試報(bào)告每輪測(cè)試結(jié)束，都需要對(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é)果作為一個(gè)性能參考基線，后續(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)用不同的服務(wù)接口來(lái)進(jìn)行模擬并發(fā)，進(jìn)行測(cè)試，但有

13、時(shí)候由于某些原因，導(dǎo)致一部分服務(wù)暫時(shí)不可用，或者次數(shù)限制，這種情況急需要用到mock服務(wù)。、HttpMockHTTP是最常見(jiàn)的一種協(xié)議，而且隨著微服務(wù)的流行，restful風(fēng)格架構(gòu)設(shè)計(jì)的運(yùn)用，HttpMock的擋板服務(wù)，就變成一種常規(guī)需要。 、SocketMockTCP連接也是某些業(yè)務(wù)系統(tǒng)服務(wù)實(shí)現(xiàn)通信的方式，為了方便的進(jìn)行性能測(cè)試而降低對(duì)其他某些服務(wù)的依賴(lài)，SocketMock擋板服務(wù)，也是必不可少的。 、其他包括dubbo接口等其他類(lèi)型的接口調(diào)用，可以針對(duì)性的進(jìn)行設(shè)計(jì)，將mock變?yōu)橐环N服務(wù)。PS:從測(cè)試管理平臺(tái)的角度來(lái)說(shuō)，將Mock對(duì)象編程服務(wù)，通過(guò)界面進(jìn)行增刪改查的管理，更方便了管理和直觀的理解。2、容器 、docker容器化，是這幾年越來(lái)越流行的一個(gè)趨勢(shì)，對(duì)不同的測(cè)試環(huán)境的docker容器管理，也是必不可少的。 、虛機(jī)限于不同項(xiàng)目不同技術(shù)架構(gòu)