編者注：在2022年8月13日舉辦的“2022 MeterSphere開源持續測試平台城市遇見· 深圳站”活動中，深圳思為科技有限公司測試經理雷華清分享了題為《MeterSphere在微服務架構中的自動化測試應用》的主題演講。以下内容根據本次演講整理而成。
深圳思為科技有限公司（以下簡稱為思為科技）成立于2011年，總部位于深圳，是一家緻力于用領先技術驅動房地産營銷數字化更新的SaaS服務商。思為科技面向開發商提供以數字内容工業化制作、營銷流程一體化打通、客戶資産沉澱及營運為核心的全場景營銷解決方案，通過實作樓盤數字化、場景線上化、資料資産化、營銷自動化，助力開發商打造線上線下一體、前後端打通的房地産數字化營銷閉環。
目前，思為科技已經在全球30多個城市設立分公司和辦事處，為500個以上的開發商提供服務，其中百強開發商覆寫率超80%。
深圳思為科技有限公司測試經理 雷華清
一、微服務架構中的測試難點
起初，思為科技的營銷雲産品以需求疊代為核心，在服務架構的設計上較為簡單，采用了傳統的大單體架構。後來，随着業務的增長，業務複雜度越來越高，傳統的大單體架構不足以支撐業務疊代。
為此，思為科技在架構上進行了更新，選擇了如今的微服務架構。因微服務架構具備高靈活、易拓展、高可用的優勢，能夠有效支撐公司複雜的業務系統。
微服務架構對測試提出了更高的要求，總結下來包括以下幾個方面：
1. 之前的大單體架構以業務型測試為主，微服務架構還需更多地關注元件測試，以及每個服務程序内部的功能及對外暴露的能力；
2. 維護環境體量變大。大單體架構時隻需維護少量環境，比如測試環境和生産環境。微服務架構則需維護整個架構：包括開發環境、測試環境、灰階環境及生産環境等；
3. API接口數量變多，且變更頻繁。微服務要把傳統的一些服務進行拆分，接口會變多，整個拆分的時候有内部接口、對外暴露接口，接口變更非常頻繁；
4. 重構次數增多導緻面臨大量的回歸測試。微服務因為便利性可以支援快速重構，每次重構對測試來說都會面臨大量的回歸測試；
5. 在微服務場景下，各個服務可獨立部署，可獨立疊代，這樣一來傳遞時間會縮短，測試的時間被壓縮。
在引入測試平台前，思為科技研發團隊采用的是傳統的軟體測試方法。然而傳統測試存在着諸多弊端。
相信很多測試人員都知道測試金字塔模型，從模型可以看出，單元測試在最底層，測試成本最低，最上面的是UI測試，由此也能看出越早做測試收益越高。
而實際的測試工作中往往與模型相反，呈現出倒金字塔模型。為了适應業務快速的疊代和市場變化，很多開發團隊沒有強制要求也沒有做很多的單元測試，有些團隊基本上是不要求就不會去做。比如開發人員比起單元測試，更多地喜歡進行上面一層的UI測試。
思為科技在使用測試平台前，在實際測試工作中面臨着以下困境：
1. 超過80%測試都是手工進行功能測試，執行收益非常低；
2. 自動化測試需要編碼能力，有一定門檻；
3. 開發團隊和測試團隊對立，認為品質保障是測試環節的工作；
4. 測試周期長，産品疊代速度慢。
因為測試資源緊張，産品開發完提測後，測試環節若有問題需要多次回歸，又因為面臨上線節點導緻團隊經常加班趕進度或發版延期等問題。若卡着時間節點上線産品，會産生很多生産問題，産品品質難以保障。
另外，因為整個測試的工作量非常大，且都是手工測試。開發人員在面臨一些底層架構不支援需要重構的情況時，考慮到每一次重構需要大量測試、大量時間而不敢重構，最終造成測試成為傳遞的瓶頸。
二、MeterSphere打破持續傳遞瓶頸
為了打破這一瓶頸，思為科技的測試團隊嘗試了很多方法。起初團隊嘗試過做自動化，專門建立了自動化測試團隊。然而自主研發測試自動化平台對團隊人員的技術要求非常高，且測試工作中不同測試狀态比較分散，使用的工具都不統一，用例無法統一管理。
是以，思為科技就考慮需要引入一個測試平台，在市場上調研了各種各樣的測試平台。思為科技也嘗試過自研，但是自研一個測試平台成本還是較高，且投入了一個開發團隊進行研發，成果卻并不理想。
最終，思為科技的測試團隊選擇了MeterSphere開源持續測試平台來支撐内部測試工作，滿足當時面臨的主要需求。
以下為MeterSphere在思為科技測試環境中的實際應用效果：
1. 使用MeterSphere平台跟蹤功能測試
思為科技營銷雲在引入MeterSphere作為測試平台後，做的第一個事情就是把整個功能測試的一系列動作、流程全部搬到了MeterSphere平台上。
應用特點：
■測試用例：使用腦圖編寫用例，快捷高效；用例線上管理，易維護；
■測試計劃：按照測試階段建立測試計劃跟蹤過程，有效把控進度；
■測試報告：自動生成測試報告以采集資料，減少手工統計的工作。之前測試人員需要使用Word寫測試報告，并進行相應的統計工作。使用MeterSphere平台後這部分工作得以簡化。
2. 通過MeterSphere插件打通IDEA與測試平台的接口同步
團隊最開始做接口測試時面臨一個難點，就是如何對接口進行管理、維護及更新。雖然MeterSphere是支援Swagger形式自動同步，但團隊内部不是用這種形式管理接口。這主要是考慮到Swagger有一定的代碼入侵，是以沒有用這種形式。
當時我們的接口布局比較散，分别放置在YApi平台、共享文檔和線下文檔等位置。另外，使用MeterSphere平台做接口測試需要保證接口實時更新，接口維護一定要實施及時。
在沒有使用MeterSphere的“metersphere-idea-plugin”插件時，導入接口是手動将接口從YApi平台導出後，再導入到平台進行更新。因手動導入、導出很麻煩，開發人員也不想做這些事，導緻推動很難。但如果接口前期不維護好，後續工作開展起來也很困難，是以想做這樣一個插件裝置在IDEA裡。
應用特點：
■ 根據服務的類型配置不同的同步政策，便于接口管理；
■ 在接口有變更時，IDEA上一鍵同步至測試平台，確定接口資訊的及時更新和維護。
注意：接口同步很關鍵，這是做好自動化測試的前提。
3. 線上管理接口
上面提到，我們産品内部的接口管理是比較分散的，使用MeterSphere可以将所有接口放在平台進行統一管理。由于采用的是微服務的形式，是以我們會把每個服務的接口單獨合并進行管理。
應用特點：
■ 統一接口管理工具，每個服務接口進行歸檔管理；
■ 接口實時更新，支援線上檢視；
■ 開發人員線上聯調、自測。之前開發的線上調試使用的是Postman，由于Postman隻能本地部署，很多參數配置無法共享。使用MeterSphere之後，其他人去通路調試的結果非常友善；
■ 資料統計，便于管理。在微服務的架構内，我們可以非常直覺地了解每個服務的接口狀态。
4. 微服務的接口測試
微服務接口測試是一個複雜的流程，接口文檔采用插件形式，如果服務中的接口有變更可以自動同步到MeterSphere平台上，這樣就不需要維護接口文檔，接口文檔就是MeterSphere平台。
開發進行Mock前後端聯調也是在MeterSphere平台上完成的。之前的瓶頸在于測試會覺得開發的品質很低，導緻每次提測的版本都需要重複測試。但是由于業務的快速發展，又不能要求開發逐個去寫單元測試。針對這種情況，測試團隊開始讓開發人員在需求提測時自己在MeterSphere平台上做接口測試，每個接口變動儲存一條用例，確定該用例能夠跑通。有了這個前提，測試團隊才會進行下一步的接口驗證，驗證前面的接口用例是否更新且能夠跑通，然後再考慮進行接口自動化測試。
應用特點：
■ 測試工作左移，在開發過程中就開始做接口測試；
■ 開發參與到接口測試的過程中，用測試檢驗開發的過程品質。開發團隊需要保證提測産品的品質，主動開展單元測試或者自測，開發實際參與到測試過程中；
■ 整個接口測試的流程都是在MeterSphere持續測試平台上進行的，整個過程可追溯。
5. 按照業務流程編排場景自動化測試
除了對單服務進行接口測試，團隊還會按照實際業務流程涉及的接口進行編排，進行場景化的自動化測試。
所有用例會進行每日定巡，通過寫定時任務，根據業務重要程度的不同，設定不同的時間跑一遍。跑的結果會與飛書系統打通，隻要結果有異常都會通知到飛書群，通知到對應的人員去處理更新。
更新後會進行自動觸發，因為整個過程結合到了DevOps流程裡，隻要版本觸發了建構部署，就會去執行。觸發有結果了相關技術人員就可以檢視是接口有問題還是場景編排有問題，然後進行持續改善、持續維護，最終完成測試的持續內建。
6. MeterSphere打通DevOps，實作微服務自動化測試全流程閉環
場景自動化的應用，最終離不開DevOps的經典流程。思為科技研發團隊所做的自動化測試，最終目的就是為了提效、回歸，減少手工的測試執行，必然會将場景自動化加到整個DevOps流水線中。
因為采用了微服務部署的形式，思為科技整個流程的架構較為複雜。我們将其歸納為的五個步驟：
第一步是建構。包含Apollo配置中心、GitLab-CI和Jenkins；
第二步是檢查。每一個服務隻要有建構，版本都會提升，如果涉及單元測試就會跑一次單元測試用例。因配置了Sonar，會進行代碼的品質檢測，如果代碼品質檢測不通過，就無法到達下一步；
第三步是部署。根據送出代碼的類型，部署到不同的服務及應用上；
第四步是測試。部署完成後會自動觸發整體的測試，此步驟通過MeterSphere測試平台提供的能力實作。比如說接口測試，接口編排完後，最終會把接口做成自動化，而後将每一個服務歸納成一個合集。當某一項服務有更新，隻會執行這一個服務的自動化測試直至通過。當系統中有多個服務同時去部署、釋出的時候，測試團隊會去跑場景化的測試。場景化的測試就是相當于系統中的核心業務，需要保證核心業務所需測試的功能是通過的，最終測試的結果會生成一個測試報告，這些工作均是自動化完成；
第五步是復原。如果前面的測試通過了，就代表正常的部署成功了；如果測試不通過的話，它會自動回歸到上一個穩定版本，然後會将測試結果進行通知。
在整個流程中，還配合着各種各樣的監控：包括事件監控、調用監控及資源監控等。監控之後還配合着整個系統的通知機制。任何一個環節出了問題，系統都會進行及時通知。
現在，思為科技内部的通知機制已經可以較好地支撐實際工作。當服務出現問題或者是有任何其他問題時，通知系統配置的機器人會自動拉群，把對應的人員拉到群裡。然後對應人員會立即去處理，處理完成後告知機器人，機器人便會關閉問題通知群，落地效果非常靈活。
最終，思為科技使用MeterSphere持續測試平台打通了DevOps流程，實作了微服務自動化測試的全流程閉環。
三、MeterSphere帶來了哪些效果和轉變？
在将MeterSphere測試平台融入到DevOps流程後，思為科技打破了持續傳遞的瓶頸，在實際生産環境中所獲得的價值收益展現在四個方面：
■ 測試提效：線上進行用例的編寫與評審，跟蹤執行過程自動生成測試報告，功能測試周期縮短了1/3。原來需要6天的功能測試現在縮短至4天；
■ 測開協作：測試與開發人員使用同一平台，開發參與到測試過程中，共同維護接口，為自動化測試提供保障。開發與測試從對立關系轉變為協作關系；
■ 快速疊代：核心業務的自動化測試，可以支撐一周兩次的版本疊代和多次重構更新，進而快速适應市場，滿足使用者需求；
■ 品質保障：把控業務品質的同時，檢驗産研的過程品質，提高所有人的品質意識，共同保障産品品質。品質保障不再僅僅是測試團隊的事情，測試驅動開發成為可能。
最後來梳理一下思為科技在MeterSphere持續測試平台各功能子產品的應用實踐：
■ 功能測試：測試用例線上編寫、評審，持續維護；對應各測試階段的測試計劃；線上生成測試報告，便于測試總結；跟進測試過程，及時發現風險并做出調整。
■ 接口測試：接口文檔及時更新線上維護；單服務接口測試覆寫100%；業務場景化接口編排覆寫80%；每日定巡，結合DevOps持續內建 。
■ UI自動化：模拟使用者真實操作，發現前端界面問題；Web端常用業務主流程覆寫20%；App端核心業務流程覆寫10%；每日定巡，持續內建。
■ 性能測試：單服務性能壓測，制定性能名額；混合場景性能壓測，滿足業務使用名額；服務重構、業務重大變更，滿足性能名額；性能壓測環境、壓測資源線上維護，減少資源浪費和重複性工作。
■ 監測體系：服務運作監控，及時發現服務異常；業務運作檢測，記錄業務報錯資訊；環境資源監控，資源占用達到門檻值及時告警；資訊自動通知。