最近剛入職新公司，忙着適應公司的文化、工作流程的一些東西。因為部門要開發性能測試管理平台，今天郵件中我也對性能測試平台的設計提了一些自己的想法。
這篇博客，就說說我對性能測試管理平台設計的一些構思，僅供參考。。。
組織架構
這里我按照每個不同系統歸屬的項目組為橫向，性能測試團隊作為職能部門為縱向的矩陣式組織架構為例，來介紹性能測試管理平台的構思。
思維導圖
一、任務管理
1、任務申請
一般來說，性能測試需求的來源有2個方面：
①、項目組提需求
項目組主動提性能測試需求，需要一個統一的性能測試任務管理的模塊，其中包括被測系統歸屬的項目條線、系統名稱、系統架構圖、網絡拓撲圖、相關設計文檔及相關環境的配置信息，
以及項目經理、開發、運維、DB等聯系方式，還有被測系統交付測試時間，deadline時間等信息。
這種情況又可以分為三種類型：
新系統發布：新的系統發布上線，需要對功能，性能，安全等各方面做一個完整的測試，評估是否達到業務、產品既定的上線要求。
老系統迭代：已有系統進行某些優化，新功能的增加或者新的業務渠道引入，可能帶來更高的流量沖擊，這時候項目經理或者開發經理會提出相關的性能需求，希望驗證已有系統是否滿足上線需要。
生產事故修復驗證：系統在生產環境遇到性能問題帶來了某些損失，經過調優或修復后需要進行一輪全面的性能測試來評估是否滿足已有的實際業務需求。
②、性能組提需求
針對項目的迭代、新需求的引入帶來的可能存在的性能瓶頸主動提出，然后經過評估，決定是否進行測試，來評估系統的穩定性可用性等。
2、任務審批
性能測試任務申請提交后，就需要項目組、性能組甚至其他相關人員根據現有情況，工作安排，工期等進行綜合評估，來決定是否進行性能測試以及何時開始，資源分配的工作。
其中需要涉及到多個團隊多個人員的配合和參與，還有不能按期交付帶來的風險預估等；關於性能測試需求評審，后續我會專門寫篇博客來分析其中的一些細節。
3、任務排期
性能測試任務經過評估后決定進行，接下來就是根據具體的工作安排，資源調配，進行工作排期等進一步的工作。
二、用例管理
這里的用例，我指的是性能測試中包括基於任務類型，資源等各方面情況來建立的業務模型來抽象管理，具體可分為下面三種業務模型：
1、常規任務
常規任務，指的是系統迭代或者新系統發布提出的性能需求，其中包括項目條線、系統名稱、架構、拓撲圖、相關人員信息、業務模型等具體信息。
根據上述的情況進行具體的被測系統場景建模分析，然后制定具體的測試用例。
2、日常輪詢
這一類型可以參考持續集成中的自動執行和條件觸發等情況，設立定時任務對范圍內的系統進行性能測試，測試類型主要包括並發、多節點等測試類型。
3、全鏈路壓測
全鏈路壓測，主要是生產環境進行的整體業務線的性能測試，具體內容，可以參考我之前的博客：聊聊全鏈路壓測。
三、環境管理
性能測試開始的前提是有一個穩定可滿足性能測試的環境，一般來說都是在下面兩種環境進行：
1、UAT
UAT環境即我們俗稱的用戶驗收測試環境，相對來說環境穩定，且配置各方面和生產相同或者可以進行等量代換，能滿足常規的性能測試需要。
2、FAT
FAT環境可理解為生產驗證測試環境，系統版本，配置、數據量等和生產保持一致，這樣從可測試性和真實性上更符合實際的生產情況。
PS：還有全鏈路壓測是在真實的生產環境進行，但是生產環境進行性能測試的風險太大，且對現有系統的改造工作較多，是否進行還需要經過詳細的評估才能決定。
全鏈路壓測的挑戰在於這幾點：
①、業務模型梳理
②、數據問題，包括數據的真實可用性、數據隔離和數據脫敏；
③、環境隔離，不能影響到實際的生產業務；
④、服務集群負載均衡，測試策略和服務間通信的問題；
⑤、容災問題，包括某些服務宕機或者不可用時，不能對實際生產業務運行造成影響，系統可用性等；
四、壓測機管理
1、壓測機調度
實際的流量沖擊較高時，單個壓力機可能無法支持，這時候就需要多個壓力執行機來分布式的進行壓測。
在實際生產環境，流量的變化很有可能是隨機的，如何做好壓測執行機的增加和縮小，合理利用資源，是需要考慮和解決的問題。
2、狀態管理
這里主要包括壓測機的狀態變化，包括閑置、使用（甚至預測何時可釋放出來供其他壓測任務使用等）、不可用（損壞或其他原因）等。
3、異常管理
當性能測試進行過程中，由於某些原因導致服務不可用，就需要及時的停止性能壓測，一般來說主要是下面幾種手段：
①、手動停止：從管理界面的功能按鈕來停止壓測執行；
②、熔斷措施：即通過監控報警措施，當系統不可用或超過某個閾值時，自動停止壓測；
③、兜底手段：當手動停止或者自動熔斷措施都不可用時，從外部的某些手段來停止壓測執行，這也算一種容災措施；
相關資料可參考餓了么全鏈路壓測平台的實現與原理。
五、數據管理
測試是需要數據來驅動的，那么在性能測試中，需要准備哪些數據呢？
1、基礎數據
基礎數據包括系統業務正常運行所必須的數據，比如：電商平台的SKU信息、庫存數據等，還有銀行的用戶信息、某些業務的相關數據等，可以通過從生產備份等手段來解決。
2、預埋數據
預埋數據主要指的是DB層面，即性能測試需要模擬實際的環境，包括數據量等，從DB層面來說，同一個庫表，數據量不同在同樣的業務模型下，其性能表現也是不同的。
預埋數據的准備，可以通過從生產備份，或者通過腳本、SQL語句來自定義准備一些可用的數據。
3、測試數據
測試腳本運行所必需的數據，通常可以通過參數化的方式來解決。
當然，從測試平台的角度，解決這個問題的方法可以通過統一的數據池來做管理，界面通過不同的選擇項，調用API來生成測試可用的數據。
六、監控管理
性能測試中，監控是必不可少的重要一環，通常來說，需要監控的包括以下幾個方面：
1、前端性能
前端展示、資源渲染所花費的時間，哪些資源耗費了最多的時間和資源，都是需要通過監控來得到相關信息。
2、中間件
①、Redis
有些系統架構利用Redis來做持久層或者緩沖區，那么對於緩存的可用性和緩存失效、緩存穿透等信息，也是必須要監控的。
②、MQ
MQ是一個異步的通信框架，類似的還有kafka等框架，對於消息隊列的生產和消費速率，資源占用，可能的堵塞等情況進行監控，也是必不可少的。
③、其他
3、容器
現在越來越多的企業開始將服務容器化（特別是在微服務的架構中，容器化是必要的一種手段），包括環境、腳本、服務都放在容器中。
那么對容器資源的監控，也是非常必須的。
4、服務器
服務器的監控，主要是內存、CPU、IO等方面，包括占比、使用率、閾值和提醒等。
5、DB
數據庫層面，主要監控的內存、CPU等信息，當然也包括SQL語句執行耗費時間、鎖等情況。
6、網絡
網絡是必不可少的一環，不穩定的網絡環境對測試結果的影響很大，可能會帶來一些隱藏的問題；網絡監控一般關注這幾個方面：穩定性、網關、CDN、防火牆等方面。
PS：實際上從上面的幾種監控來看，都是從用戶層到最終的服務處理層，層層進行監控，做到一切用數據說話。
七、日志管理
在測試過程中，有時候不能從測試數據直觀的看到隱藏的問題，就需要查看對應的日志，從詳盡的日志中分析爆發問題的節點，然后進行針對性的分析。日志監控，大概分下面幾個層級：
1、web
這里可以理解為用戶層的日志，包括資源的本地加載、緩存等信息（由於某些情況下詳盡的日志包較大，采用了日志寫入用戶層的操作）。
2、app
這里代指應用層，有時候出現性能問題的原因發生在應用層，那么對應用層的監控，日志分析也是很重要的。
3、service
后台服務層，日志包括處理了哪些操作，哪個請求甚至哪里調用等。
4、DB
數據庫日志，同理，哪些操作耗費的時間長、資源多等，都是需要對應的監控和必要的日志分析，才能看出問題。
PS：上述的幾種日志管理，從性能測試平台角度來說，都是希望將日志更直觀的進行展示、篩選，否則我們需要通過命令或者其他工具的方式，到具體的層級去查找分析日志，這樣無疑會浪費一定的時間。
八、報表管理
報表管理主要包括下面幾個方面：
1、實時結果
將測試的實時監控結果存入數據庫，然后通過grafana等工具展示在界面上，更直觀的對測試結果進行管理。
2、測試報告
每輪測試結束，都需要對測試結果進行統計分析，以便於作為一個基點，對下一次測試提供參考和評估依據；測試報告界面可以通過自定義的樣式來展現。
3、性能基線
這里的性能基線，指的是：將每次性能測試的最終結果作為一個性能參考基線，后續的每次迭代，以上次性能測試結果為評估點，然后持續更新性能基線，作為下一次的評估依據。
可以通過數據折線、樹狀圖等多種方式來展現，目的是為長期的系統穩定性、可用性做一個監控，為系統調優或重構提供多種維度的參考依據。
九、配置管理
1、擋板
一般來說，性能測試都是通過調用不同的服務接口來進行模擬並發，進行測試，但有時候由於某些原因，導致一部分服務暫時不可用，或者次數限制，這種情況急需要用到mock服務。
①、HttpMock
HTTP是最常見的一種協議，而且隨着微服務的流行，restful風格架構設計的運用，HttpMock的擋板服務，就變成一種常規需要。
②、SocketMock
TCP連接也是某些業務系統服務實現通信的方式，為了方便的進行性能測試而降低對其他某些服務的依賴，SocketMock擋板服務，也是必不可少的。
③、其他
包括dubbo接口等其他類型的接口調用，可以針對性的進行設計，將mock變為一種服務。
PS：從測試管理平台的角度來說，將Mock對象編程服務，通過界面進行增刪改查的管理，更方便了管理和直觀的理解。
2、容器
①、docker
容器化，是這幾年越來越流行的一個趨勢，對不同的測試環境的docker容器管理，也是必不可少的。
②、虛機
限於不同項目不同技術架構的情況，虛擬機管理這一項，可以根據具體的需要來進行設計，如果全部容器化，那么虛擬機管理，沒有也罷。
十、系統管理
1、用戶管理
包括使用這個系統的用戶注冊、新增、刪除，狀態管理等功能，以及可能需要的任務分配等操作。
2、權限管理
不同的用戶角色，分配不同的系統使用權限，可以利用單點登錄的原理來設計這一模塊。
3、組管理
這里的組管理，我個人理解為基於身份和角色不同所划分的職能組，對其進行新增、權限職能分配、狀態變更等功能的管理。
以上內容僅是我個人的一些構思和想法，還有很多不足之處和值得深入討論的地方，如有更好的建議，請在評論區指出，謝謝。。。