1、軟件性能測試平臺的建設說明一、組織架構這里我按照每個不同系統歸屬的項目組為橫向，性能測試團隊作為職能部門為縱向的矩陣式組織架構為例，來介紹性能測試管理平臺的構思。二思維導圖料爵申埔柱務申批4F呼卄IU1中IM件DB業務捲楓汀試也未-I繭輪曲webJRPsnriccUBJATPA1訓度停止吶-并常氾底4、圧測機管理性能測試骨即平臺宜吋鮎果側試槪汕HITPMo匚klife-10,毎辦悴理百門匚kerMnrk其他dtocker虛機用戶評利限習艸三、任務管理1、任務申請一般來說，性能測試需求的來源有2個方面： 、項目組提需求項目組主動提性能測試需求，需要一個統一的性能測試任務管理的模塊，其中包括被測系

2、統歸屬的項目條線、系統名稱、系統架構圖、網絡拓撲圖、相關設計文檔及相關環境的配置信息，以及項目經理、開發、運維、DB等聯系方式，還有被測系統交付測試時間,deadline時間等信息。這種情況又可以分為三種類型：新系統發布：新的系統發布上線，需要對功能，性能，安全等各方面做一個完整的測試，評估是否達到業務、產品既定的上線要求。老系統迭代：已有系統進行某些優化，新功能的增加或者新的業務渠道引入，可能帶來更高的流量沖擊，這時候項目經理或者開發經理會提出相關的性能需求，希望驗證已有系統是否滿足上線需要。生產事故修復驗證：系統在生產環境遇到性能問題帶來了某些損失，經過調優或修復后需要進行一輪全面的性能測

3、試來評估是否滿足已有的實際業務需求。 、性能S提需求針對項目的迭代、新需求的引入帶來的可能存在的性能瓶頸主動提出，然后經過評估，決定是否進行測試，來評估系統的穩定性可用性等。2、任翁審批性能測試任務申請提交后，就需要項目組、性能組甚至其他相關人員根據現有情況，工作安排，工期等進行綜合評估，來決定是否進行性能測試以及何時開始，資源分配的工作。其中需要涉及到多個團隊多個人員的配合和參與，還有不能按期交付帶來的風險預估等；關于性能測試需求評審，后續我會專門寫篇博客來分析其中的一些細節。3、任翁腕性能測試任務經過評估后決定進行，接下來就是根據具體的工作安排，資源調配，進行工作排期等進一步的工作。四、用

4、例管理這里的用例，我指的是性能測試中包括基于任務類型，資源等各方面情況來建立的業務模型來抽象管理，具體可分為下面三種業務模型：常規任務，指的是系統迭代或者新系統發布提出的性能需求，其中包括項目條線、系統名稱、架構、拓撲圖、相關人員信息、業務模型等具體信息。根據上述的情況進行具體的被測系統場景建模分析，然后制定具體的測試用例。2、日常輪詢這一類型可以參考持續集成中的自動執行和條件觸發等情況，設立定時任務對范圍內的系統進行性能測試，測試類型主要包括并發、多節點等測試類型。3、全鏈路壓測全鏈路壓測，主要是生產環境進行的整體業務線的性能測試，具體內容，可以參考我之前的博客：聊聊全鏈路壓測。五、環境管理

5、性能測試開始的前提是有一個穩定可滿足性能測試的環境，一般來說都是在下面兩種環境進行：1、UATUAT環境即我們俗稱的用戶驗收測試環境，相對來說環境穩定，且配置各方面和生產相同或者可以進行等量代換，能滿足常規的性能測試需要。2、FATFAT環境可理解為生產驗證測試環境，系統版本，配置、數據量等和生產保持一致，這樣從可測試性和真實性上更符合實際的生產情況。PS:還有全鏈路壓測是在真實的生產環境進行，但是生產環境進行性能測試的風險太大，且對現有系統的改造工作較多，是否進行還需要經過詳細的評估才能決定。全鏈路壓測的挑戰在于這幾點： 、業務模型梳理 、數據問題，包括數據的真實可用性、數據隔離和數據脫敏；

6、 、環境隔離，不能影響到實際的生產業務； 、服務集群負載均衡，測試策略和服務間通信的問題； 、容災問題，包括某些服務宕機或者不可用時，不能對實際生產業務運行造成影響，系統可用性等；丸壓測機管理1、壓測機調度實際的流量沖擊較高時，單個壓力機可能無法支持，這時候就需要多個壓力執行機來分布式的進行壓測。在實際生產環境，流量的變化很有可能是隨機的，如何做好壓測執行機的增加和縮小，合理利用資源，是需要考慮和解決的問題。2、狀態管理這里主要包括壓測機的狀態變化，包括閑置、使用（甚至預測何時可釋放出來供其他壓測任務使用等）、不可用（損壞或其他原因）等。3、異常管理當性能測試進行過程中，由于某些原因導致服務不

