給研發工程師的代碼質量利器 | SOFAChannel#5 直播整理

時間 2019-11-29

標籤研發工程師代碼質量利器 sofachannel#5 sofachannel 直播整理简体版

原文原文鏈接

<SOFA:Channel/>，有趣實用的分佈式架構頻道。
本文根據 SOFAChannel#5 直播分享整理，主題：給研發工程師的代碼質量利器 —— 自動化測試框架 SOFAActs。

回顧視頻以及 PPT 查看地址見文末。

歡迎加入直播互動釘釘羣：23195297，不錯過每場直播。

你們晚上好，我是螞蟻金服自動化測試框架 SOFAActs 開源核心成員青勤，目前從事測試技術相關的研發工做，今晚將由我來給你們分享交流自動化測試框架 SOFAActs 的基本原理和使用，今天的內容主要分爲如下四個章節：git

項目介紹
SOFAActs 接入
功能介紹與使用
升階功能使用

歡迎你們 Star 我，SOFAActs：github.com/sofastack/s…github

1 項目介紹

在分享使用操做前，我將引導你們來熟悉下 SOFAActs 的項目背景、基本原理等。數據庫

對於研發質量保障而言，金融系統和金融業務的多樣性、複雜性一樣也會在測試場景、測試驗證和測試流程的複雜程度上獲得充分體現。性能優化

譬如，對於包含出參、RPC 調用、DB 變動和異常等多個測試驗證點的用例而言，在研發和測試人員維護和驗證用例場景的過程當中，時常發生業務結果校驗遺漏，對咱們及早發現和糾錯問題形成干擾，進而沒法嚴格保障產品質量。這些問題對研發質量保障提出了很高的挑戰，相應的自動化、精細化的白盒測試工具需求日益增加，這其中就包括 SOFAActs。bash

爲了解決上述痛點、知足精細化測試須要，在多年測試實踐積累與沉澱下，咱們研發了基於模型驅動的 SOFAActs 測試框架，它能夠靈活、可擴展的提供一站式用例管理，標準化測試執行和精細化校驗。目前 SOFAActs 測試框架逐漸成熟並在螞蟻金服內部獲得普遍應用。架構

1.1 項目架構

介紹完背景，咱們來看下 SOFAActs 的大致框架，SOFAActs 底層封裝並集成適配 SOFABoot 等運行環境。框架

在重要的引擎層，SOFAActs 封裝了工具類和數據模型，並將測試模式的過程進行了標準化，提供通用測試能力和擴展點。對於有自動化測試經驗的同窗來說，測試模式其實並不複雜，這其中有不少工做是能夠抽象和固定的，SOFAActs 將這部份內容內聚到引擎層，封裝成標準測試流程等，尤爲是模型驅動和精細化校驗等，從而釋放精力，將更多關注點聚焦在待測目標上。編輯器

引擎層之上，是 SOFAActs 提供的可視化用例管理功能，能夠一站式的維護測試腳本、測試數據和數據模型，藉助可視化編輯器可成倍提升用例管理等等操做效率，總體而言 SOFAActs 圍繞模型驅動引擎和可視化編輯器，將測試代碼的編寫工做量極盡下降，目標聚焦在測試對象上。分佈式

這裏咱們示例看下，SOFAActs 對測試代碼和效率的優化。這裏以 Credit 接口爲例，業務處理開始以前會檢查傳參，構造上下文、隨後發起業務處理，涉及對三張表的讀取或變動，並在數據庫事物結束以後，返回業務處理結果。ide

針對這一業務邏輯，這裏咱們構造一個 Credit 接口的完整測試用例，在代碼驅動測試時，它須要一下 9 個步驟，手動準備依賴數據、構造請求參數、執行業務邏輯、校驗業務結果以及數據清理等等，人工介入成本居高，尤爲當存在多個用例時，測試代碼可複用性低，測試效率是難以獲得有效提高。而與之對比，在模型驅動測試下，Credit 接口的 SOFAActs 測試腳本會對固有的測試模式進行封裝，用例複雜度獲得極大精簡，衆多用例數據能夠獲得高效的可視化管理。

