產品解讀丨MeterSphere介面自動化測試的應用場景和實踐

過去的十幾年，DevOps運動在中國得到了大範圍的推廣與發展，也湧現出了很多DevOps社群，它們在深度和廣度上都推動著軟體交付模式的變革。尤其是新冠疫情以來，企業的數字化轉型需求愈加強烈和迫切，軟體的迭代交付也更為頻繁，給軟體質量的把控帶來了新的挑戰，也提出了更高的要求。

正是在這樣的背景下，以及基於投入產出的效果考慮，軟體從業者們都意識到了測試的必要性，尤其是以介面為基礎的自動化測試的必要性。

在過去一段時間，我所接觸到的測試同行們中，大家普遍擁有做自動化測試的共識，但也都面臨著不同的難題。有的是在等待領導決策，需要一些量化的評估指標；有的是一直在不同的技術框架下嘗試和選擇，比較碎片化，沒有形成統一的自動化測試平臺；有的是基於某個開源框架，通過大量程式碼開發自主建設，卻在長期維護上需要持續投入較大精力……

MeterSphere開源持續測試平臺提供了測試跟蹤、介面測試、UI測試、效能測試等一站式能力。尤其在介面測試上，基於B/S架構，將傳統的單純依託程式碼開發或JMeter這樣的單體工具的測試方式，轉變為線上協作、視覺化、簡單拖拽的方式來進行介面自動化測試，極大地降低了自動化測試的學習曲線和准入門檻，也為介面自動化測試的持續維護提供了工具支撐，賦予團隊和組織將測試用例、測試資料、測試執行記錄和測試結果沉澱為資產的能力。

MeterSphere介面自動化測試應用場景

1. 建立自動化測試體系

對於正準備開拓介面自動化測試的團隊，MeterSphere提供了從介面定義到單介面用例，再到跟業務場景關聯的場景用例的測試業務邏輯。對於一些現有的測試指令碼，支援通過匯入的方式一鍵遷移到MeterSphere平臺，實現無縫切換。

目前MeterSphere平臺支援的匯入源有MeterSphere、Postman、Swagger、HAR和JMeter。以Swagger為例，可以通過Swagger URL直接匯入介面定義，並且支援定時同步，能在結果變化時，自動獲取最新的介面定義。

通過這種線上視覺化的互動，測試人員能快速上手，有利於介面自動化測試的開展與推廣，從而幫助團隊建立起自身的自動化測試體系，提升質量內建的能力。

2. 企業級軟體測試

現在有越來越多的企業比以往更加重視軟體測試以及圍繞測試所進行的質量保障活動，將測試納入到端到端的軟體研發體系建設中進行規劃。企業級的軟體測試要求既能滿足傳統的專案組織方式，又要能滿足各種敏捷團隊的測試需求，包括中小型敏捷團隊和部落制敏捷團隊。

MeterSphere持續測試平臺所提供的“工作空間-專案”的組織和資源隔離機制，可以靈活滿足不同規模企業的測試團隊和專案組織的實踐需要；而其提供的“角色-人員” 的許可權機制，又能滿足同一專案團隊內部人員根據角色分工的不同分配不同許可權的實際需要。

尤為重要的是，內部崗位變動和外部因素造成的人員流動是不可避免的，也是正常的。所謂“鐵打的團隊流水的兵”。統一的測試平臺可以幫助企業建立統一的測試技術棧和測試執行工具，避免“百花齊放”的現象，為統一的測試流程建設和團隊協作提供技術支撐。

3. 持續測試

軟體的持續交付往往具有輕量、快速、按需、頻繁等特徵，這同時要求測試具有可持續性，要能滿足持續交付與持續釋出的要求。

MeterSphere作為以“持續測試”為定位的平臺，不僅本身支援自動化測試，賦能測試人員專注於測試用例的設計、維護、執行與反饋，同時支援DevOps平臺對自動化測試用例的遠端觸發和定時觸發，將測試平臺融入到DevOps的流水線當中去，真正實現開發、測試、反饋的持續交付閉環。

由於MeterSphere提供標準的RESTful API介面，無論是廣泛使用的Jenkins、GitLab這類開源CI工具，還是諸如Azure DevOps和雲效的商業DevOps平臺，亦或其他各類研發管理平臺的流水線均可以呼叫MeterSphere的自動化測試用例、測試場景和測試計劃。專案團隊可以根據各自專案的特點和需求，在設計自己DevOps流水線的時候，靈活組合並呼叫相關的自動化測試用例。

4. 擋板測試

現代軟體功能越來越豐富，導致服務間依賴和呼叫也越來越多。服務間依賴主要分兩種情況：一是軟體本身的架構，越來越多地採用微服務架構，不同的服務可能會由不同的團隊負責，而不同團隊之間的進度差異很可能無法滿足本專案團隊的測試要求，進而導致測試處於阻塞狀態；另外一種情況可能是由於功能上的需求，軟體需要呼叫一些外部服務，例如地圖服務、通知服務、OCR服務、大資料服務、物聯網服務等，這既可能是由於內外網隔離的網路原因，也可能是由於這些外部服務相對更不可控，出於穩定性考慮的原因。