7、可用，就需要及時的停止性能壓測，一般來說主要是下面幾種手段： 、手動停止：從管理界面的功能按鈕來停止壓測執行； 、熔斷措施：即通過監控報警措施，當系統不可用或超過某個閾值時，自動停止壓測； 、兜底手段：當手動停止或者自動熔斷措施都不可用時，從外部的某些手段來停止壓測執行，這也算一種容災措施；相關資料可參考餓了么全鏈路壓測平臺的實現與原理。七、數據管理測試是需要數據來驅動的，那么在性能測試中，需要準備哪些數據呢？1、基礎數據基礎數據包括系統業務正常運行所必須的數據，比如：電商平臺的SKU信息、庫存數據等，還有銀行的用戶信息、某些業務的相關數據等，可以通過從生產備份等手段來解決。2、預埋數據預埋數

8、據主要指的是DB層面，即性能測試需要模擬實際的環境，包括數據量等，從DB層面來說，同一個庫表，數據量不同在同樣的業務模型下，其性能表現也是不同的。預埋數據的準備，可以通過從生產備份，或者通過腳本、SQL語句來自定義準備一些可用的數據。3、測試數據測試腳本運行所必需的數據，通常可以通過參數化的方式來解決。當然，從測試平臺的角度，解決這個問題的方法可以通過統一的數據池來做管理，界面通過不同的選擇項，調用API來生成測試可用的數據。八、監控管理性能測試中，監控是必不可少的重要一環，通常來說，需要監控的包括以下幾個方面：1、前端性能前端展示、資源渲染所花費的時間，哪些資源耗費了最多的時間和資源，都是需

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

10、內存、CPU等信息，當然也包括SQL語句執行耗費時間、鎖等情況。6、網絡網絡是必不可少的一環，不穩定的網絡環境對測試結果的影響很大，可能會帶來一些隱藏的問題；網絡監控一般關注這幾個方面：穩定性、網關、CDN、防火墻等方面。PS:實際上從上面的幾種監控來看，都是從用戶層到最終的服務處理層，層層進行監控，做到一切用數據說話。九、日志管理在測試過程中，有時候不能從測試數據直觀的看到隱藏的問題，就需要查看對應的日志，從詳盡的日志中分析爆發問題的節點，然后進行針對性的分析。日志監控，大概分下面幾個層級：1、web這里可以理解為用戶層的日志，包括資源的本地加載、緩存等信息（由于某些情況下詳盡的日志包較大，

11、采用了日志寫入用戶層的操作）。2、app這里代指應用層，有時候出現性能問題的原因發生在應用層，那么對應用層的監控，日志分析也是很重要的。3、service后臺服務層，日志包括處理了哪些操作，哪個請求甚至哪里調用等。4、DB數據庫日志，同理，哪些操作耗費的時間長、資源多等，都是需要對應的監控和必要的日志分析，才能看出問題。PS:上述的幾種日志管理，從性能測試平臺角度來說，都是希望將日志更直觀的進行展示、篩選，否則我們需要通過命令或者其他工具的方式，到具體的層級去查找分析日志，這樣無疑會浪費一定的時間。十、報表管理報表管理主要包括下面幾個方面：1、實時結果將測試的實時監控結果存入數據庫，然后通過g

12、rafana等工具展示在界面上，更直觀的對測試結果進行管理。2、測試報告每輪測試結束，都需要對測試結果進行統計分析，以便于作為一個基點，對下一次測試提供參考和評估依據；測試報告界面可以通過自定義的樣式來展現。3、性能基線這里的性能基線，指的是：將每次性能測試的最終結果作為一個性能參考基線，后續的每次迭代，以上次性能測試結果為評估點，然后持續更新性能基線，作為下一次的評估依據。可以通過數據折線、樹狀圖等多種方式來展現，目的是為長期的系統穩定性、可用性做一個監控，為系統調優或重構提供多種維度的參考依據。十一、配置管理1、擋板一般來說，性能測試都是通過調用不同的服務接口來進行模擬并發，進行測試，但有

13、時候由于某些原因，導致一部分服務暫時不可用，或者次數限制，這種情況急需要用到mock服務。、HttpMockHTTP是最常見的一種協議，而且隨著微服務的流行，restful風格架構設計的運用，HttpMock的擋板服務，就變成一種常規需要。 、SocketMockTCP連接也是某些業務系統服務實現通信的方式，為了方便的進行性能測試而降低對其他某些服務的依賴，SocketMock擋板服務，也是必不可少的。 、其他包括dubbo接口等其他類型的接口調用，可以針對性的進行設計，將mock變為一種服務。PS:從測試管理平臺的角度來說，將Mock對象編程服務，通過界面進行增刪改查的管理，更方便了管理和直觀的理解。2、容器 、docker容器化，是這幾年越來越流行的一個趨勢，對不同的測試環境的docker容器管理，也是必不可少的。 、虛機限于不同項目不同技術架構