1.2 執行原理

在開始使用 SOFAActs 以前，咱們來了解一下有關 SOFAActs 執行引擎的運做原理。SOFAActs 框架也提供了很是多的擴展點，若是須要個性化的定義，能夠對每個環節進行擴展。

上文中已提到過 SOFAActs 執行引擎是對測試模式過程的封裝，Setup 方法是引擎入口，用於加載初始化 SOFAActs 運行時的必需資源，如獲取數據源。

如下是主體測試過程：clear、prepare、execute、check 這 4 個方法依次負責環境清理、依賴準備、執行、結果校驗等。這些內容是代碼驅動測試時須要手寫的測試代碼和內容，每一個測試腳本的完成意味着上面的過程會被咱們重複一遍，因而 SOFAActs 將這部份內容進行了封裝，實現了最通用基礎的功能。

右側，咱們對高頻數據如方法入參、出參、異常和依賴DB數據進行了抽象，給出 SOFAActs 的模型，這是代碼驅動轉向模型驅動、精細化校驗的基礎。左側的數據總線會貫穿每一個用例的執行生命週期，即貫穿中間的主體測試過程，若是你們對框架封裝的基礎功能有自定義須要，能夠經過數據總線對 SOFAActs 的對象、方法進行獲取、重寫，以便更靈活的控制框架行爲。固然 SOFAActs 對這些內容做了較好的封裝，覆蓋了大部分的測試需求，無需你們過分關注。

以上就是 SOFAActs 的執行原理，接下來我會給你們詳細介紹 SOFAActs 的接入和使用。

2 SOFAActs 接入

SOFAActs 分爲兩部分，其一是可視化編輯器，在 SOFAStack 官網上 [1] 咱們能夠獲取該編輯器的安裝包，並經過 IDEA 的插件管理進行安裝。其二是 SOFAActs 的基礎 jar，它提供了 SOFAActs 用例運行的環境支持，在 test 模塊 pom 中添加下列依賴便可，有關 test 模塊或者多模塊詳細內容你們能夠參考 SOFAActs 的快速開始文檔 [1] 。

3 功能介紹和使用

下面，咱們進入 SOFAActs 的功能介紹和使用章節，這部分我將分爲三小節展開：一站式構建、SOFAActs 核心的模型驅動以及 SOFAActs 提供的精準校驗。

3.1 一站式構建

一站式構建中，SOFAActs 經過可視化編輯器爲咱們提供了便捷操做，以幫助一鍵配置初始化、構建測試腳本與模型，可視化管理用例數據等等。藉助可視化編輯器，在整個過程當中咱們能夠替換大部分手工編寫代碼的工做，進行一站式操做。

一鍵初始化

這裏咱們示例看下，如何操做一鍵初始化以及一鍵初始化作哪些內容。首先一鍵初始化框架只須要 3 個鼠標點擊步驟。在 Package 視圖下選中測試模塊並右鍵選擇 SOFAActs 功能，一鍵初始化，輸入該應用的應用名稱和工程編碼格式。在一鍵初始化完成後，SOFAActs 將會在 test 模塊寫入 SOFAActs 配置文件，DB 鏈接配置文件，測試套件配置文件以及建立模型存儲目錄等。

acts-config 配置文件是 SOFAActs 的核心配置，提供了測試環境切換、數據庫鏈接切換、冒煙測試以及預跑反填等配置，來開關 SOFAActs 的相關功能；model 目錄用於存放對象模型、數據模型，以便對模型進行統一管理；DB 配置文件指明瞭數據庫鏈接信息，用於生成數據模型時自動填充表結構和模版數據。

一鍵生成測試腳本