MeterSphere Mock服務可以根據使用者輸入的請求引數、返回資料來生成Mock介面。這些介面會自動生成模擬資料，覆蓋使用者的一些測試需求。同時，Mock期望可以根據設定的請求觸發條件進行過濾，返回期望的資料。

5. DevOps評級

信通院釋出的《研發運營一體化（DevOps）能力成熟度模型》第三部分“持續交付”對測試管理和自動化測試提出了明確的要求，包括自動化設計、自動化開發、自動化執行、自動化分析等幾方面。

該能力成熟度模型指出，自動化測試需要建立統一的自動化測試框架，統一管理自動化測試用例，需要對介面與服務採用自動化測試，能由流水線自動觸發，並且對自動化測試結果要具備較強的自動判斷能力。

目前，MeterSphere開源持續測試平臺已經對業界普遍期望的DevOps評級進行了針對性的支援。例如加入了“誤報庫”，測試人員可以對網路、環境等非應用原因導致的失敗設定相應的規則，在自動化用例執行的過程中，由系統根據誤報規則進行自動判斷和標記。

目前，MeterSphere支援對響應頭、響應碼和響應體設定規則，運算子包括“等於”、“包含”、“不包含”等。所有的誤報規則基於專案進行設定，以支援各專案團隊根據自身的需求設定相應的規則。

MeterSphere介面自動化的典型功能

1. 環境管理

測試用例的環境無關屬性是用例能夠重用的重要基礎。MeterSphere通過專案級別的環境管理將環境相關的變數進行抽象，並按照Dev、QA、SIT等進行組織，測試用例通過選擇執行環境即可在不同的測試環境中進行執行。

MeterSphere的環境管理支援設定通用的請求引數、環境相關的域名配置、資料庫連線資訊、證書配置、全域性前置指令碼、全域性後置指令碼、全域性斷言等。目前已經內建了測試中常用的MySQL、SQL Server、PostgreSQL、Oracle資料庫驅動，對於其他像Redis資料庫，可通過外掛的方式進行擴充套件。

2. 檔案管理

測試平臺最重要的功能是提供了一個協作和自動化框架。在實際測試工作中不可避免地有個性化場景需要特殊處理，例如個性化的加解密演算法、封裝的資料準備和資料處理程式等。MeterSphere支援測試團隊上傳自己的Jar包，並在前後置指令碼中進行引用。

3. 自定義程式碼片段

自動化測試中經常需要新增前後置指令碼和自定義指令碼。通過程式碼片段功能，測試人員可以儲存常用的指令碼，在需要使用的地方直接新增引用即可。前面提到的Jar包上傳後，除了在前後置指令碼中使用，也可以在程式碼片段中引用。

示範程式碼片段：

import org.apache.commons.codec.binary.Base64;
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;

String accessKey = "axNBP3PxyVdtvkaw";
String secretKey = "DayAGHyuUAXKLeI7";

public static String aesEncrypt(String src, String secretKey, String iv) throws Exception {
  byte[] raw = secretKey.getBytes("UTF-8");
  SecretKeySpec secretKeySpec = new SecretKeySpec(raw, "AES");
  Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
  IvParameterSpec iv1 = new IvParameterSpec(iv.getBytes());
  cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, iv1);
  byte[] encrypted = cipher.doFinal(src.getBytes("UTF-8"));
  return Base64.encodeBase64String(encrypted);
}

try {
  //呼叫加密演算法生成簽名
   String signature = aesEncrypt(accessKey + "|" + System.currentTimeMillis(), secretKey, accessKey);
  //將簽名值存入 signature 變數中
  vars.put("signature",signature);
} catch (Exception e) {
  e.printStackTrace();
}

4. 版本管理

版本管理主要是與“被測系統的迭代版本”所對應的用例標記，它是一個在專案級別可單獨開啟的功能。

當開啟版本管理後，專案管理人員可以根據迭代釋出計劃建立相應的版本：

如下圖這樣，介面定義、單介面用例和場景用例都將與版本進行關聯。

■ 介面定義可以在不同版本之間切換與對比

■ 介面的不同版本的對比

5. 場景用例

MeterSphere的場景用例又稱為“介面自動化”。一般是根據業務場景所設計的自動化用例，由多個單介面步驟通過拖拽的方式組裝而成。支援介面執行次序的設定、前後介面間引數的提取與傳遞、斷言設定、ForEach/While迴圈、If…Then條件判斷控制器等，極大地簡化了介面自動化的設計和維護成本，使人人都能上手做自動化測試成為可能。

MeterSphere介面自動化快速上手

一般情況下，MeterSphere建立自動化測試由以下三個步驟組成：

下面的例子主要是用MeterSphere的介面自動化能力，呼叫MeterSphere平臺本身的介面，批量建立MeterSphere使用者的場景。本示例通過環境變數accessKey和secretKey，結合全域性前置指令碼生成Signature簽名進行介面鑑權，中間也涉及到CSV資料檔案、迴圈控制器、引數提取、斷言等基本設定。

1. 介面定義

利用介面定義的匯入功能，將MeterSphere介面匯入到平臺的介面列表中。

