MeterSphere 案例分享丨恆大智慧科技基於 JMeter 的效能測試方案演進之路

恆大智慧科技有限公司（以下簡稱為恆大智慧科技）是恆大高科技集團的全資子公司，定位於網際網路智慧城市生態運營商。

目前，我在恆大智慧科技的測試團隊中擔任Leader，團隊成員11人，以外包居多。外包同事在工作中遇到最多的問題是許可權受限的問題。我們每次在完成SIT（System Integration Testing，系統整合測試）後，都需要按照集團要求對所測系統的一些介面進行效能測試，並且將報告給到集團驗收。

我們使用的效能測試工具是JMeter。“Best practices state that you shouldn’t run a load test from the GUI mode at all.”——按照JMeter的最佳實踐，我們準備了不少壓力機供測試人員到上面執行命令（-n -t -l），下載JTL檔案生成報告。

但是我們的外包同事居然沒有壓力機登入許可權，這樣我們只能一遍遍地上去幫助他們進行上傳、執行和下載操作，並且發給他們結果。我們還需要負責調整指令碼的專案結構，操心執行完後去取檔案的時機。這樣就導致我們的工作時間被嚴重碎片化，工作效率也被降低了。

如果我們向外包人員開放賬號，也面臨著新問題。操作的人太多，壓力機裡目錄變得一片狼藉。簡單來說就是一切有許可權的目錄，都會有各式的檔案和資料夾，慢慢壓力機磁碟也爆了，無人清理。

MeterSphere能夠幫助我們做什麼？

面對這樣一個簡單的問題，業界有很多的解決方案，我們也有自己的辦法。

圖1 內部實現的壓測平臺

我們做了一個簡單的Web程式，把一個個小專案的效能測試指令碼資料夾打包上傳，拷貝到做了分散式配置的壓力機上。外包同事在Web頁面點選便可執行，這時配置好的控制機就會執行一個事先準備好的Shell指令碼去跑這些傳上去的JMX，每一條上傳記錄執行後都會有JTL的ZIP包下載連結。這樣一來，上述的基礎問題便解決了。磁碟的清理加個定時任務應該也不是難事，但我們還是遇到了新問題。

每更換一次虛擬使用者數，就需要將指令碼下載下來修改一次。除錯時我們習慣將虛擬使用者數和迴圈次數都設定成1，這樣操作很容易帶入壓測環境。這也帶來了很多“下載-修改-打包-上傳”的反覆操作，真的令人抓狂的！我們需要讓Web程式能夠線上修改上傳的JMeter指令碼。

但是一波未平，一波又起。我們的效能測試除了出報告，也是需要配合開發調優，我們需要讓開發看到實時變動。既然我們一直都在用Non GUI執行，就不必再使用JMeter的GUI去實時呈現了，這樣不僅有效能損耗，也不太好和現有的Web程式相整合。

“Backend Listener+Grafana+InfluxDB”很香嗎？實踐下來也不盡然。為每一次壓測生成對應的Grafana展示模板並作為URL分享並不是一件容易的事。再看我們這個簡單的效能指令碼分發器，還缺乏專案組織、定時設定、日誌檢視等功能。如果持續投入時間去完善它，哪還有時間寫程式碼呢？是時候找一個開源產品了。

選擇開源產品的套路很多人都懂，比如開源許可協議、活躍度、開發語言等等。常年混跡於GitHub，我們發現，GitHub裡開發框架和業務專案居多，優秀的國內開源測試平臺卻鳳毛菱角。

2020年5月之前，Java系的看的下去的貌似只有“LF”，阿里也有一款基於AI的用例膨脹的工具。國外的Taurus專案解決了我們根據場景修改JMeter指令碼的痛點，但如何讓它自身圖形化、且變得易用又成為了一個新的課題。BlazeMeter似乎是集大成者，但是我司網路訪問真的好卡，而且開源版不直接在企業環境內部署。

我們希望能找到一款目前能解決我們大部分痛點，遇到新的痛點我們能在此基礎上自行解決，發生問題我們能自行定位處理的開源測試平臺。MeterSphere開源持續測試平臺正是我們所需要的。

