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