1.什么是測試架構

從基本的觀點看，測試架構師由軟件系統技術架構和軟件測試結構構建的需求而定。

2.測試領域架構

2.1.功能測試

(1).在功能測試中，不僅要完成業務邏輯的驗證，還要進行用戶界面和輸入空間的驗證。我們常用的黑盒測試中的等價類、邊界值、決策表、因果圖等方法，實際上都只是功能測試的冰山一角，僅為對輸入空間的驗證。

(2).在功能測試中，不光要進行不同層次的測試，還要針對不同空間或領域進行相應的測試。如下圖所示：

圖1 不同視角看功能測試

(3).功能測試架構圖：

圖2 功能測試架構示意圖

備注：有限狀態機(FSM)，形式規格說明(ForS)，功能規格說明(FunS)

2.2.非功能測試

(1).非功能測試可以看做兩部分組成，一是設計驗證，二是系統驗證。

圖3 非功能測試架構

3.自動化測試架構之說

3.1.良好的自動化測試框架應該具有的特點：

(1).提供非常有效的測試工作流程模型

我的理解，就是一套完整的測試流程，從測試任務的準備、執行、測試報告。一套流程的元素都應該具備。

(2).支持多種腳本語言的錄制、編輯、調試和回放等集成開發環境

(3).完成各類測試任務的執行

我的理解，選擇測試任務時應該是支持多選，且存在固定的測試集，如冒煙測試場景集、回歸測試場景集，前者是提供執行者按需選擇執行模塊(次數每個模塊應該相互獨立，才能方便自由組合)，后者是為了滿足快速測試。

(4).有良好的擴充能力，如和第三方插件、工具的集成

我的理解，比如第三方監控工具，可以在開始測試任務時開啟，做到測試過程資源監控。

(5).具有數據驅動、關鍵字驅動等腳本模式的支持

(6).具有分布式處理、遠程調用的不同的運行方式

(7).能獲取測試覆蓋率。

我的理解，該出應該體現在測試報告中，包含總體測試覆蓋情況(測試累計時長、測試模塊)，單一模塊執行情況(執行時長、檢查點通過情況、失敗檢查點有失敗結果)等

3.2.公用的對象、方法、環境或數據因素處理

(1).公用的對象。構建對象庫，封裝公用的對象，并建立實體對象和邏輯對象之間的映射。

(2).公用的方法。

我的理解，以上兩種的要求是盡可能多的封裝、公用。且利于維護。

(3).公用的環境或數據。將不同的測試環境或數據封裝起來，和測試用例靈活的組合，以增強腳本執行的靈活性。?

我的理解，一般情況下，自動化測試平臺應該至少支持兩套環境(測試環境、生產環境)，例如接口測試，兩套環境需要準備IP、端口、頭文件。兩套環境應該都有封裝，在配置文件中決定使用哪套環境基數。

圖4 自動化測試框架示意圖

(1).綜合而管理平臺：統一的web發布頁面，管理所有環節

(2).腳本開發IDE：

我的理解，為關鍵字驅動的測試用例場景，此處編寫的測試用例，可直接被控制中心作為任務模塊子元素組合操作。

(3).任務安排：

我的理解，此處的任務就是一個組合執行過程，可包括立即執行、定時執行、加入執行隊列等待執行

(4).監控測試資源：在測試過程中，能夠及時發現問題，發出警告，并保留相關數據。

3.3 測試自動化框架的基本構成

圖5 自動化測試框架雛形

4.測試架構師

4.1 對軟件測試架構師的要求

(1).測試架構師是測試團隊的技術帶頭人，在系統非功能特性的測試、自動化測試框架等方面發揮著主導作用，對開發團隊具有很好的溝通能力和影響力。

(2).測試架構師應該具有較強的抽象能力和創新能力，通過一個全局的觀點、宏觀的視角來理解軟件系統作為一個整體是如何工作的，可以將具體問題抽象為一個模型，從而解決一類問題，并通過不斷創新，找到解決問題的新方法，推廣新的測試技術。同時，測試架構師作為測試技術帶頭人，就是為測試團隊梳理技術標桿，提供技術指導、做好技術決策。

4.2 測試架構師職責

圖6 測試架構師職責

4.3 測試架構師產物

圖7 測試架構師產物