今天，給大家介紹如何進行自動化測試框架的設計。這裡所說的框架，是建立在一些主流類庫、框架或工具的基礎上的，自行研發的、適合公司的自動化測試資產。
如今有很多UnitTest測試框架，已經提供了資料驅動、使用者併發、斷言、報告等優異的特性，完全可以被用來進行單元測試之外的功能、效能、介面等方面的測試，建議大家可以基於他們來實現。
這裡給出我們建議的、自動化測試框架的分層結構，下面將圍繞此給大家逐一做介紹。
測試用例指令碼
在此實現業務的自動化測試，這一層面的指令碼同手工測試用例具有最直接的對應關係。
公共業務指令碼
一些提取出的、可在業務層面複用的函式、類庫或指令碼。比如網上購物系統的登入、加購物車、下單、付款等常用的業務操作。也可包括一些應用系統層面、或有安全限制的Knowledge Base的實現，如筆者曾經在測試電子支付系統時使用的、向全球央行打款的命令列工具，其由公司核心人員開發，執行於安全性極高的隔離環境中。
指令碼解析
用於解析類似關鍵字驅動（Data Driver）、自然語言理解（NLU）等更高形式的測試指令碼，將其轉換成某種程式語言的可執行程式碼。如解析QTP關鍵字檢視的指令碼到VBScript程式碼，轉換RobotFramework自定義關鍵字的指令碼到Python3程式碼的過程。
資料管理
實現自動化測試的資料管理和資料驅動。比如，大家習慣用Excel維護二維的表格資料，在指令碼中讀取後再迭代引用；也可以類似前一篇文章中的例子，為資料檔案或ZenData資料介面編寫DataProvider，然後在指令碼中使用Java標註的形式，將資料迴圈、逐條地”餵給“業務測試方法。
執行排程
分散式測試框架中，用於控制測試執行發生在什麼樣的系統、裝置或節點等環境上。可以類似Jenkins的代理，執行測試於不同的遠端機器中；也可以類似禪道的ZAgent開源專案，執行測試於指定特徵的虛擬機器、容器或手機裝置中。
結果斷言
通常是對一些主流測試框架的斷言和日誌特性做封裝，使其用起來更方便、更適合公司的業務。比如，在用例做驗證點檢查的同時，列印、朝資料庫儲存、向日志系統推送指定格式的、更為詳盡的訊息，以利於後續的統計分析。
日誌訊息
除了上述斷言有關的、驗證點檢查所輸出的 期待結果、實際結果、通過與否等資訊，也可以包括：基於UI的自動化測試中、每個步驟的控制元件定位結果、操作結果；基於協議的介面測試中，請求、響應的訊息和狀態，如此等等各類有益於排錯和分析的日誌。
統計分析
對測試步驟、檢查點、用例、測試集、執行計劃等各個層面的輸出結果做採集和分析，生成完整的自動化測試統計報告。
測試資產管理
集中管理不同型別的測試資產，包括物理伺服器、虛擬測試機、手機或嵌入式裝置，甚至是AI測試中的 語音識別（ASR）語料、自然語言理解（NLU）說法、人臉識別的相簿。
基礎工具類庫
一些常用的、特定程式語言層面的類庫。如字串處理、檔案解析、協議請求、訊息傳送等等。
基礎框架和工具
基於的第三方自動化測試類庫、框架或工具。如上文提及的JUnit、TestNG、Selenium、Appium、JMeter、QTP等優秀的開源和商業專案。大部分時候，我們不需要重複去造基礎的輪子。
以上所述的模組和功能，算是囊括了一個自動化測試平臺的方方面面。實際工作中，大家可以按需、逐步的進行實踐，適合的永遠是最好的。