軟件性能測試平臺的建設(shè)說明

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