從2020年6月MeterSphere釋出的第一個版本，我們就開始試用，並閱讀了其程式碼。MeterSphere使用的是當下主流的開發框架（Vue.js+Spring Boot+Docker），建立在著名開源介面、效能測試工具JMeter之上，沒有絲毫地“藏私”，系統裡的每一個元件都能找到原始碼，包括它們使用到的Dockerfile。

MeterSphere的使用感受

MeterSphere專案的第一個版本釋出後，我們完成了對它調研。GPL v2.0開源許可協議賦予了這個開源專案充分的使用和修改自由，短時間內，這個專案在Github上的Star數量已經突破了2500個，專案團隊也在持續展開規律性的迭代，每個月你都能收穫一系列想要的功能。如果你是Java系，MeterSphere專案採用的技術非常主流，程式碼也比較工整，你可以上手修改。

第一次搭建部署我們就遇到了問題，主要的原因是我們沒有太多使用Docker Compose的經驗。我們的風格是要完全掌控我們所使用工具的每一個細節，為此我們放棄了MeterSphere一鍵安裝的部署方式，單獨編譯每個元件，並使用公司已有的中介軟體（Nginx、ZooKeeper、Kafka、MySQL）來部署MeterSphere，並且把我們一直使用的JMeter做成Docker映象供MeterSphere進行排程。

這樣每個元件的日誌，以及執行方式我們都能瞭如指掌，出現問題也能快速定位，以確保平臺一直可用。遇到搞不定的問題，也能在微信交流群中提供更精準的資訊請MeterSphere研發團隊的同學幫忙解決。

圖2 MeterSphere平臺架構

在我們使用第一版MeterSphere之前，我們做了簡單的改造，遮蔽了用例管理和Bug跟蹤功能。這樣做是考慮到上線了就會有人使用，遮蔽暫不使用功能是為了降低運維成本和解釋成本。我們將執行時間從分鐘改為了秒，也修改了一些Bug（這些Bug在MeterSphere後續的版本中已經修復）。我們就這樣愉快地開啟了開源持續效能測試之旅，它完美解決了我之前所提到的種種問題。

伴隨著MeterSphere專案的持續演進，我們基本上是MeterSphere每釋出一個新版本都會進行升級。因為MeterSphere的介面測試功能幾乎每個版本都在完善（從Dubbo到TCP，再到SQL），這對我們很有意義。我們的介面自動化測試用例都是以JMeter指令碼的形式維護在SVN中，每次需要再次執行時都需要花費時間去除錯。很多指令碼都不知道是從何時開始就已經不可用，用這種維護方式做持續整合測試並不如人意，報告也需要額外處理。

MeterSphere集中化、介面化、場景化介面測試用例的方式其實更為主流。而且MeterSphere一系列介面配置操作後內部其實還是一個個JMeter檔案去跑介面測試（使用JS生成的JMX），你從JMeter介面測試到MeterSphere介面測試的過渡從原理與機制上是順滑的。而且在後面的版本，MeterSphere還計劃推出JMeter直接上傳為MeterSphere介面測試用例的新功能。目前，MeterSphere已經支援了Postman的遷移功能。總的來說，持續發展的專案更值得我們花時間去適應，也會引導我們走更為主流的技術道路。

期待與建議

MeterSphere的每個版本都有驚喜，易用性也在不斷加強。我總在期待卻不知道如何建議，如果非要說點什麼，那麼我簡單想到了以下兩點：

• 報告與圖表不如BlazeMeter精細、豐富；
• 日誌類的檔案存到了MySQL中，不適合查詢。下載是需要先讀mysql，檔案大時非常卡，感覺Elastic Search和InfluxDB更合適一些。

我們還需要與MeterSphere開源持續測試平臺不斷磨合並深入使用。MeterSphere專案成長得很快，我們還有很多東西沒有來得及使用和學習，我們要加快腳步！

注：本文作者為恆大智慧科技高階測試工程師李生。