前面兩篇筆記介紹瞭如何快速上手壓測項目以及壓測前準備測試環境和測試數據的一些方法。
這篇文章，我想分享下關於壓測平臺功能設計和技術實現方案的一些技術筆記內容，內容主要來源於兩方面：
- 18年我所在性能團隊使用的壓測平臺技術實現細節；
- 20年後我帶穩定性團隊時我們開發的全鏈路壓測平臺的功能設計和技術方案；
爲什麼需要壓測平臺？
從實際工作場景出發，如果只有一兩個人做性能測試工作，那其實沒必要開發專門的壓測平臺，原因如下：
- 成本問題：開發壓測平臺，前期需要投入至少1-2個專門的人力，且需要長期維護；
- 效率問題：人數少，基本相當於壓測任務並不太多，腳本管理數據管理這些可以通過本地上傳到服務器，服務器只需要按照業務域和壓測節點，建立對應的文件目錄，然後有個crontab的定時任務來清理即可；
- 協作問題：人數少其實不太需要平臺來解決規範和流程問題，協作的事情幾句話口頭就可以溝通解決；
對於壓測平臺，或者說各種測試平臺，其實很多同學有個誤區就是：平臺各種高大上牛逼，但往往忽略了開發和維護以及學習使用平臺本身的成本。
測試平臺的目的是：通過平臺提供標準化操作，將不同個體差異通過流程化的方式約束起來，減少重複造輪子和輪子之間差異導致的排查和解決問題的成本，進一步提高人效。
畢竟工作最終是結果導向的，如果沒有更高效的解決問題，那平臺最終會成爲沉沒成本。
假設現在你想擁有一個壓測平臺，那我個人覺得最起碼需要滿足如下幾個條件：
- 業務線多，版本迭代快（需求驅動）；
- 測試團隊個體間的技術差異比較大（技術驅動）；
- 性能需求較多，線上穩定性問題頻發（問題驅動）；
- 技術團隊達到一定規模，做壓測的人比較多（效率驅動）；
壓測平臺功能設計思路
聊完了關於壓測平臺是否必須以及要解決的問題，這部分聊聊一個可用的壓測平臺要滿足哪些條件。
- 簡單易用：平臺學習和使用成本低，操作簡單快捷；
- 數據持久化：測試腳本&測試數據&測試結果持久化，便於追溯歷史記錄；
- 維護成本低：滿足開箱即用，和外部系統可以交互，出問題也有高效的技術支持；
- 支持多人協同：可以滿足不同團隊的人使用，快速開展壓測工作且不會交叉影響；
- 便於配置管理：對壓測集羣、壓測組件和一些配置項的管理便捷高效，不用手敲太多命令；
- 完善的施壓支持：支持一定的高併發能力，壓測集羣可擴展，支持多協議和基本的自定義擴展能力；
看完上述條件，我們對壓測平臺的功能模塊，就有了比較明確的要求。
- 用例管理：一個壓測項目可以創建多個壓測任務，任務=用例，用例包含壓測腳本、壓測數據和插件；
- 壓測執行：支持手動和定時執行壓測，可以配置運行參數、可以選擇多個壓測節點、支持同時運行多個壓測任務；
- 實時監控：壓測過程中實時展示TPS、RT、請求數、錯誤率等核心指標，並支持按時間段選擇和計算；
- 壓測結果：壓測結束後整個任務的壓測結果可以進行詳細的展示，比如TPS、ART、90/95/99RT、成功/失敗請求數、錯誤日誌等；
- 配置管理：比如壓測節點參數變更、綁定host、插件上傳更新等；
- 擴展功能：比如支持mock、openAPI、造數工具、三方庫兼容等；
看完了上面的條件和功能模塊要求，那麼一個基本的壓測平臺，要具備哪些具體的功能呢？請看下圖：
PS：此圖僅供參考，並不代表要完全有這些功能，根據自己的具體情況設定。
壓測平臺技術實現方案
接下來聊聊壓測平臺部分功能的技術實現方案。
壓測平臺的技術架構其實關鍵字搜索已經很多了，這裏我也不想多費筆墨，在其他人的基礎上微創新。
我想分享一些具體功能模塊的技術實現方案，供大家參考。
mock功能
日誌採樣功能
PS：該功能是基於jmeter爲壓測工具實現的，僅供參考。
如上就是我關於壓測平臺的一些工作實踐筆記和個人思考。
下篇文章，我會聊聊關於質量度量的新看法，敬請期待。