關於性能測試平臺的一些想法

最近剛入職新公司，忙着適應公司的文化、工做流程的一些東西。由於部門要開發性能測試管理平臺，今天郵件中我也對性能測試平臺的設計提了一些本身的想法。

這篇博客，就說說我對性能測試管理平臺設計的一些構思，僅供參考。。。

 

組織架構

這裏我按照每一個不一樣系統歸屬的項目組爲橫向，性能測試團隊做爲職能部門爲縱向的矩陣式組織架構爲例，來介紹性能測試管理平臺的構思。

思惟導圖

 

1、任務管理

一、任務申請

通常來講，性能測試需求的來源有2個方面：

①、項目組提需求

項目組主動提性能測試需求，須要一個統一的性能測試任務管理的模塊，其中包括被測系統歸屬的項目條線、系統名稱、系統架構圖、網絡拓撲圖、相關設計文檔及相關環境的配置信息，

以及項目經理、開發、運維、DB等聯繫方式，還有被測系統交付測試時間，deadline時間等信息。

這種狀況又能夠分爲三種類型：

新系統發佈：新的系統發佈上線，須要對功能，性能，安全等各方面作一個完整的測試，評估是否達到業務、產品既定的上線要求。

老系統迭代：已有系統進行某些優化，新功能的增長或者新的業務渠道引入，可能帶來更高的流量衝擊，這時候項目經理或者開發經理會提出相關的性能需求，但願驗證已有系統是否知足上線須要。

生產事故修復驗證：系統在生產環境遇到性能問題帶來了某些損失，通過調優或修復後須要進行一輪全面的性能測試來評估是否知足已有的實際業務需求。

②、性能組提需求

針對項目的迭代、新需求的引入帶來的可能存在的性能瓶頸主動提出，而後通過評估，決定是否進行測試，來評估系統的穩定性可用性等。

二、任務審批

性能測試任務申請提交後，就須要項目組、性能組甚至其餘相關人員根據現有狀況，工做安排，工期等進行綜合評估，來決定是否進行性能測試以及什麼時候開始，資源分配的工做。

其中須要涉及到多個團隊多我的員的配合和參與，還有不能定期交付帶來的風險預估等；關於性能測試需求評審，後續我會專門寫篇博客來分析其中的一些細節。

三、任務排期

性能測試任務通過評估後決定進行，接下來就是根據具體的工做安排，資源調配，進行工做排期等進一步的工做。

 

2、用例管理

這裏的用例，我指的是性能測試中包括基於任務類型，資源等各方面狀況來創建的業務模型來抽象管理，具體可分爲下面三種業務模型：

一、常規任務

常規任務，指的是系統迭代或者新系統發佈提出的性能需求，其中包括項目條線、系統名稱、架構、拓撲圖、相關人員信息、業務模型等具體信息。

根據上述的狀況進行具體的被測系統場景建模分析，而後制定具體的測試用例。

二、平常輪詢

這一類型能夠參考持續集成中的自動執行和條件觸發等狀況，設立定時任務對範圍內的系統進行性能測試，測試類型主要包括併發、多節點等測試類型。

三、全鏈路壓測

全鏈路壓測，主要是生產環境進行的總體業務線的性能測試，具體內容，能夠參考我以前的博客：聊聊全鏈路壓測。

 

3、環境管理

性能測試開始的前提是有一個穩定可知足性能測試的環境，通常來講都是在下面兩種環境進行：

一、UAT

UAT環境即咱們俗稱的用戶驗收測試環境，相對來講環境穩定，且配置各方面和生產相同或者能夠進行等量代換，能知足常規的性能測試須要。

二、FAT

FAT環境可理解爲生產驗證測試環境，系統版本，配置、數據量等和生產保持一致，這樣從可測試性和真實性上更符合實際的生產狀況。

PS：還有全鏈路壓測是在真實的生產環境進行，可是生產環境進行性能測試的風險太大，且對現有系統的改造工做較多，是否進行還須要通過詳細的評估才能決定。

