MeterSphere 案例分享丨我們為什麼要從 HTTPRunner 轉向 MeterSphere

寧波蔚瀾環保科技有限公司（以下簡稱為蔚瀾環保）是一家致力於“碧海藍天”的環保科技公司，主要的產品包括智慧分類垃圾箱，以及小程式、安卓端主機、服務端等提供垃圾智慧分類功能的軟體產品。

圖1 蔚瀾環保的智慧回收機

圖2 蔚瀾環保的廚餘智慧分類機

蔚瀾環保目前的軟體團隊有19人，包括軟體總監1人，產品經理兼專案經理2人，UI設計1人，開發12人，測試3人。其中，測試經理兼任自動化測試，功能測試人員2人。

作為一家成立於2019年的公司，軟體團隊組建時間較短，但是產品已經更新了3代（包括硬體）。隨著產品功能的增多，新功能的加入難以有效評估影響範圍，直接導致迴歸測試的時間越來越長。如果仍然採取之前的功能測試模式，很難滿足公司業務發展的需要，引入自動化測試勢在必行。

為什麼採納 MeterSphere？

在引入自動化測試框架時，我們捨棄了UI自動化測試，直接選擇了介面測試。這主要考慮到我們的產品是嵌入式開發，UI層面的元素比較少，UI自動化測試無法滿足我們的需求。

在選擇介面自動化測試框架時，我們評估了市面上流行的幾款自動化測試框架，包括RobotFramework+HTTP介面自動化測試、Python+Request、JMeter、HttpRunner等。經過比較，我們最終選擇了HttpRunner。

相比其他的自動化測試框架，選擇HttpRunner的理由如下：

1. 小巧靈活
2. 開源
3. 學習成本相對較低

基於這些原因，我們在內部開始使用HttpRunner作為自動化測試平臺。經過一段時間的使用後，我們發現該開源框架存在諸多問題，例如指令碼維護成本較高、查詢和編輯不方便、對格式要求嚴格、視覺化程度低、無法使用註釋功能等。

團隊內部對這一款開源框架從喜歡到排斥，感覺“不好用”，使用者體驗非常差。正在我們為自動化框架苦惱時，一個測試朋友推薦了MeterSphere開源持續測試平臺。我自己下載安裝體驗一週後，向團隊內部安利，請他們到我的本機體驗MeterSphere的自動化指令碼編寫和執行。

圖3 MeterSphere自動化介面編寫介面

正所謂“吃一塹，長一智”，我們這次充分調研了自動化測試平臺的後續維護和使用者體驗。團隊內部經過一段時間的充分評估後，最終選擇了MeterSphere作為自動化測試平臺，選擇理由如下：

1. 學習成本低。團隊內部之前使用Postman進行介面測試，MeterSphere介面編寫方式基本與Postman介面測試無縫銜接，可以直接在MeterSphere上進行介面測試，並實現自動化。

2. 開源。對於小型公司而言，沒有預算去購買商業化的自動化測試工具，開源是必選。其次，MeterSphere還打通了TAPD和Jira直接的關聯。介面自動化測試發現的缺陷，可以直接同步到TAPD和Jira中，正好我司使用的是TAPD，這樣又省去了手動建立缺陷的過程。
   

   圖4 通過MeterSphere對接TAPD和Jira

3. 響應及時，更新迭代快。MeterSphere v1.0版本時，還不支援函式和單個指令碼除錯，導致測試資料要手動輸入。但其後續版本中，可以引用函式並除錯，極大地降低了維護成本，使用者體驗越來越好。
   

   圖5 MeterSphere的全域性變數配置

4. 易用。從圖3和圖5可以看出，MeterSphere對於指令碼和測試報告的匯入匯出、全域性變數配置、函式的呼叫、執行定時任務等需求都能夠滿足。這些功能點在其他自動化測試平臺上，要麼沒有，要麼有而不好用。對於一款經常使用的工具而言，易用性是非常重要的，否則在公司內部極難推廣使用。

MeterSphere的使用情況

前面把選擇MeterSphere開源持續測試平臺的理由說了一遍，實際的使用效果怎麼樣呢？

圖6 MeterSphere提供的自動化測試報告