在完成配置初始化操做後，咱們能夠開始第一個用例的編寫，SOFAActs 提供了一鍵測試腳本生成功能。以待測的 getMessage 接口爲例，在其方法定義上右鍵選擇 SOFAActs 功能，生成測試用例，在彈出框中檢查用例信息，修正無誤後點擊肯定能夠生成該接口的測試腳本。校訂依賴的啓動類並運行 SOFAActs 測試腳本，能夠看到可以正常啓動 SOFABoot，SOFAActs 會拉起 SOFABoot 以儘可能模擬業務代碼運行時的容器環境，所以若是存在 SOFABoot 上下文加載失敗，須要排查應用配置。

一鍵生成數據模型

一般在咱們建立 SOFAActs 測試腳本時方法入參和出參的對象模型會一併生成好，所以這裏着重介紹下如何一鍵生成數據模型。事先，咱們在 acts-config 配置文件中，指明 DB 環境如 dev 並配置 dev 環境下 DB 鏈接信息。就緒後，咱們打開測試腳本，在被 @test 註解的方法上右鍵選擇 SOFAActs 功能，生成 DB 表結構模型，在彈出視圖中選擇須要的 DB 表，當有多個表時，能夠一併添加至右側，點擊 OK 以生成 DB 模型，以後可在 model／dbModel 目錄查看生成的數據模型。

稍後模型驅動內容中，我將給你們詳細介紹 SOFAActs 中模型的概念和使用。

可視化用例管理

在 SOFAActs 編輯器中，咱們可以可視化地修改入參、DB 和結果數據等。在用例級別，編輯器提供了用例複製功能，對於設計等價用例而言，一般正常測試用例之間，異常測試用例之間的差別可能只在於某一關鍵字段的取值，而大部分數據是相同的，這時用例數據複用十分必要。SOFAActs 提供了用例複製等管理功能，可用於快速發起用例構建。

3.2 模型驅動

下面咱們介紹模型驅動，在代碼驅動測試時，方法入參、出參和 DB等測試數據是經過代碼組織的，隨着業務複雜度提高，尤爲在金融級業務場景中，類和表動輒十幾個屬性或者字段，屬性嵌套也時常可見，代碼驅動測試難移應對：測試腳本可複用性低、測試數據管理困難等問題。因而，SOFAActs 將方法入參、出參、異常和 DB 等數據抽象爲模型，用以結構化地記錄數據類型、取值和校驗規則，能夠快速發起用例數據構建。

SOFAActs 中的模型主要分爲：數據模型和對象模型。

對象模型：主要用於構造方法入參、指望結果和指望異常。指望結果和指望異常是指在符合測試預期下被測方法的返回結果或者異常拋出。

數據模型：對於一個有 DB 依賴的業務場景的測試驗證，須要生成相關 DB 表的數據模型，用於快速構建 DB 準備數據和指望數據。DB 準備數據是業務執行期間依賴的前置 DB 數據，例如在驗證轉帳場景時參與雙方的帳戶餘額等，DB 指望數據是指在符合測試預期下，被測方法對 DB 的變動。

通過模型化，一個複雜對象或數據能夠被快速模版化地建立、拷貝和校驗，達到測試數據與測試代碼解耦合的效果，另外一方面，配套使用 SOFAActs 編輯器，實現測試數據一站式管理，來提升用例編寫效率和下降維護成本。

下面我詳細介紹下數據模型和對象模型的結構和使用。

3.2.1 數據模型

一般 SOFAActs 只須要填充 DB 準備數據，而 DB 指望數據能夠利用預跑反填功能進行自動採集。

爲了更好地理解數據模型，在model／dbModel 下的 csv 文件中，咱們能夠看到某一張表的所有字段、取值以及校驗規則。數據模型聚合了表的結構、數據和校驗規則，結合可視化編輯器可快速建立、複製 DB 數據，一次編輯屢次使用。這裏咱們來看下示例，在編輯器如何使用數據模型。

3.2.2 對象模型

對象模型，它是方法入參、出參等對象在 SOFAActs 中的映射，能夠在 model／objModel 目錄下查看生成的對象模型。對象模型的結構和數據模型類似，是屬性、取值、校驗規則的聚合，與數據模型不一樣的是，對象模型可能存在多層嵌套，由於類的某一屬性能夠是 map、集合、類等引用類型。

