編者注：在2022年8月13日舉辦的“2022 MeterSphere開源持續測試平台城市遇見· 深圳站”活動中，深圳法大大網絡科技有限公司測試負責人董虎分享了題為《基于MeterSphere打通DevOps流程》的主題演講。以下内容根據本次演講整理而成。
法大大是國内領先的電子合同與電子簽雲服務平台（Fadada Agreement & Signature Cloud），緻力為企業、政府和個人提供基于合法數字簽名技術的電子合同和電子單據的線上協同簽署及管理服務，建構商業契約的數字化基礎能力，助力企業數字化轉型和社會數字化更新。
法大大的主要産品能力及服務包括：電子簽名和電子印章管理、合同模闆創作和管理、合同或檔案的多方協作簽署、簽署後的合同管理、合同智能稽核及全鍊路存證和出證服務等。企業的各種數字化業務系統、IT系統及産業網際網路平台，可與法大大平台無縫內建，實作具體業務場景與電子簽的全鍊路數字化閉環，進而促進業務發展、效率提升、安全保障和風險控制。
深圳法大大網絡科技有限公司測試負責人 董虎
一、法大大的業務背景
法大大所有的産品子產品共同建構起了一個完整的Fadada Cloud，并通過以下兩種方式為客戶提供服務：
■ Cloud（SaaS和OpenAPI）
■ Open Platform，簡稱為OP（OP-SaaS和OP-OpenAPI）
這兩種方式都可以通過SaaS或OpenAPI的模式與使用者及客戶系統進行互動。SaaS和OpenAPI并存的模式是法大大産品體系的一個特色。
其中SaaS産品為标準上市産品，也就是即開即用産品，會被較多的使用者所采納，包含PC端、小程式、微信、企業微信之類産品。它們的背景服務一般會有自己的架構。法大大的SaaS模式背景架構有以下幾個次元：
① 前端的APP類産品：終端産品；
② 前端對應的背景；
③ 背景的Business Facade（業務外觀）層；
④ Core（核心）層和業務層。
與之對應，測試産品也可以做出分層，即不僅僅将其當作一個簡單的工具去設定或者使用，而是做出産品形态的劃分。
OpenAPI內建模式的産品也擁有一定的使用者群。很多客戶不願意直接使用SaaS版本的産品，而是會采用內建的方式與公司内部的系統打通，與業務進行關聯。
二、為什麼使用MeterSphere開源測試平台？
法大大的測試團隊人數在30人以内。對于這種規模的團隊，如果公司支援的話，會安排少部分專屬的測試開發人員，去定制開發測試平台；其他絕大部分測試人員則是集中于業務測試方面。但在實際工作中，公司業務很多，測試開發人員也需要去做業務測試的工作。另外，這少部分測試開發人員開發出的測試平台也不一定能夠滿足目前的業務需求。
從時間、成本、效率三個次元考量，并考慮到後續項目推廣的要求，經過對多個現有測試産品的調研，最終我們決定使用MeterSphere開源持續測試平台。
選擇MeterSphere開源持續測試平台的理由如下：
■使用體驗佳：MeterSphere的界面簡單易用，具備接口管理、接口用例管理、自動化測試的編排能力，支援自動輸出測試報告能力，大幅縮短了原來的測試時長；
■能夠在不同Scrum團隊、項目中推廣：具備簡單易用的特性、項目團隊協同能力，以及個性化的協定滿足能力；
■測試資料的沉澱與量化，并直覺顯示：使用者可以以此建立一套可量化的評測體系來衡量測試人員的工作情況，提高測試的能效。
MeterSphere是一個簡單易用的測試平台工具，不過這也不意味着使用MeterSphere進行測試工作沒有技術含量。
我們也可以将MeterSphere與我們自己的測試産品內建使用，比如與TAPD、Jira進行內建；我們可以提供标準化的API産品，讓第三方公司可以內建MeterSphere平台去完善自己的産品，同時也可以去提供GUI，實作一些原本不易實作的互動驗證。這樣一來，第三方公司就可以結合自己的業務內建MeterSphere。
結合公司的業務去思考，雖然整個MeterSphere的架構比較複雜，但因為我們公司的團隊是以Scrum團隊模式去運作，實際在使用者層面，我們每個産品的子產品也都是子產品化部署的。也就是說，我們的每個産品測試中也隻需要用到一些基本的功能，是以隻要按需上架産品功能即可。
如果需要測試方案的第三方團隊要求比較高，則需要針對其産品特性去做定制。
三、自動化測試流水線整體思路
最初法大大的測試團隊在整個DevOps流水線中存在感較低。在我們的PipeLine（流水線）鍊路中，從代碼倉庫的建立、掃描，到建構部署鏡像等步驟，都有可使用的工具，甚至我們的釋出工具從SIT（系統內建測試）、UAT（使用者接受測試）和生産都有智能的平台工具。但是整個鍊路缺乏測試平台的接入和打通，且測試環節中沒有平台化的工具展現，所使用的都是JMeter、Postman等本地化的工具。
有了MeterSphere開源持續測試平台後，我們着手将其嵌入公司的自動化測試流水線。
1. GitFlow分支
在建設自動化測試流水線之前，我們首先需要了解GitFlow分支釋出的流程規範。
法大大的GitFlow流程如下：
① 拉取線上歸檔分支的feature分支（開發分支）去進行開發；
② 提測之後，将代碼合并到test分支（內建測試分支）進行測試；
③ 在test分支的測試通過之後，将代碼合并到release分支（發版分支）；
④ 線上測試通過、釋出成功後歸檔到master分支。
我們與開發、運維、測試人員等全面同步了GitFlow分支釋出的流程規範，加深了各部門對DevOps中這個重要環節的了解。
2. 基于MeterSphere的自動化測試平台流水線
法大大内部使用的是穩豸釋出平台，這是一個我們基于Jenkins自建的平台，使用體驗更佳，也更适配我們的日常工作流程。穩豸釋出平台基于GitFlow分支管理規範去運作，為我們的測試工作帶來更良好的體驗。
基于MeterSphere平台的自動化測試流水線
法大大的自動化測試流水線整體思路如下：
① 在部署環境推進項目時，測試人員與運維人員打通MeterSphere與穩豸釋出平台等其他平台；
② 部署成功之後，發送一個Kafka消息到内部的品質平台，内部品質平台就可以擷取服務資訊，包括它的環境、版本資訊、鏡像号以及服務名稱等；
③ 擷取服務資訊後，到品質平台對應的測試計劃做智能比對。比對到測試計劃後，即可排程對應的MeterSphere在ms-api-server層的應用服務接口，用它去跟MeterSphere做實際的互動，也就是執行MeterSphere的測試計劃；
④ 由MeterSphere來測試對應的真實應用服務，然後把測試結果資訊回傳到ms-api-server層；
⑤ 對MeterSphere的測試結果進行解析，傳回測試報告資訊到品質平台，并将測試結果通過企業微信通知給對應人員。
3. 測試跟蹤-測試計劃管理
MeterSphere的自動化測試功能确實非常強大，不隻可以用于功能測試，也可以用到接口自動化，以及後續的UI自動化。MeterSphere可以內建被測對象的内容子產品到測試計劃中，隻需要去排程對應的測試計劃辨別，就可以友善地調動多個測試用例。
4. 自動化測試流水線-用例執行及通知
通過MeterSphere平台可以進行測試計劃的管理和排程、測試結果的上傳，也可以定制測試結果通知消息模闆的配置管理政策等。
測試結束後，平台會将測試結果以流水線中設定的格式，通過企業微信群告知測試人員。實際上在我們的自動化測試流水線中，平台會更加詳細地記錄用例執行的方式、過程以及結果等具體資訊。這也是MeterSphere平台本身所具備的能力。
我們可以憑借這些記錄來判斷哪些真實的業務場景實際應用得更多，這樣就可以進一步得知團隊應該在哪些方面着重發力。
5. 自動化測試-代碼覆寫率平台
由于網際網路公司的發展較快，測試工作也需要随着不斷更新疊代的産品而逐漸完善。在此過程中，測試品質的評估可能更依賴于主觀或者業務的熟悉度。但是除主觀判斷以外，對于測試工作，我們也需要一套客觀的衡量标準。
測試覆寫率這一名額就可以在一定程度上滿足我們的自動化測試品質衡量需求。在實際工作中，我們可以基于功能測試以及測試工作的策劃讨論，通過代碼覆寫率平台去收集、分析測試的結果，再去檢視真實的測試情況，相對客觀地評估自動化測試水準。
四、MeterSphere在法大大的使用情況
在2021年10月之前，法大大的部分測試團隊就已開始使用MeterSphere開源持續測試平台。直至現在，法大大各個業務線都已經開始推廣使用MeterSphere平台，測試覆寫率較高。
MeterSphere開源持續測試平台在法大大的整體使用情況如下：
■ 項目數量：10+；
■ 接口數量：3000+；
■ 自動化測試腳本數量：數千個；
■ 接入使用者數量：50+。
法大大的測試團隊主要使用MeterSphere平台來進行内部業務5.0和5.1兩個版本的測試工作。不同模式産品的測試團隊對MeterSphere測試功能的要求不同：
■ SaaS産品：對MeterSphere測試要求較低，主要集中在功能測試方面；
■ OpenAPI産品：對MeterSphere測試要求較高。需要随接口的變動去重新組裝接口腳本。同時，由于法大大電子業務對安全性的高要求，每個接口的傳輸有加密要求，無形中提高了我們測試工作的成本，編寫腳本時經常遇到困難。
作為應對，我們用到了MeterSphere一個比較強大的功能——Jar包管理。在團隊自動化測試流水線中嵌入MeterSphere平台之後，我們依靠MeterSphere在前後置腳本中使用BeanShell引用外部Jar包的功能解決了這一困難。基于MeterSphere平台，我們可以提前準備好加密的Jar包，将它們上傳到平台，然後在對應的腳本中直接引入需要的Jar包。
不過，我們在實際測試業務中也遇到了一些問題。在單個場景中，往往會有多個接口請求，而每個接口請求都需要測試人員寫出對應的BeanShell腳本，不但過程繁瑣，而且對不擅長Java的測試人員也不友好。
為了解決這個問題，我們将邏輯封裝進了一個名叫“Fadada Data Center”的自用服務，然後把需要加密的核心接口全部交給這個服務去處理，讓它通過設定好的函數去請求伺服器。這樣就可以降低對測試業務人員測試開發能力的要求，隻需要測試人員對業務的邏輯了解清晰，具有接口與接口之間的參數關聯能力和整個邏輯的處理能力即可。
五、後續自動化測試平台完善計劃
1. 接口測試用例導入
目前法大大是用Swagger去管理接口文檔的，之後我們計劃新增一個功能，使得基于Swagger的接口可以自動生成對應的接口用例。這樣就可以免去URL參數及其描述資訊的填寫步驟，直接初始化成功，讓MeterSphere平台的使用成本更低，讓整個自動化鍊路運作更加順暢。也讓測試人員可以專注于測試工作本身，而不是反複進行工具的切換等重複性的工作。
2. 自動化測試與測試覆寫率平台挂鈎，實作用例執行情況可視化
目前我們的自動化測試平台與測試覆寫率平台依然是比較分離的狀态。在一般的功能測試和自動化測試結束之後，我們隻能在本平台上看到測試報告，然後再去相對主觀地推演測試的結果。我們希望可以将自動化測試平台與測試覆寫率平台關聯起來，使得測試執行結束後即可在我們的品質平台看到自動化測試的覆寫率情況，也可以實作用例執行情況的可視化，形成更加整體化的測試工作閉環。
3. 将性能測試更好地應用到項目中
目前公司的性能測試工作主要使用的是JMeter本地工具，還沒有應用測試平台工具。希望之後能将MeterSphere平台的性能測試子產品也應用起來，創造更大的工作價值。