全鏈路壓測的挑戰在於這幾點：

①、業務模型梳理

②、數據問題，包括數據的真實可用性、數據隔離和數據脫敏；

③、環境隔離，不能影響到實際的生產業務；

④、服務集羣負載均衡，測試策略和服務間通訊的問題；

⑤、容災問題，包括某些服務宕機或者不可用時，不能對實際生產業務運行形成影響，系統可用性等；

 

4、壓測機管理

一、壓測機調度

實際的流量衝擊較高時，單個壓力機可能沒法支持，這時候就須要多個壓力執行機來分佈式的進行壓測。

在實際生產環境，流量的變化頗有多是隨機的，如何作好壓測執行機的增長和縮小，合理利用資源，是須要考慮和解決的問題。

二、狀態管理

這裏主要包括壓測機的狀態變化，包括閒置、使用（甚至預測什麼時候可釋放出來供其餘壓測任務使用等）、不可用（損壞或其餘緣由）等。

三、異常管理

當性能測試進行過程當中，因爲某些緣由致使服務不可用，就須要及時的中止性能壓測，通常來講主要是下面幾種手段：

①、手動中止：從管理界面的功能按鈕來中止壓測執行；

②、熔斷措施：即經過監控報警措施，當系統不可用或超過某個閾值時，自動中止壓測；

③、兜底手段：當手動中止或者自動熔斷措施都不可用時，從外部的某些手段來中止壓測執行，這也算一種容災措施；

相關資料可參考餓了麼全鏈路壓測平臺的實現與原理。

 

5、數據管理

測試是須要數據來驅動的，那麼在性能測試中，須要準備哪些數據呢？

一、基礎數據

基礎數據包括系統業務正常運行所必須的數據，好比：電商平臺的SKU信息、庫存數據等，還有銀行的用戶信息、某些業務的相關數據等，能夠經過從生產備份等手段來解決。

二、預埋數據

預埋數據主要指的是DB層面，即性能測試須要模擬實際的環境，包括數據量等，從DB層面來講，同一個庫表，數據量不一樣在一樣的業務模型下，其性能表現也是不一樣的。

預埋數據的準備，能夠經過從生產備份，或者經過腳本、SQL語句來自定義準備一些可用的數據。

三、測試數據

測試腳本運行所必需的數據，一般能夠經過參數化的方式來解決。

固然，從測試平臺的角度，解決這個問題的方法能夠經過統一的數據池來作管理，界面經過不一樣的選擇項，調用API來生成測試可用的數據。

 

6、監控管理

性能測試中，監控是必不可少的重要一環，一般來講，須要監控的包括如下幾個方面：

一、前端性能

前端展現、資源渲染所花費的時間，哪些資源耗費了最多的時間和資源，都是須要經過監控來獲得相關信息。

二、中間件

①、Redis

有些系統架構利用Redis來作持久層或者緩衝區，那麼對於緩存的可用性和緩存失效、緩存穿透等信息，也是必需要監控的。

②、MQ

MQ是一個異步的通訊框架，相似的還有kafka等框架，對於消息隊列的生產和消費速率，資源佔用，可能的堵塞等狀況進行監控，也是必不可少的。

③、其餘

三、容器

如今愈來愈多的企業開始將服務容器化（特別是在微服務的架構中，容器化是必要的一種手段），包括環境、腳本、服務都放在容器中。

那麼對容器資源的監控，也是很是必須的。

四、服務器

服務器的監控，主要是內存、CPU、IO等方面，包括佔比、使用率、閾值和提醒等。

五、DB

數據庫層面，主要監控的內存、CPU等信息，固然也包括SQL語句執行耗費時間、鎖等狀況。

六、網絡

網絡是必不可少的一環，不穩定的網絡環境對測試結果的影響很大，可能會帶來一些隱藏的問題；網絡監控通常關注這幾個方面：穩定性、網關、CDN、防火牆等方面。

