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服務是非常值得開發和研究的。