在 SOFAActs 編輯器中能夠爲一個新的用例添加入參數據，若是入參是簡單類型，如 int、String 等能夠選擇簡單類型填充，這裏示例下複雜類型，即業務對象的模型使用，在左側的列表中選擇目標對象，添加至右側，若是有多個入參能夠一併添加到右側後，再點擊肯定，便可以在入參設置中看到入參數據並可進行編輯。對於有多個入參的方法，入參設置中從上之下的順序和方法聲明入參順序是須要一致的。

3.3 精細化校驗

下面咱們介紹精細化校驗，在一開始時，咱們說起到複雜業務場景下極易出現校驗遺漏，造成校驗假綠。爲此，SOFAActs 內置了精細化校驗，從校驗規則和行爲還原兩點，來保證複雜場景的校驗覆蓋。

如右圖，SOFAActs 將重複性 assert 代碼抽象概括爲校驗規則，與測試數據一同做爲數據模型的一部分，能夠細化校驗每一個字段。目前acts支持的校驗標籤以下，其中經常使用有 Y、N、C 標籤，Y 表示了校驗時必須一致的對象或屬性、N 表示校驗時不關心的屬性或記錄值、C 標籤標示 DB 數據校驗時的 DB 查詢條件，即 where 條件，參考右圖咱們能夠理解標籤的使用。

爲了真實還原業務行爲以提升驗證覆蓋和用例數據的編寫效率，SOFAActs 提供了行爲還原，做爲精細化校驗的一部分，行爲還原在 SOFAActs 中稱爲預跑反填功能，是指在方法入參、依賴的 DB 數據等用例正常執行的基本數據準備完成後，可先沒必要填寫指望數據而直接運行測試腳本，框架可自動捕獲運行時方法返回結果、全部 DB 表變動等數據，經過 SOFAActs 編輯器可填充用例的指望數據，小幅度修正和標記校驗規則後便可完成所有校驗點的參考數據的編寫。

這裏我給你們演示如何使用 SOFAActs 的預跑反填功能：

啓用 SOFAActs 的預跑反填功能須要在 acts-config 中打開結果收集開關，而後執行用例，運行完畢喚起 SOFAActs 編輯器，點擊左上角的預跑反填，選中須要的用例數據，點擊肯定就完成了相應用例的指望結果、指望 DB 數據的構造，但預跑反填功能自己並不保障校驗數據的準確性，須要針對待測業務場景將數據修正。

4 進階功能

下面，咱們進入本次分享的最後一部分，SOFAActs 進階功能的使用。這裏爲你們介紹使用頻度最高的兩個功能：自定義引擎流程和參數化。

稍作回憶，在一開始咱們熟悉了 SOFAActs 的運行原理，說起到 SOFAActs 執行引擎是對測試模式過程的封裝，同時爲數據模型、數據總線提供了擴展點，這裏咱們舉例使用、重寫這些 API 。另外一個高頻功能是參數化，提供了運行動態替換 String 類型取值的功能，以知足部分隨機動態的測試須要。

@Override
public void check(ActsRuntimeContext actsRuntimeContext) {
  if (actsRuntimeContext.caseId.endsWith("001")) {
    if (((AccountTransResult) actsRuntimeContext.getResultObj()).isSuccess()) {
      actsRuntimeContext.paramMap.put("status", "0");
    } else {
      actsRuntimeContext.paramMap.put("status", "1");
    }
    actsRuntimeContext.refreshDataParam();
  }
  super.check(actsRuntimeContext);
}複製代碼

咱們以 check 流程爲例，重寫了 check 方法來知足動態校驗，這裏依據返回結果設置了自定義參數，放置到數據總線 Actsruntimecontext 中，咱們將指望 DB 數據中的 mast 表的 status 字段設置爲自定義參數，表示該字段的指望值應該和方法返回結果中的狀態保持一致或者關聯。而後運行用例來查看咱們重寫的校驗是否達到了預期。