造數 - 我的理解與落地實踐

“造數工廠” 是什麼？

理解思考造數工廠是什麼之前，我們先需要搞清楚業務功能（前端、服務，資料）之間的關係

在業務系統中，業務資料一般由使用者發起業務流程產生，也就是由功能產生，這是所謂的正向資料流，例如 “新建” 相關的功能。而產生的資料為後續的業務功能提供基礎支撐，例如 “查詢”，“更新”，“記憶體運算” 等，這是所謂的逆向資料流。使用者的操作產生資料，產生的資料根據業務要求進行一系列的操作和加工又反饋給使用者。所以在業務系統中，我們可以把功能劃分為三大類：

1. 產生資料的功能;
2. 使用資料的功能;
3. 產生和使用資料的功能;

透過上圖可以看到：

1. 功能 A 類似 “新建” 或 “資料接入” 的功能，純產生資料。
2. 功能 B，功能 C 類似 “編輯”，“刪除” 的功能，使用其他功能產生的資料，並進行運算元據進行增、刪、改。
3. 功能 D 類似 “查詢” 的功能，對已經存在資料根據業務要求進行查詢，聚合，記憶體運算，當然這種功能業務產生資料，但這些資料都是存放在記憶體中，並不會持久化下來，一定時間後會被清理掉。 透過上圖也可以看出一些基本常識，在業務系統中功能和功能之間、資料和資料之間，功能和資料之間存在依賴。 正是這個 “依賴” 為 “造數工廠” 的定義提供了有效的參考。我個人理解造數工廠是一種在軟體生產過程中為功能直接快速提供業務資料支撐，縮短業務鏈路，豐富資料樣本的能效工具。在文章後續的內容中，會圍繞這個定義進行展開。

為什麼生產過程中需要類似 “造數工廠” 工具的存在？意義是什麼？

我們站在開發、測試兩個角色去看待這個問題。

開發：

1. 又要聯調了，開發環境沒有支撐聯調的資料啊？
2. 開發 A：“我的功能要依賴開發 B 負責的功能產生的資料，我不是很瞭解，開發 B 你幫我弄一下唄”。 開發 B：“我沒時間哦，我還要搞其他需求”。
3. 聯調過程中， 前端開發：“介面 500，後端看一下” 後端開發：“資料缺失了，我補一下，你再看看” 前端開發：“介面還是 500，後端看一下” 後端開發：“資料還有缺失了，我補一下，你再看看” 前端開發：“介面依然 500，後端看一下” 後端開發：“資料怎麼還有缺失啊，那個後端開發，你幫我看看” 10 分鐘過去了，介面還沒 200

現在很多微服務基於 DDD，後端開發各自專注於自己的領域中，對依賴服務的內部邏輯和資料結果並不關注，只關注互動介面提供的資料結構和含義。這就導致了很明顯的問題，開發環境進行聯調時，花費大量時間在依賴資料的構造中，效率極低。

測試：

1. 我的目標測試物件是功能 X，但是功能 X 依賴其他功能路徑和對應的資料，難道我一定要把其他功能路徑跑一遍後，我才能測功能 X？

如果測試人員在迭代中為了生成目標功能依賴的業務資料，而去把程式碼未發生任何變動的功能都跑一遍，這種方式是低效率無意義的。在整個測試過程中，只有階段 2 才是有效的測試。

如果有造數工廠，你的工作流程會變更為：

你可以在測試設計階段中，在造數工廠中將你測試過程中需要的資料先準保好，在測試開始的時候直接在造數工廠中生成依賴的業務資料就好。

1. 我的 UI 自動化測試用例，介面自動化測試用例都需要非常多的前置條件，搞得我的指令碼內容好多，維護成本大大提升題。

在自動化測試的實踐過程中，以下問題會阻礙自動化測試落地：
* 用例和用例之間不獨立，依賴嚴重
* 測試點小、用例大
* 維護指令碼成本大
這三個問題背後的原因很大層度都是被 “測試場景構建” 的問題影響：
* 下一個測試用例的測試場景構建，依賴上一個測試用例的執行
* 為了構造測試場景，不得不做很多額外的操作，導致指令碼步驟增多，從而導致整個自動化測試的穩定性下降
* 用例無效內容多，不同用例關聯關係緊密，與測試點無關的功能變動有可能也會導致用例執行失敗
透過造數工廠的能力，將自動化測試指令碼強依賴的測試場景構建從自動化測試本身抽離出來，自動化測試的用例只需要呼叫造數工廠進行測試場景構建。從而解決以上三個問題。

“造數工廠” 應該具備哪些核心能力

• 資料來源管理能力
  • 用能依賴的資料可能來源於不同的資料來源，例如：Mysql、Clickhouse、Redis、ES 等，因此需要支援不同資料來源的造數。
• 業務系統中常用、通用資料抽象能力
  • 多種造數過程中會使用到相同的資料內容，因此這些資料需要抽象出來，可以複用在不同的造數過程中。