PS：實際上從上面的幾種監控來看，都是從用戶層到最終的服務處理層，層層進行監控，作到一切用數聽說話。

 

7、日誌管理

在測試過程當中，有時候不能從測試數據直觀的看到隱藏的問題，就須要查看對應的日誌，從詳盡的日誌中分析爆發問題的節點，而後進行鍼對性的分析。日誌監控，大概分下面幾個層級：

一、web

這裏能夠理解爲用戶層的日誌，包括資源的本地加載、緩存等信息（因爲某些狀況下詳盡的日誌包較大，採用了日誌寫入用戶層的操做）。

二、app

這裏代指應用層，有時候出現性能問題的緣由發生在應用層，那麼對應用層的監控，日誌分析也是很重要的。

三、service

後臺服務層，日誌包括處理了哪些操做，哪一個請求甚至哪裏調用等。

四、DB

數據庫日誌，同理，哪些操做耗費的時間長、資源多等，都是須要對應的監控和必要的日誌分析，才能看出問題。

PS：上述的幾種日誌管理，從性能測試平臺角度來講，都是但願將日誌更直觀的進行展現、篩選，不然咱們須要經過命令或者其餘工具的方式，到具體的層級去查找分析日誌，這樣無疑會浪費必定的時間。

 

8、報表管理

報表管理主要包括下面幾個方面：

一、實時結果

將測試的實時監控結果存入數據庫，而後經過grafana等工具展現在界面上，更直觀的對測試結果進行管理。

二、測試報告

每輪測試結束，都須要對測試結果進行統計分析，以便於做爲一個基點，對下一次測試提供參考和評估依據；測試報告界面能夠經過自定義的樣式來展示。

三、性能基線

這裏的性能基線，指的是：將每次性能測試的最終結果做爲一個性能參考基線，後續的每次迭代，以上次性能測試結果爲評估點，而後持續更新性能基線，做爲下一次的評估依據。

能夠經過數據折線、樹狀圖等多種方式來展示，目的是爲長期的系統穩定性、可用性作一個監控，爲系統調優或重構提供多種維度的參考依據。

 

9、配置管理

一、擋板

通常來講，性能測試都是經過調用不一樣的服務接口來進行模擬併發，進行測試，但有時候因爲某些緣由，致使一部分服務暫時不可用，或者次數限制，這種狀況急須要用到mock服務。

①、HttpMock

HTTP是最多見的一種協議，並且隨着微服務的流行，restful風格架構設計的運用，HttpMock的擋板服務，就變成一種常規須要。

②、SocketMock

TCP鏈接也是某些業務系統服務實現通訊的方式，爲了方便的進行性能測試而下降對其餘某些服務的依賴，SocketMock擋板服務，也是必不可少的。

③、其餘

包括dubbo接口等其餘類型的接口調用，能夠針對性的進行設計，將mock變爲一種服務。

PS：從測試管理平臺的角度來講，將Mock對象編程服務，經過界面進行增刪改查的管理，更方便了管理和直觀的理解。

二、容器

①、docker

容器化，是這幾年愈來愈流行的一個趨勢，對不一樣的測試環境的docker容器管理，也是必不可少的。

②、虛機

限於不一樣項目不一樣技術架構的狀況，虛擬機管理這一項，能夠根據具體的須要來進行設計，若是所有容器化，那麼虛擬機管理，沒有也罷。

 

10、系統管理

一、用戶管理

包括使用這個系統的用戶註冊、新增、刪除，狀態管理等功能，以及可能須要的任務分配等操做。

二、權限管理

不一樣的用戶角色，分配不一樣的系統使用權限，能夠利用單點登陸的原理來設計這一模塊。

三、組管理

這裏的組管理，我我的理解爲基於身份和角色不一樣所劃分的職能組，對其進行新增、權限職能分配、狀態變動等功能的管理。

 

以上內容僅是我我的的一些構思和想法，還有不少不足之處和值得深刻討論的地方，若有更好的建議，請在評論區指出，謝謝。。。