1. 什麼是自動化專案搭建
當一個軟體開發工程師接到一個新的Web專案開發的時候，往往需要完成一些準備工作，例如，選擇web框架，專案的目錄結構設計，資料庫的連線配置，Redis/Kafka連線和配置；甚至包括一些基礎功能的實現和封裝，例如 MySQL庫增刪查改操作的封裝，登入功能，以及登入token的驗證。這個過程通常稱為 專案初始化 或 專案搭建。
當我們的大部分專案都會用到這些基礎功能，我們會將這個搭建好的專案放到一個單獨的程式碼倉庫，當需要開發新的專案時就從從這個倉庫拉取程式碼，在這個專案程式碼的基礎上繼續開發。這專案通常被稱為 種子專案 或 模板專案。
每次從模板專案拉取程式碼，都需要手動修改 模板專案 的名稱，例如：將 template-project 改為 company-user-project 或 company-payment-project。甚至在使用 模板專案的時候，會有個性化的需求，company-user-project 需要使用MySQL資料庫，company-payment-project需要使用MongoDB資料庫，我們可以進一步實現腳手架工具。透過可選配置的方式生成個性化的 模板專案 ，這樣的工具我們通常稱為 腳手架工具。
圖：Spring initializr
自動化測試工程師在接到新需求時，也需要完成類似專案初始化的工作（例如選擇測試框架、設計目錄結構、整合測試報告，以及各種主流的測試庫等）。此外，也包括實現一些基礎用例或封裝一些通用操作，比如系統的註冊、登入用例，封裝隨機數的生成等等。毫無疑問，這個過程也被認為是 自動化專案搭建
當我們搭建好了自動化測試專案，同樣可以將其作為 模板專案 使用。然後，基於 模板專案，我們可以更加快速的編寫自動化測試用例。
為什麼要介紹這個概念，是因為網上看到大量的文章將 自動化測試專案搭建 叫做 自動化測試框架開發，這顯然是錯誤的認知，因為兩者的角度和目的是不同的。
-
自動化測試專案搭建： 服務於公司具體業務，為了更快速地編寫業務的測試用例。
-
自動化測試框架開發： 為了解決一類通用問題，開發設計的一種通用的能力，從而定義解決問題的方法和結構。
2. 為什麼設計自動化測試框架
開發框架的原因可以有多種角度，以下是比較常見的原因。
2.1 提高開發效率
現有框架可能存在以下問題：
- 現有框架使用過程中存在過多的第三方依賴，安裝和配置比較繁瑣。
- 使用複雜，測試工程師需要花費過多時間學習或適配。
透過開發更貼合需求的自動化測試框架，可以減少重複性勞動，提升開發效率。
2.2.滿足特定型別需求
現有框架存在無法滿足特定型別的業務的測試需求（例如，gRPC、Kafka的測試用例編寫），需要在現有框架的基礎上做更多的功能擴充套件和封裝。
透過開發功能更加強大的框架，更好的解決現有業務型別的自動化測試需求。
2.3 提供更優的設計理念
提供更優的設計理念或創新技術實現。
- 創新性設計：基於新的架構或設計模式提供更高效能、更易擴充套件的解決方案。
- 領域驅動：專注於某一特定領域（如關鍵字驅動，資料驅動、方法鏈）的最佳實踐。
2.4.提升團隊協作
規範團隊協作，提升開發體驗和程式碼一致性。
- 框架可以規範團隊的開發方式，減少個性化差異帶來的協作成本。
- 提供標準化的工具鏈、模組和流程，確保團隊程式碼質量和一致性。
3. 自動化測試框架設計的方向
當我們決定去設計自動化測試框架，那麼可以有兩個方向：從零開始設計 和 基於單元測試框架二次開發。
3.1 從零開始設計
從零開始設計自動化測試框架，例如針對一款的程式語言，單元測試框架一般需要作為基礎庫被設計並整合到程式語言中。
標準化的測試結構
單元測試框架提供了一種統一的結構化方式，讓開發者以一致的方式組織和執行測試。
-
生命週期方法: 通常框架會定義一套標準化的生命週期鉤子，用於在每個測試方法執行前後進行資源管理：
setup/beforeEach: 在每個測試執行之前初始化測試環境（如建立測試資料、例項化物件）。
teardown/afterEach: 在每個測試執行後清理資源（如關閉資料庫連線、刪除臨時檔案）。 -
測試方法的命名: 通常有特定約定，比如以
test_開頭（Python 的 unittest）或@Test註解（Java 的 JUnit）。 這種約定使得框架可以自動發現測試方法。 -
獨立性: 每個測試方法應保持獨立，不依賴其他測試。測試之間的隔離有助於更快定位問題。
斷言機制
斷言（Assertions）是單元測試的核心，用於驗證被測程式碼的行為是否符合預期。
斷言的作用:
- 透過對輸入和輸出的驗證，確保程式碼邏輯正確。
- 如果斷言失敗，測試會立即終止並報告錯誤。
測試發現
測試發現是單元測試框架的一項重要功能，能夠自動找到符合規範的測試。
框架會掃描特定的模組或資料夾，找到符合命名約定的方法。例如：在 Python 中，pytest 會自動發現以 test_ 開頭的方法。在 Java 的 JUnit 中，@Test 註解標識的方法會被識別為測試方法。
測試套件和測試執行器
測試套件和執行器使得開發者可以高效地組織和執行測試。
- 測試套件（Test Suite）
測試套件是一個集合，用於將多個測試用例組合在一起執行。方便地對一組相關的測試進行分組管理。
- 測試執行器（Test Runner）
測試執行器負責執行測試並收集測試結果。
測試報告和結果反饋
測試報告用於展示測試的執行結果，幫助開發者快速瞭解程式碼的健康狀態。測試結果分類
- 透過（Pass）: 測試正常完成且所有斷言成功。
- 失敗（Fail）: 測試未透過，某個斷言失敗。
- 錯誤（Error）: 測試執行過程中丟擲了未預期的異常。
- 跳過（Skip/Ignore）: 測試因某些條件未被執行。
擴充套件：xUnit 被認為是許多主流程式語言的單元測試框架的雛形和靈感來源。xUnit 是一種架構模式，最早由 Kent Beck 和 Erich Gamma 在 SUnit（Smalltalk 的單元測試框架）中提出，併成為了測試框架設計的標準。其設計思想和概念被廣泛應用到其他語言中，例如 JUnit（Java）、NUnit（.NET）、pytest（Python）等。
3.2 基於單元測試框架二次開發
基於單元測試框架二次開發，在單元測試框架的基礎上，更偏注重於擴充套件各種測試能力。
通常，單元測試框架已經提供了基礎的測試能力，為了更好的支撐各種型別的測試，我們可以在此基礎上進行擴充套件，以便於滿足不同型別的需求。
基於單元測試框架二次開發的方向比較多，取決於基於框架設計的定位和目標。以下是常見的擴充套件功能。
資料驅動
資料驅動是自動化測試最常見的功能之一，可以有效的減少樣例程式碼的編寫，從而提高測試用例編寫的效率。
- 資料驅動裝飾器
可以透過資料驅動裝飾器來驅動測試測試用例（方法）， 例如，Seldom框架的 @data([]) 裝飾器。
- 資料驅動檔案
透過取數驅動檔案讀取不同型別的資料檔案。例如，Seldom框架的@data_file("./data/file.json")管理測試資料。
定製化測試報告
測試報告是自動化測試框架的非常重要的功能，我們需要對報告做一些定製化開發。
- 個性化測試樣式和內容
例如顯示公司logo、人員個名稱和角色等。
- 生成不同的報告型別
不同的執行模式需要不同的報告型別。例如，本地執行需要HTML格式的報告，CI/CD 或平臺化執行需要XML、JSON格式的測試報告。
腳手架工具
整合腳手架工具，可以快速的生成 自動化測試專案模板。
關於自動化測試專案模板，文章的開頭已經介紹，這裡不再闡述。
整合訊息功能
每個公司都有自己的通訊工具，郵件、釘釘、企微、飛書等。 透過呼叫相關工具的API，實現發訊息功能，可以讓測試的執行結果更快的傳送給相關人員。
整合各種測試庫
基於框架的定位，可以整合不同型別的測試庫，並對這些庫進行二次開發，使框架的使用更加高效統一。
- Web UI測試
如果是為了實現Web UI自動化測試，那麼可以整合 Selenium、Playwright等測試庫，並對這些庫的API進行二次封裝。
- API 測試
如果是為支援介面測試，可以整合 Requests、webSocket、gRPC等測試庫，並對這些庫的API進行二次封裝。
- App UI測試
如果是為了實現App UI自動化測試，那麼可以整合 Appium、uiautomator2 等測試庫，並對這些庫的API進行二次封裝。
4. 自動化測試框架設計基本準則
4.1 獨立的名字和版本管理
我們應該把框架當成一個獨立的專案來進行開發、維護和升級。
框架的命名
首先，應該為框架起一個獨立的名字，既可以以某個動物或植物命名，比如，Python（蟒蛇）或Lettuce（生菜）；也可以按照框架的本意命名，比如， Robot Framework（自動化框架）或unittest（單元測試）；還可以是縮寫合成詞，比如，pytest = Python + Test、Appium = Application + Selenium等，關鍵是簡單好記。
版本號管理
其次，框架應該有自己的版本號，推薦使用GNU風格的版本號命名。
格式：主版本號.子版本號[.修正版本號[.編譯版本號]]
- 主版本號：重構版本。
- 子版本號：重大功能改進。
- 修正版本號：小升級或者bug修復。
- 編譯版本號：一般是編譯器在編譯過程中自動生成的，我們只定義其格式，並不進行人為的控制。
獨立的安裝
最後，框架應該提供獨立的安裝，比如，Python使用pip命令進行安裝。
對於開源的專案來說，例如，需要建立setup.py或pyproject.toml打包檔案，將專案打包成.whl格式的檔案，提交到pypi.org官方倉庫。
4.2 具備通用性
作為一款框架，其定位和目標一定是解決一類通用問題並提供能力。
例如： 資料驅動、自動化發郵件、生成隨機數、資料快取、命令列工具 這些都與具體公司業務無關，提供的是通用的能力。
4.3 清晰的定位和目標
自動化測試框架被設計的初衷一定是為更好的瞭解決某一類問題。在設計之初，我們應該有一個清晰的目標和定位。
從無到有地解決一類問題
xUnit在單元測試框架領域具有開創性意義。前文有對 xUnit 進行介紹。
更加簡單地解決一類問題
Flask是一個使用Python編寫的輕量級Web框架，透過它，我們可以只簡單地編寫幾行程式碼就搭建一個Web服務。
提供更加強大且豐富的功能
Django是一個開放原始碼的由Python編寫的Web框架。
Django雖然學習成本較高，但是它功能提供了 ORM（關係物件對映）、Admin管理系統、模板系統、Cache系統、表單處理、會話（session）、國際化等，這些功能幾乎都是開箱即用的，可以用來實現一個較為複雜的系統。
最後，當你要設計一個自動化測試框架的時候，不妨思考一下，設計目標是什麼？為了解決什麼問題？是否已經有更好的開源框架可以直接使用。
5. 相關書籍推薦
那麼，是否有一本書能講清楚 自動化測試框架設計 ?
答案是：《自動化測試框架設計》一書
本書由蟲師編著，作為 SeldomQA GitHub千星開源專案的開發者，在自動化測試框架設計、定製化測試報告設計、設計模式，以及測試平臺開發方面有著深厚技術積累和獨特的設計理念。
書中淺顯易懂的介紹了 SeldomQA 相關專案中的諸多設計和封裝技術。並且，介紹了一個開源自動化測試框架從設計到釋出的整個流程。
此外，書中還介紹瞭如何打通自動化框架和自動化測試平臺，這是一種獨特的技術方案，為自動化測試平臺提供了新的設計思路。
最後，結合當下熱門的AI技術，作者還介紹AI在自動化領域的探索方向。
