編者注：以下內容根據MeterSphere研發經理王振在6月17日“FIT2CLOUD飛致雲在線講堂”的直播內容整理而成，其中演講內容進行了部分節選，並對在線問答環節進行了整理。
本次直播我會和大家分享一下FIT2CLOUD飛致雲最新開發的一站式開源持續測試平臺——MeterSphere。
說到FIT2CLOUD，可能有朋友瞭解過我們的公司和之前的產品，包括多雲管理平臺、JumpServer開源堡壘機和KubeOperator開源容器平臺。那麼，我們爲什麼會在測試領域做MeterSphere這樣一款產品呢？以及MeterSphere會有哪些具體功能？能解決什麼的問題？今天來跟大家分享一下。
一、MeterSphere爲何而來？
FIT2CLOUD飛致雲的產品定位是“爲企業提供多雲時代更好地構建、運行、管理、保護其IT基礎設施和應用的關鍵工具”。在“運行”、“管理”和“保護”這三方面，我們已經有了對應的產品，也給我們的用戶帶來了比較好的價值，但是在“構建”領域，也就是面向研發、測試的環節，我們還缺少一款產品提供支持。
同時我們也發現，測試人員的需求其實是沒有很好被滿足的。現在市面上，尤其是在國內，也缺少一款相對成熟、受衆廣泛的開源測試平臺。爲什麼會出現這樣的情況呢？借用同行的一句話，可能是“因爲測試不夠性感吧”！
最後也出於我們自身的需求，我們需要有這樣的一個平臺給公司其他產品的測試任務提供支持。
基於以上幾方面的原因，MeterSphere應運而生。
我們對MeterSphere的產品定位是一個“一站式的開源持續測試平臺”。它主要涵蓋測試跟蹤、接口測試、性能測試、團隊協作等功能，同時兼容JMeter等主流的開源標準，可以有效地助力開發和測試團隊充分利用雲的彈性，進行高度可擴展的自動化測試。
在剛纔的這段介紹裏面，其實有三個關鍵詞：一站式、開源、持續測試。下面我們一個個來解讀一下。
首先是“一站式”。我們和很多測試人員聊的時候發現，其實在測試領域的每個環節、每一部分，很多公司、團隊都有對應的工具、方法提供支持，但是一個很普遍的現象是——各個環節之間都是互相割裂、互相獨立的。我的測試用例管理工具裏面的某個用例和某個測試人員寫的測試腳本之間沒有什麼聯繫，測試腳本跑完之後需要手動把測試結果更新到用例管理工具上去。
另一種情況是，我寫好接口測試的腳本不能直接拿來用作性能測試，還需要換一個工具重新來一次。
面對這樣現象，我們希望MeterSphere能夠涵蓋到軟件測試工作中，從測試用例管理、測試任務跟蹤到測試執行、測試報告分析的不同階段，同時可以幫助測試人員完成從手工的功能測試到自動化接口測試、從接口測試到性能測試的無縫過渡銜接。
雖然我們目前發佈的MeterSphere v1.0版本離真正的“一站式”還有一些距離，像材料裏灰色部分的移動端測試、UI測試、安全測試等功能都還沒有包含，但是我們會在後面的迭代中不斷朝着“一站式”的目標持續前進。
再來看看“開源”。開源就是開放源代碼，相信大家有着切身的體會，開源應用、開源軟件正在切切實實地改變着我們的這個世界。
我簡單列了一下我們的團隊和我個人平常會用到的開源項目，從底層的操作系統到最上層的具體應用和工具一應俱全，這裏列出來僅僅是整個開源世界的冰山一角，大家也可以去整理一下經常用到的軟件和工具裏有多少是開源的。
像我們的JumpServer開源堡壘機和KubeOperator開源容器平臺一樣，MeterSphere這款產品也會以開源項目的形式運作，大家可以從官網或者直接在GitHub上搜索，就可以找到MeterSphere的代碼倉庫。
另外，我們目前在接口測試、性能測試這一塊完全兼容JMeter格式，後續的話也會和其他優秀的開源測試工具、測試引擎，比如Selenium、Robot Framework等來進行對接，不斷完善我們自身的功能。
最後是“持續測試”。持續測試不是孤立的事情，需要融入到我們整個DevOps體系。DevOps也是這幾年很火的概念，很多公司都在積極探索，進行DevOps轉型，不同的人可能會對DevOps有不同的概念和認識。
在我看來，DevOps最核心的特點就像經典的八字圖一樣，就是不斷地重複、循環，也就是持續化。它包含了各個環節的持續化，從最開始的持續計劃、持續開發到持續集成、持續測試，然後再到上線之後持續部署、持續監控等。
從快速交互應用的角度來看，可能持續集成是整個DevOps流水線的核心。但是從DevOps的核心目的——又快又好地交付應用的角度來看，“持續集成+持續測試”才應該是整個DevOps的核心所在。
Gartner的一份報告也印證了這樣的觀點。Gartner預測，到2020年50%的企業會通過採納開源框架和開源工具來落地持續測試。
提到持續測試，可能有人會問，持續測試和自動化測試有什麼區別？自動化測試我們可能聽到的更多一些，持續測試是在自動化測試的基礎上進行一些擴展和延伸，不僅包括自動化測試的過程，更包括從測試左移到測試右移所覆蓋的全部環節。
測試左移的話，就像我們做一些單元測試、組件測試、代碼覆蓋率測試一樣；測試右移就是我們需要在應用上線之後，不斷地對它進行生產環境的監控，在生產環境上做一些簡單而不影響業務的測試等。
具體到MeterSphere，我們會提供完善的Jenkins插件，幫助用戶實現持續測試的目標，把測試環節納入到整個DevOps流水線當中。目前MeterSphere主要還是在測試左移這個方向的功能，後續我們會推出實現測試右移的相關功能，來達到整體持續測試的效果。
“一站式”、“開源”、“持續測試”這三個關鍵詞基本概括了我們對MeterSphere這個產品的整體定位，接下來看一下爲了實現這樣的定位，MeterSphere相比於傳統的測試工具或者測試平臺所具有的優勢和特色。
二、MeterSphere的優勢與架構
MeterSphere的優勢體現在以下四個方面：
第一，全生命週期的支持。這部分就是剛纔針對“一站式”的解讀，MeterSphere所提供的功能能夠覆蓋測試計劃、測試執行、測試分析的不同階段；
第二，自動化和擴展性。現在是雲和容器的時代，如果在之前我們要做一個大規模的性能測試，去部署和維護大量的測試執行節點，可能需要我們投入很大的精力來做。基於MeterSphere，可以通過和雲平臺、容器平臺的接口進行對接，自動管理測試資源池，可以充分利用雲的彈性實現超大規模的性能測試；
第三，持續測試。MeterSphere能夠與持續集成工具無縫集成，支撐企業實現測試左移；
第四，團隊協作。MeterSphere提供了一個比較靈活的多租戶管理模型，基於這樣的多租戶體系，MeterSphere既可以支持小到幾人的測試團隊，也可以支持大到數百人的測試中心。
接下來我們來看一下MeterSphere的整體架構。MeterSphere主要由紫色的四個部分組成，灰色的部分是一些通用的開源中間件。紫色的部分中的Frontend 和Backend 構成來我們應用的一個主體，在應用主體中我們採用了前後端分離的架構，分爲前端和後端。
前端主要是基於VueJS和ElementUI來做的，後端是基於Java SpringBoot這個框架來做的。應用主體裏包含應用的大部分功能，比如剛纔提到大部分功能都是在這部分裏提供的。
DataStreaming組件和NodeController組件主要是支撐我們完成大規模分佈式的性能測試。
首先看一下NodeController組件，這個組件我們可以裝在一臺安裝了Docker的Linux機器上，主體應用會在做性能測試的時候，把這個性能測試任務下發到NodeController，可以把它理解爲壓測的執行節點。NodeController收到這個性能測試任務之後，會通過控制Linux機器上容器引擎的方式來啓動一個JMeter的容器運行性能測試腳本，從而完成性能測試。
同時在這個JMeter腳本里，我們增加了一些配置，在測試執行時會實時地把性能測試壓測結果傳輸到Kafka隊列中。這個結果到了Kafka隊列之後，後邊就是DataStreaming組件的工作。這個組件會不斷從Kafka隊列中收集性能測試結果和測試產生的日誌，進行一些相關處理之後，會再把它持久化存儲到數據庫裏。存儲到數據庫之後，在前端頁面上就可以看到整個性能測試壓測的報告了。
三、MeterSphere的管理模型和四大功能
接下來看看MeterSphere的管理模型。剛纔提到MeterSphere的一大優勢就是團隊協作能力，我們整個背後管理模型是一個兩級租戶體系。這個租戶體系在FIT2CLOUD的其他產品裏得到了比較好的驗證，有了很豐富的落地實踐經驗。
在這裏，我們劃分了組織和工作空間兩級租戶。在工作空間租戶中，不同的團隊還可以創建維護自己的項目，所有的測試跟蹤、接口測試等都在項目的範圍內提供。
測試跟蹤中首先是測試用例的管理。基於你的用例可以針對不同版本、不同迭代發起測試計劃。還有一個比較好的特點，就是我們這裏的測試用例可以和接口測試、性能測試、UI功能測試等進行關聯，這也就是剛纔說的“一站式”的體現。
現在，大家一定迫不及待地想要了解MeterSphere究竟提供了哪些具體的功能，以及可以用它做什麼？在MeterSphere v1.0版本中，我們提供了四大功能：即測試跟蹤、接口測試、性能測試、團隊協作。
首先是測試跟蹤。MeterSphere提供了遠超TestLink的使用體驗。TestLink大家可能都有了解，它的整個技術棧、UI等都是比較老舊的，用起來體驗並不是特別好。在MeterSphere的測試跟蹤功能模塊裏，用戶可以針對每個獨立項目，以樹狀的形式管理所有的用例。用例的管理方式既可以通過瀏覽器在線編輯的方式來維護，也可以通過Excel導入的方式，快速導入已有的用例。
同時用例都維護好之後，可以針對這個項目的不同迭代、不同版本來發起若干個測試計劃。發起測試計劃的時候，可以從項目裏的所有用例中選擇若干的用例分配給不同的執行人進行測試。
執行人被分配測試之後，通過MeterSphere可以在線記錄整個測試的過程和結果。整個測試用例、計劃都執行完之後，系統會給出一個完整的測試報告，這就是測試跟蹤模塊的主要功能。
第二是接口測試。在接口測試功能模塊中，MeterSphere提供了類似主流Postman工具的使用體驗。大家應該都用過Postman這個工具，整體上它的功能還是比較完善和好用的。但是對於一個團隊使用來說，一個很大的問題是它的免費版本不支持團隊協作，如果要支持團隊協作，需要用到企業版。
MeterSphere具備天然的團隊協作能力，在MeterSphere的接口測試功能模塊裏，大家也可以像使用Postman那樣，在瀏覽器裏在線編輯接口測試的請求詳情。除了基本的請求詳情之外，我們也提供了很常用的參數化測試、變量提取等較爲高級的功能。
同樣，用戶在MeterSphere平臺上執行測試後，可以馬上查看到一個完整的測試報告。這個測試報告裏包含了測試概覽情況，同時也包含了每個測試具體的請求和相應的內容，方便大家去做一些異常的判斷和問題的定位。
第三是性能測試。MeterSphere的性能測試和接口測試都是完全兼容JMeter的。如果你之前使用JMeter，可以把已有的JMeter腳本直接上傳到MeterSphere的平臺上，非常方便地發起性能測試。同時，在接口測試功能調測好之後，還可以基於MeterSphere把接口測試一鍵轉化成性能測試，然後再加上一些壓力配置相關的參數，就可以發起性能測試了。
MeterSphere也提供了瀏覽器插件，這個瀏覽器插件開啓錄製之後，會把你在瀏覽器頁面中所有的網絡請求都記錄下來，當然會篩選掉一些靜態文件的請求。記錄下來之後，你可以把它保存爲一個JMeter腳本。有了這個腳本之後，你就可以把它扔到MeterSphere平臺上做接口測試、性能測試，整個插件用起來還是很方便的。
和接口測試一樣，整個性能測試跑完之後，可以在線看到整個測試執行的報告情況。報告呈現的內容也是很完整的，既有概覽的信息，也可以看到請求的統計，還有出現錯誤異常的情況，以及背後JMeter完整的日誌，都可以在報告中進行查看。
第四是團隊協作。這部分前面基本上介紹了，主要包含多租戶的支持和測試資源管理。
很多管理員可能對多租戶的支持感興趣。它可以很好地組織租戶，既可以做到不同租戶之間很好的隔離，包括資源的隔離、權限的隔離，又可以做到同一個租戶中的成員比較方便的協作。
測試資源管理，包括我們做性能測試時對整個測試資源池的管理。MeterSphere還提供了默認的測試報告模板，你也可以基於這個模板創建自己的測試報告模板，同時可以做一些和第三方系統對接的工作，以及比較常見的系統配置任務。
四、MeterSphere的研發計劃
MeterSphere會保持每個月一個功能版本的節奏來持續迭代。除了在完善改進已有功能的同時，我們也會不斷的增加新功能，不斷探索在測試領域中技術創新的更多可能性。
MeterSphere v1.1的版本預計將在2020年7月底發佈。這一版本的功能規劃大概包含以下幾方面：
第一，瀏覽器插件功能的改進和增強，主要包括瀏覽器插件錄製後腳本的在線編輯能力。現在插件功能比較簡單，只能保存下來，保存成JMX文件之後再去編輯，後面我們會增加在插件界面上的直接編輯能力；
第二，插件錄製的腳本可以直接扔到MeterSphere平臺上做接口測試；
第三，針對性能測試報告的優化。有使用過MeterSphere的用戶可能發現，現在的報告功能只能在測試執行完成後才能看到報告內容。在下一個版本中，我們會增加報告動態展示的能力，在測試執行過程中可以實時查看到整個被測系統響應的情況；
第四，我們會在v1.1的版本中提供達到持續測定目的的Jenkins插件，通過這個插件可以在Jenkins上觸發MeterSphere的測試任務；
第五，v1.1版本會推出在線體驗環境，便於大家更快速、更便捷地體驗到MeterSphere平臺最新版本的功能。
預計在2020年8月發佈的v1.2版本中，MeterSphere將主要對接口測試做一些功能上的增強和優化。在接口測試中，會支持前後置的腳本，同時可以支持等待時間的設置，可以加一些CSV類型的參數。插件方面我們也會做功能的增強，現在導出的是JMX JMeter腳本的格式，後面我們可以導出成更爲通用的HAR格式。
另外，在v1.2版本中，MeterSphere還計劃增加和前後置系統的對接集成能力，包括對比較主流的需求管理系統的集成，以及缺陷管理系統的集成對接。
剛纔提到了對接雲平臺，從而動態地來管理測試資源池，MeterSphere計劃在v1.3版本時推出相關的功能。而在更長遠的版本規劃中，比如之前提到其他形式的測試，包括UI功能測試、移動端測試、Mock服務等，我們也會在後續的版本中不斷地增加相關的功能。
五、在線互動問答
問題1：MeterSphere和JMeter有什麼區別？
回答：這個問題很好，後面我們會專門寫一些相關的文章來說明這個事情。這裏先簡單說一下：
第一，和Postman類似，JMeter這樣的客戶端工具更多的是面向個人的，團隊協作能力相對欠缺。比如我使用JMeter，寫好一個JMeter腳本之後，可能需要把這個腳本存起來，再發給其他同事。MeterSphere因爲有天然的團隊協作能力，大家都可以在同樣的平臺和界面管理維護你的腳本；
第二，JMeter去做分佈式、多節點的性能測試時，會有自己的一些問題和侷限。比如說它所有的節點都要求在同一個子網內，當然你也可以有其他規避這個問題的方式，但是相應地你也需要額外地投入和精力做這個事情；
第三，JMeter整個分佈式的機制也有比較大的侷限。MeterSphere可以比較好、比較方便地進行分佈式的性能測試，可以很方便地把你的壓測執行節點以一個資源池的形式統一地管理起來。
問題2：MeterSphere手工測試用例是如何轉爲自動化測試關聯的？測試用例是如何與需求、版本關聯的？是否支持用例在不同計劃輪次的隨意編排、評審和指定執行人？
回答：剛纔提到MeterSphere有一個瀏覽器插件，可以通過瀏覽器插件讓我們在做手工的功能測試時把瀏覽器插件的錄製功能打開，然後在做功能測試的同時，這個插件會把我們在測試過程中發送的網絡請求錄製下來。
測試完成後，我們就可以把錄製的腳本保存下來，再進行一些參數化、斷言等相關的修改，可以得到一個接口自動化測試的腳本。你可以把它扔到MeterSphere平臺上來執行，因爲它是一個標準的JMeter格式。你如果比較喜歡用JMeter的話，也可以直接把它扔到JMeter上運行。
另外這個問題涉及研發規劃的v1.2版本，MeterSphere將會和前置的需求管理工具，比如說Jira，以及後置的缺陷管理工具，來進行集成和對接。
問題3：MeterSphere是否會劃分商業和開源版本，還是純開源？
回答：這個問題也是大家比較關心的問題，這裏統一回答一下。MeterSphere的開源策略將和FIT2CLOUD飛致雲其他產品的開源策略保持一致。它會在保持核心功能開源的基礎上，增加一些企業版的擴展功能，也就是說我們未來會推出MeterSphere企業版。
當然大家可以放心的使用MeterSphere的開源版本，我們會保證它的核心功能是開源的。你如果不用企業版只用開源版的話，也可以用得很爽。這方面大家可以和JumpServer開源堡壘機的用戶瞭解印證。
問題4：接口有規劃支持Dubbo嗎？
回答：目前還沒有這樣的規劃，但是我們會很歡迎大家在GitHub和MeterSphere項目交流羣裏給我們提出需求，如果大部分人都有這方面的需求，我們會考慮把它加到後面版本的規劃當中。
問題5：介紹中提到能夠與持續集成工具無縫集成，具體是如何與企業現有的CI/CD系統集成的？
回答：在MeterSphere v1.1版本規劃裏提到的，我們會提供一個Jenkins插件。這個插件大概功能就是——首先會和MeterSphere平臺有一個認證，認證完成後可以在你所選的項目裏選擇一些測試用例、接口測試、性能測試腳本做一個觸發執行，執行完成後我們的插件會返回給Jenkins結果。
這個插件可能有幾種使用方式，你可以用Freestyle的方式，把它作爲一個單獨的任務，然後跟其他的任務關聯起來。我們也會支持Pipeline的方式，你可以直接把這一個環節加到你的整個Pipeline裏面。
問題6：是否支持與gitlab-ci集成呢？
回答：目前我們考慮的更多是和Jenkins集成。和剛纔那個問題一樣，如果您這邊有比較強的需求，我們會看這個需求是不是比較普遍，也會考慮把它加入到我們後續的版本規劃當中。
問題7：遇到高併發場景的話，有分佈式嗎？
回答：在MeterSphere的產品架構包含了NodeController的組件，這個組件可以脫離主體應用獨立安裝。我們會有一個測試資源池的概念，在這個測試資源池裏面，你可以添加很多個這樣的NodeController，或者叫壓測執行節點。當你去做性能測試、壓測的時候，你選擇了對應的資源池，我們會把整個併發數按照一定的規則拆分到每個壓測執行節點上進行執行，最後再把結果進行統一彙總。
問題8：性能測試除了支持上傳JMeter腳本外，是否支持在線編寫和修改腳本？
回答：目前MeterSphere提供的測試針對Web應用更多一點，在線的編輯和修改腳本的形式雖然不能在性能測試中直接做這個事情，但是我們提供的對應功能可以把一個接口測試轉換成性能測試的腳本。也就是說，如果你有在線編輯修改的需求，你可以在接口測試那邊編輯修改你的接口測試，在沒有壓力的情況下，測試通過了之後，再把這個接口測試轉化成一個性能測試。
當然JMeter除了測Web應用、HTTP請求以外，它通過插件的形式還能做很多事情。MeterSphere目前的規劃還是會以Web形式爲主，因爲JMeter功能蠻強大的，我們如果把它的所有功能都挪到我們的Web頁面上也不是特別現實。
問題9：接口測試和性能測試的參數有可能不一樣，這種情況怎麼把接口測試直接生成性能測試腳本呢？
回答：這個問題可能一方面是MeterSphere平臺會提供相關的功能，另一方面可能也需要把這個腳本做一個比較好的參數化處理。相當於在做接口測試的時候，已經把可能會變的參數剝離出來，把它搞成一個外部的參數。當我把它轉換成性能測試的時候，其實可以重新給性能測試的參數賦值。
另一方面，未來我們也會去做一個類似環境管理的功能。在環境管理中，針對不同的環境，你可能會維護不同的變量，以及不同變量的不同值。可能用類似的功能，同時也會有全局或者局部的變量。基於這樣的形式，你在做接口測試、性能測試的時候，就可以給到某一個參數不同的值。
問題10：建議規劃中能考慮測試數據管理、生成、Mock的能力。
回答：這個我們其實也考慮過，測試數據管理、生成可能會麻煩一些，現在想的還不是特別清楚。如果大家有什麼好的解決思路、好的方法，十分歡迎和我們聯繫，大家一起交流一下，共同把MeterSphere做得更好用。
Mock的話，剛纔在規劃裏也提到了，目前在v1.x的版本中，更多的是把現有的能力不斷地完善優化。未來的v2.0版本會增加這樣的能力，比如Mock服務，以及UI功能測試等。
問題11：請問如何快速部署出測試集羣？
回答：不知道這裏的“測試集羣”指的是什麼？是不是我們做壓測的時候，分佈式的壓力執行節點。如果是的話，可能有幾種方式。目前來講，MeterSphere提供的安裝包中，通過安裝包可以不安裝其他的組件和應用，只安裝我們的壓測執行節點需要的組件。通過這樣的方式，你可以按需部署自己的壓測執行節點。
另外像v1.3版本中所規劃的，我們後續會考慮和雲平臺的接口做一個對接。這樣的話，你只要把雲平臺的認證信息、機器創建所需的相關配置參數填寫到MeterSphere平臺上，後續做性能測試的時候，MeterSphere平臺可以自動地把整個測試集羣、壓測執行節點創建出來。測試結束之後，也可以把它自動銷燬掉，你就不需要手動管理這樣的測試資源了。
問題12：可以上傳locust腳本壓測嗎？
回答：目前還不太可以。因爲目前MeterSphere的接口測試、性能測試背後都是通過JMeter來完成的。在後續的版本里面，我們也考慮把整個平臺做進一步的抽象。這樣的話，MeterSphere平臺既可以使用JMeter來作爲測試引擎，也可以使用其他的主流工具作爲測試引擎，同時也會提供一些比較好的擴展能力。用戶可以在MeterSphere擴展機制的基礎上，去擴展自己已有的引擎裏沒有的東西，這個可能是更長遠的規劃。
感謝大家的提問，非常感謝大家關注MeterSphere項目。如果大家還想要了解更多的信息或者跟我們保持溝通交流，大家可以訪問MeterSphere的官方網站或者加入MeterSphere的微信交流羣。
我們也提供了一個一鍵安裝腳本，大家如果有自己的機器，可以通過這個腳本快速部署一套自己的環境，親自體驗一下剛纔介紹到的所有功能。
再次感謝大家的關注，希望大家能夠和我們分享您的想法和建議，大家一起打造一款符合我們心中期望的開源持續測試平臺。謝謝大家！