使用 J2EE 和 STAF/STAX 實現全生命周期的自動化回歸測試

　　總體設計

　　該框架使用了 MVC 的設計思想，采用 J2EE 的 web 技術作為表現層，使用 Struts 這個流行的 JAVA 框架作為控制層，采用 hibernate 與 JDBC 相結合的方法處理數據持久化，主要的工作放在邏輯層，包括對回歸測試 request 的任務分析，生成 Configuration 列表，Configuration 運行期的任務調度，多線程的 Configuration 測試流程以及每個 Configuration 的自動執行。

　　測試框架采用 IBM Websphere Application Server 作為服務器容器，采用 IBM DB2 作為數據庫產品，采用由 IBM 開發的軟件測試自動化框架(Software Testing Automation Framework，簡稱 STAF)以及其執行引擎(STAf eXecution engine，簡稱 STAX)作為框架內部的分布式調用平臺。

　　圖 1. 體系結構圖

　　項目拓撲結構

　　本測試框架應用于 DB2 JCC 的測試場景中，需要一臺應用服務器作為框架的支撐，一臺數據庫服務器作為數據持久化的容器，這兩者可以使用同一臺服務器。在具體測試時，還需要若干臺 DB2 Server 和 DB2 Client，都可以由虛擬機來構建，以達到最優化測試資源配置和自動化的目的。同時，還需要一些項目相關的資源，如存放測試軟件安裝程序的 FTP 站點(這里以 DB2 為例)等。

　　圖 2. 項目拓撲圖

　　回頁首

　　前臺設計與實現

　　基于 Struts 的表現層 mvc 設計

　　Struts 是一個 JAVA 世界非常流行的表現層 MVC 框架，對于 web 開發表現層的各個方面都有很好的細節處理，如表單驗證、請求分發等。我們的測試框架便采用了 Struts，下面給出一個測試請求的提交頁面，用戶可以定制自己測試的屬性，選擇測試版本、期望報告時間等，易于使用。

　　圖 3. 測試任務提交頁面

　　使用 Filter 控制用戶權限

　　我們的測試框架面對的用戶主要有多種角色。以開發人員和測試人員為例，開發人員通過 web 提交任務，并進行一些任務信息的管理和查看;測試人員權限更大一些，需要能完全掌握整個系統的運行狀況，在有必要的時候進行人工干預。因此，系統需要對用戶進行權限控制。

　　Servlets Filter 是 Servlet 2.3 規范中新增加的，它是截取用戶從客戶端提交的請求，在還沒有到達需要訪問的資源時運行的一個類。它操縱來自客戶端的請求，在資源還沒有發送到客戶端前截取響應，并處理這些響應。

　　因此，Filter 非常適合做用戶權限的控制和過濾。項目中使用了兩個 Filter，一個用于登錄的驗證，在 Filter 中檢查 Session 的狀態，控制用戶登錄情況。另一個用于權限的驗證，通過給用戶的角色分配不同權限的 URL 列表，在 Filter 中進行 URL 的檢查，可以達到控制權限的目的。

　　結合 JDBC 和 Hibernate 實現數據層持久化

　　Hibernate 是一個開放源代碼的對象關系映射框架，它對 JDBC 進行了非常輕量級的對象封裝，使得 Java 程序員可以隨心所欲的使用對象編程思維來操縱數據庫。Hibernate 內容簡單，十分靈活，但數據持久化的效率比 JDBC 要低。如果 JDBC 的代碼寫的非常優化，那么 JDBC 架構運行效率最高，但也會帶來大量重復的數據庫編程。

　　結合上述的特點，我們采取的策略是：使用 Hibernate 作為 OR 映射的框架，這能大大加快開發進度;在對性能要求較高的場合，例如測試資源匹配、狀態監控等，使用 JDBC SQL 來操作，當然 JDBC 的 Sesstion 是通過 Hibernate 來獲取的。

　　回頁首

　　控制層的并發處理

　　Test Configuration 的工廠實現

　　用戶提交的測試任務可能是較為復雜，并不是實際測試中的測試執行單元，實際測試的資源分配是根據最小測試執行單元的。我們的框架需要能分析任務的復雜程度，并依據測試規則將其分解成我們需要的最小執行單元。

　　我們的框架中實現了一個 Configuration 工廠，這個工廠能夠對用戶測試請求進行解析，主要包含兩個方面：一，對測試任務進行 Configuration 的分解;二、排除不符合測試規則的無效因素。最后生成一個 Configuration 的列表。

　　圖 4. Configuration 解析列表頁面

　　基于 FCFS 和修正優先級的 Configuration 調度

　　我們的框架主要是面向測試人員和開發人員，即使訪問量不是很大，但是受限于測試所需要的各種測試資源，仍然需要一個 Configuration 調度程序來管理，以實現盡可能的多任務的并發和盡可能高的資源利用率。

　　當一個測試任務到來的時候，依據測試任務的復雜度和測試結果提交日期的緊迫程度，系統會為測試任務分配一個優先級;如果優先級相等，依據 FCFS(先來先服務)規則進行測試資源的匹配。同時，系統會維護一個 Configuration 等待隊列，用于存放暫時無法得到運行的 Configuration。這個隊列中 Configuration 的優先級是不斷動態修正的，例如，當一個 Configuration 匹配測試資源成功得到運行后，與其同組的 Configuration 的優先級會被調低，以達到測試資源的平均分配。

　　基于 Multi-thread 的 Kickoff

　　每一個獲得測試資源得到執行的 Configuration 都必須在一個單獨的線程里執行，這是毋庸置疑的，否則無法實現并發的執行任務。執行線程需要處理一個 Configuration 測試過程中所有步驟，比如準備測試環境、下載 Build、準備驅動程序等。其中很多個步驟都是需要花較長時間，在這段時間內，沒有理由讓線程仍然占用 CPU 資源。

　　我們在系統中維護一個資源鎖列表，每一個資源鎖對應一個線程。當線程發出一個需要較長時間才能返回的 STAF 命令時，線程會釋放相應的鎖，處于資源阻塞狀態;當命令執行完成后，會異步的更新鎖狀態，同時返回執行的結果信息。然后 Configuration 執行線程得到執行，讀取返回的結果信息，判斷是否繼續走下一步的測試步驟。

原文轉自：http://www.anti-gravitydesign.com