MeterSphere案例分享丨基于JMeter的性能測試方案演進之路

812次閱讀

目前，我在公司的測試團隊中擔任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的遷移功能。總的來說，持續發展的項目更值得我們花時間去適應，也會引導我們走更為主流的技術道路。