MeterSphere Swagger URL：http://<ms-server>/v3/api-docs

2. 介面用例

建立 /user/special/list/{goPage}/{pageSize}介面用例，設定請求頭、請求引數。

3. 場景用例

■ 建立場景

在“介面自動化”標籤頁下建立場景；

■ 設定場景變數

新增CSV型別的場景變數，將CSV上傳至平臺，並根據CSV格式設定分隔符；

CSV格式及參考內容如下：

name,age,email
demo_1,20,[email protected]
demo_2,30,[email protected]
demo_3,40,[email protected]
demo_4,32,[email protected]
demo_5,25,[email protected]

■ 複製引用單介面用例（CASE）

本示例選擇將單介面用例（CASE）複製到場景，並設定執行次序；

■ 建立前驗證

為了方便對比建立前後的使用者變化，特意將“demo_”字首的使用者提取出來；

① 設定斷言

② 提取引數

■ 建立迴圈

新增迴圈控制器，並在控制器內巢狀建立使用者的介面請求。請求體中的變數${name}即為從CSV中取出來的使用者名稱；

■ 建立後驗證

最後，再次呼叫“獲取使用者”的請求，獲取使用者列表。

■ 設定環境變數

設定accessKey和secretKey鍵值對

設定全域性前置指令碼（具體內容參考“自定義程式碼片段”）

■ 執行場景用例

總結

從前面的實踐可以看出，MeterSphere作為開源開放技術基礎之上的一站式持續測試平臺，可助力企業建設自己統一的測試服務平臺。在敏捷開發的過程中，企業可以藉助MeterSphere將持續測試的理念付諸實踐，形成DevOps持續交付閉環。

MeterSphere本身依託開源社群成長和發展，具有以下多方面優勢：

1. 生態

■ 開源

MeterSphere本身採用開源的方式運作，是最貼近一線測試人員的一種方式。其功能需求基本直接來自一線的測試人員，問題反饋可直達研發團隊，反饋後的解決也比較快速，在產品功能和質量上都有保障；

■ 開放

MeterSphere基於JMeter技術，技術相對開放和通用，擁有良好的技術生態和廣泛的使用者基礎。產品本身也擁有與周邊平臺的整合能力，能夠較好地融入到企業現有的研發測試流程中去；

■ 社群

MeterSphere擁有自己的技術社群，能夠團結廣大測試從業人員和愛好者，不斷擴充社群的技術隊伍，為產品的潛在推廣來培養和沉澱技術人員。同時，也便於企業吸收相關專業技術人員、建設技術團隊，縮短學習和推廣曲線。

2. 治理

■ 統一

通過測試平臺建設，企業能夠進行測試相關的統一治理，避免工具碎片化。同時方便統一測試流程的建立，並提供統一的測試服務；

■ 標準

標準化的測試工具和測試框架，將使整個軟體交付過程也更為標準和成熟。通過將測試融入到交付流水線中，使質量真正內建於專案團隊中，以更為高效和更廣泛的覆蓋率支援冒煙測試、可用性測試和迴歸測試等多種型別的測試工作；

■ 沉澱

企業可以將測試用例、測試執行記錄、測試報告等沉澱下來，形成企業的測試資產，為測試用例的重用提供根本支援，也在必要的時候提供測試的相關回溯。

3. 技術

■ 視覺化

相較於傳統的介面自動化工具，MeterSphere首先提供的是協作式平臺，能以視覺化的方式建立自動化案例，支援更為高效的測試用例編寫和維護；

■ 低程式碼

MeterSphere的自動化用例除了前後置指令碼或程式碼片段，並不需要編寫其他程式碼，更多的是通過介面的組裝生成用例；同時，MeterSphere平臺還提供了多種控制器，例如事務控制器、迴圈控制器、條件控制器、等待控制器等，這大大降低了自動化測試的准入門檻；

■ 易上手

視覺化和低程式碼意味著有更多的人員可以投入到自動化測試的工作中來，也意味著測試效率和測試覆蓋率的雙重提升。

過去自動化測試之所以在很多組織中推廣有難度，就是因為測試人員既要懂業務，也要懂測試，還要會開發，而會開發的測試人員更是難找。無論從社群的反饋還是已有企業使用者的反饋，MeterSphere在企業的推廣過程都較為理想，而且幾乎所有專案團隊都能順利地基於MeterSphere開展自動化測試。

4. 服務

開放與服務是MeterSphere最為鮮明的兩大特徵。MeterSphere一直注重社群使用者和企業使用者的使用體驗，秉持著“軟體用起來才有價值，才有改進的機會”的理念，為社群和企業使用者持續提供專業的支援服務。

■ 社群服務

社群使用者除了可以自己直接在GitHub提交Issue反饋需求與問題之外，MeterSphere還有專門的企業微信群，由專業技術人員為社群使用者解答軟體使用的相關問題；

■ 企業服務

對於購買了MeterSphere企業版的使用者，MeterSphere提供了一對一的售後支援服務，由專門的技術團隊負責，能夠及時響應企業使用者在使用過程中的問題。同時，研發團隊對於企業使用者所提出的需求，也會優先進行評估和排期。