• 造數邏輯編寫、組織能力
  • 我們採用自行編寫語言的方式對造數過程進行設計，並對造數過程中依賴的內容進行組織和管理。
• 造數過程中中間資料記錄和傳遞能力
  • 造數過程中，步驟和步驟直接需要資料的傳遞，因此造數過程中需要具備儲存、記錄中間資料的能力。
• 造數過程隨意在開發、測試環境切換的能力
  • 同一個造數過程可以在不同的環境中使用，相同功能的資料不需要在不同的環境中都具備造數過程。
• 造數過程拼搭能力
  • 不同的造數過程可以隨意的拼搭，組織，這樣可以保證造數過程在不同功能中的複用。

我的 “造數工廠” 核心功能長啥樣

• 資料來源管理： 新建資料來源，目前支援 mysql，kafka，mq

新建 kafka 資料來源

新建 MQ 資料來源

新建 Mysql 資料來源：

在資料來源管理頁面中你可以建立、編輯、查詢你造數流程中會使用到資料來源。

• 通用資料抽象：變數管理 變數採用 json 格式進行編寫，儲存，方便在造數過程中的使用

新建/編輯變數：

我們使用 codemirror6 的元件編寫 json 的編輯器，並且在編輯器中提供了一些使用函式

函式在編輯器中會自行提醒並補全

有時候，一個變數 json 內容會非常多，在當前看到編輯器中編寫不是很方便，因此我們提供一個放大功能，就是標題旁邊那個藍色的小按鈕

在當前這個純淨的編輯視窗中編寫就會非常的舒服啦

• 造數邏輯編寫、組織能力 #### 新建訊息模板

訊息模板採用 JSON 格式進行編寫，主要針對業務系統透過訊息通道（KAFKA，MQ）接收上游業務系統推數後產生業務資料的造數。這樣在測試過程中，就不需要依賴上游業務系統的推送，我們自己按照約定編寫業務訊息，進行推數驗證我們自己業務系統處理訊息的業務邏輯就行。

訊息模板列表頁面

透過訊息模板的列表頁面對存量的訊息模板進行維護

新建資料模板

處理針對訊息佇列的訊息模板外，我們還提供了針對 Mysql、ClickHouse 的資料模板

在一個資料模板中，可以有多個步驟：

透過新增按鈕新增步驟，刪除按鈕刪除步驟；

每個步驟都對應一個資料來源，因為一個功能依賴的資料可能來自不同的資料來源；

每個步驟都可以擁有他自己的變數，可以是多個。

在資料模板中使用變數

先為當前步驟選擇變數，再編寫 SQL 語句的時候可以直接引用

編寫 SQL 的時候，變數的內容不需要手動編寫，編輯器會為你做程式碼提示

同樣 SQL 的編輯器也提供了純淨編寫的功能，並且兩個不同的編寫器的內容相互同步

• 造數過程中中間資料記錄和傳遞能力 在資料模板中使用上下文，在造數過程中，下一個步驟可能會使用到上一個步驟產生的內容，因此我們設計了給步驟新增上下文的功能，當前步驟產生的結果資料會存放在指定的上下文中，後續的步驟可以到指定的地方獲取上下文中需要的資料。

• 造數過程拼搭能力 一個造數過程可以是多個資料模板和多個訊息模板組成，因此我們抽象除了，工人和生產線的概念，在這兩個概念上，資料模板和訊息模板就變成具體的工作內容，而模板中的步驟則變成了具體的工作細節。

在一個工人中可以設定多個資料模板，他們的序號就是他們工作的順序，模板中的上下文作用域只能在當前模板中，不能跨模板使用。

同理一個生產線中也可以有多個工人，他們的需要就是工人之間的工作順序。

這樣透過在工人中設定資料模板和訊息模板，在生產線中設定工人並實現了造數過程中的拼搭能力。

綜上所述，我們可以看到整個造數過程中資料結構的層級關係是：

所以按照上述內容，為了使你的造數可用性，複用性更高，應該儘量做到以下幾點：

1. 儘可能的將通用資料抽象成變數維護
2. 資料模板和訊息模板中的步驟儘可能的不要太多，方便模板在不同工人中的複用
3. 工人中的資料模板和訊息模板儘可能的不要太多，方便工人在不同生產線中的複用

當前在專案中的落地情況

因為我們業務系統屬於資料密集型系統，無論是後端和前端在開發環境中聯調，還是測試執行過程中的提效，自動化測試中場景的構建，對造數工廠都有強烈的需求。目前在專案中已經使用起來，切實幫助測試解決了很大的問題，提升了測試效率，特別是資料模板和訊息模板積累起來後，使用效率和帶來的效果越來越大。

後續功能：

1. 資料模板中，將訊息模板，ClickHouse 打通，在一個訊息模板中往 Mysql 中造數的同時也可以往訊息佇列中傳送訊息，也可以往 ClickHouse 中造數。在一個資料模板中支援多種資料來源。
2. 上下文可以跨資料模板使用。
3. 新增工作空間，不同的登入使用者具備自己的工作空間。