聊聊性能測試平臺

1. 背景

在剛過去的2020年，我司的全鏈路壓測平臺已成功落地。今天呢，寶路就來聊聊本身對性能測試平臺設計的一些想法與思考！

2. 平臺思惟導

 

2.1 需求工做流

工做流確保了測試按約定步驟推動，同時讓工做的透明度和可再現性。咱們工做中經常使用的有JIRA、TAPD等。平臺是徹底能夠與之進行對接的。

一般狀況下壓測需求可能由開發部門、業務部門、運維部門發起，測試組接收到壓測需求後須要對測試需求調研、評估。

壓測需求經過評審後，測試組根據實際狀況進行排期、制定壓測方案計劃。測試組完成壓測方案計劃後可向項目發起方案評審。多方會議評審經過後，則可進入壓測實施、直至測試組完成壓測工做，發出性能測試報告。

上面所述的是一個大體的流程，在實施的過程會遇到各類各樣的困境，致使流程很難推動下去。

每每不少時候你們對系統性能的認知還不夠深入。本應該作壓測的項目卻被項目組忽視性能測試，在系統上後引起性能問題；測試跟開發的關係一直很微妙，測試發現的問題多，開發就不happy了（又該挨批了）！測試發現的問題少，上面領導就不happy了（養測試時幹什麼吃的。。。。）！

開發人員心理叫苦，測試人員也是黯然神傷！今天就不過多展開聊，寶路後面計劃專門開一篇 「如何作好性能測試」的文章。

 

2.2 測試腳本管理

腳本在線編輯：支持測試人員調整腳本，如調整併發用戶、壓測環境、參數數據等。

腳本克隆：爲了測試人員在不改動父腳本的前提下，快速拷貝以達到測試人員快速編寫調整腳本。

腳本錄製：目前大概有四種腳本編寫方式：1.純手工編寫（相對比較慢）、2.JMeter代理錄製（感受很差用）3.Fiddler抓包工具插件轉jmx腳本（目前對腳本的兼容性有待考察）4.採用meterSphere的錄製插件（目前開源，很是推薦使用）。

腳本一鍵上傳：兩種方式：1.傳統的文件上傳（平臺頁面點擊上傳>選擇腳本文件進行上傳）、2.插件方式（單獨開發JMeter插件，GUI模式下編寫完腳本後點擊上按鈕默認直接上傳當前腳本及參數化文件，很是的方便，你們可參考bzm開源的插件自行開發）。

腳本標籤：這個功能是爲了更好的對測試腳本進行快速查找區分，測試人員可根據自定義的標籤來實現快速查找腳本。

  

2.3 庫文件、插件管理

在使用JMeter測試工具測試，你們確定常常會遇到一個問題那就是常常要上傳一些插件（需放lib/ext目錄下）和依賴的庫文件（需放lib目錄下）。若是不作統一管理，很容易出現jar包衝突、覆蓋其餘人上傳的包等現象，進而形成測試失敗。

那麼怎麼規避呢？我們其實能夠從用戶角度分析，好比：測試用戶A在作某個項目時須要上傳一個A1插件或A1庫文件，可是這個插件或文件對測試用戶B根本就用不到。

那就各子維護本身的插件就完事了唄，普通用戶本身上傳的插件只對本身生效或者可見，那些通用的插件，好比特殊Thread Group、TPS、Shaping Timer等插件則可由組長或者管理員帳戶統一來維護。這些插件對特定組員或者普通測試用戶可見，且不可編輯（防止亂刪）。

場景執行前先對salve機器進行數據同步，好比參數文件、插件和庫文件、服務器時間等。

2.4 數據、環境管理

修改數據文件：壓測的時候常常會遇到腳本中包含了某些參數文件。特別是消耗性的數據，會讓人難受。。。。要反覆的搞不少個參數化文件，而後再對每一個slave機進行替換。既然有了性能平臺，那性能平臺就應該支持在線修改參數據、一鍵同步文件。記住這種消耗性的數據必定要進行數據分塊。否則在壓測過程數據庫會造成大量鎖等待，形成TPS較低。

環境管理：這個應該很好理解，測試人員可提早維護好各個環境。總之一句話說：「腳本不該依賴於環境」。腳本在運行的時候是能夠選擇環境的，而不是在腳本中固定請求地址。

2.5 壓力機管理

智能調度：根據測試腳本中總併發用戶，智能分配壓力機，進而達到slave機資源利用率最大化。

監控狀態：測試人員可查看壓測過程當中，所用到slave機的資源消耗狀況。若是發現cpu資源消耗較高，可從新配置slave機的併發分配佔比，進而達到最優測試結果的目的。

手動啓停：在測試過程當中，如遇slave狀態異常，測試人員可在平臺上對slave機進行人爲的啓停。

自動熔斷：在測試過程當中，若是在某一段連續時間內，出現大量失敗請求，此時salve自動觸發中止測試場景，以此來保護被測系統。經常使用的開源插件有 AutoStop Listener。這個是一個值得探討的問題，究竟是應該中止壓測場景，仍是中止某些slave機？是maser發起中止所有 仍是salve之間互相通知？關於這塊，寶路這邊也計劃深刻研究一下，畢竟總有更好的辦法！

2.6 配置管理

容器配置：爲每臺容器salve機器配置併發用戶上限、cpu數等。

定時任務：測試人員能夠配置計劃任務，來達到定製執行壓測計劃的目的。

擋板配置：支持部署單獨的擋板模塊。配置管理請求地址、接口報文、交易延遲等。

2.7 實時監控

性能數據結果實時展現：常見的方案有兩種：一是採用InfluxDB+ Grafana的解決方案（這裏也有「坑」，之後寶路會寫文章來分析）；二是採用MySQL+Echars +Kafka的解決方案。

被測系統資源監控：解決方案：Collectd+InfluxDB+ Grafana

以上所述的方案，寶路更傾向與採用InfluxDB+ Grafana的解決方案。至於緣由嘛，暫且不談。固然了想作好這些確定不容易，每一個都須要你去了解，不能光看看網上的帖子就覺得本身會了。。。有好多東西都是值得深挖的。

 2.8 測試報告

郵件發送：這個功能確定是經常使用功能，值得討論的就是制定一個能知足本身的報告模板。其核心主題就是怎麼展現才能讓不懂性能的人看明白，也就是所謂的通俗易懂。。。不能總站在本身的角度考慮問題，對吧！

報告共享：郵件的方式算其中一種，測試人員也能夠採用共享的方式，給制定人員共享測試報告。該用戶經過登陸平臺或者制定鏈接都可查看。

系統測評：當測試人員完成壓測需求後，會根據測試結果再結合約定的規則對系統進行評分，再由測試組長複評。這個規則是值得商榷的。。。好比能夠根據不一樣併發用戶下的接口響應時間、系統資源消耗等方面進行規則制定。經過不斷的完善，以達成你們均承認的一個評分規則。

2.9 系統管理

  這個就簡要說了，經常使用的數據清理功能，能夠按時間段清理測試結果，來確保磁盤預留足夠的空間，其包含了一些經常使用的用戶權限管理、用戶的增刪改等。

2.10 REST API

做爲一個測試平臺，不管功能仍是性能，其實都繞不開CI/CD、DevOps。關於這個趨勢想必也不須要寶路來過多敘述了。

這就意味着，平臺必需要具有這個能力！外部系統能夠經過平臺API方便的調用平臺的服務。圖中也僅是舉個幾個API的例子，爲更好的適配，更多的API服務是很是值得開發和研究的。