我司現在使用在MeterSphere中編寫自動化指令碼330多條，覆蓋基本的核心業務場景，極大地減輕了我們在迴歸測試時的工作壓力和迴歸測試時長。

在實現核心業務場景覆蓋的基礎上，我們現在還藉助MeterSphere實現測試左移。開發人員完成介面開發後，即可轉交介面測試，將介面測試指令碼加入到自動化測試體系中。

我們現在自動化的執行還是以定時執行任務為主，還沒有實現MeterSphere和Jenkins的銜接。未來，我們希望將MeterSphere部署到Jenkins流水線中，開發人員提交構建後，即可實現自動化測試。

MeterSphere帶來的收益

雖然我們只是採用了MeterSphere介面測試部分的功能，但是該平臺給蔚瀾環保帶來的收益已經初步展現出來了。

• 最明顯和最直接的收益是——我們通過MeterSphere發現了5個嚴重bug，使其成為我們捉蟲子的好幫手；
• 其次，我們兩週一個迭代，測試部門之前功能迴歸測試需要3人天，現在可以縮短到1人天，極大地降低了迴歸測試的成本，測試部門有更多的時間進行探索性的測試；
• 最後，降低了風險，增強了信心。之前的迴歸測試由於時間不足，總是承擔很大的風險。使用自動化測試之後，有了資料支撐，懸著的心可以緩一緩了。

感受與評價

現在來談談對MeterSphere開源專案的整體感覺吧。個人感覺MeterSphere開源持續測試平臺是個好產品，不僅滿足我司現階段對自動化測試平臺的所有要求，而且很好用。總結起來優點主要包含以下幾方面：

• 安裝簡單方便。在Linux系統上幾乎是一鍵安裝，升級也是如此。這裡要點個贊，好多產品都需要自己配置一大堆問題，產生很多配置問題。
• 指令碼易於維護和推廣，學習成本低。MeterSphere支援在Web頁面直接編輯除錯指令碼，這樣很容易在團隊內部共享自動化測試的成果。
• 社群互動氛圍良好。在這裡要表揚一下MeterSphere專案的開發團隊，使用中有問題在微信交流群裡提問，MeterSphere團隊小夥伴能夠及時地回覆，並且有效地解決問題，希望MeterSphere的開發團隊能夠保持初心不改，產品越做越好。

期待與建議

最後，作為MeterSphere專案的深度使用者和粉絲，對於這款產品既熱愛，也期待她能夠越來越好。因此，我在這裡將建議轉為了期待，和大家梳理一下我所期待的MeterSphere專案在未來能夠增加的新特性：

1. 期待MeterSphere以後可以在初次進入產品頁面時提供產品引導，幫助使用者快速地熟悉產品功能分佈。更新版本後，核心的特性也要提供指引，畢竟大部分人都不會看釋出日誌的；
2. 期待在場景中可以一次刪除多個指令碼，因為我會複製上個場景，在其基礎上編輯新場景的指令碼，但是可能會刪除場景下的多個指令碼。希望在這裡可以按住Shift或Ctrl鍵，支援選中多個指令碼進行刪除、禁用等操作；
3. 在指令碼執行結果中，希望能夠標記指令碼失敗的原因。是發現了Bug？還是指令碼不穩定等其他問題所導致的？這樣我們可以統計指令碼失敗的資料，並分析改進；
4. 希望可以在首頁對測試報告進行視覺化，類似儀表盤那樣進行展示。執行了多少條指令碼？多少條通過？多少條失敗？要儘量醒目一點。個人感覺測試日曆沒有多大作用，可以放在次要的位置；
5. 希望在用例介面和介面測試介面增加一個全域性搜尋功能，要支援全域性搜尋用例、場景和指令碼；
6. 期待MeterSphere可以打通和TAPD或其他研發管理平臺的對接，支援將TAPD中的用例匯入到MeterSphere平臺中；
7. 社群運營層面，MeterSphere團隊可以建立一個超級粉絲群，一群對測試熱愛的人，有時間可以開一個遠端頭腦風暴會議，大家一起吐槽，對平臺發展建言獻策。

注：本文作者為寧波蔚瀾環保科技有限公司測試經理張浩。