SOA 組合業務服務的自動化測試：第 2 部分

SOA 的體系架構中很強調“分布式”這個概念，不僅是構架的分布式，開發模式也體現了“分布式”的概念，SOA 的開發團隊經常分布于全球不同的角落，比如：Service 層的開發位于中國、測試組位于中國、UI 層的開發位于美國。這種分布式的時區差異導致了如果美國出 Build 的時間是北京時間的凌晨 4：00，中國測試團隊每天早上上班的第一件事就是從美國的服務器中取下 Build 然后把它部署到服務器上，重復的勞動不僅耗費大量的人力物力，且由于 SOA 組件的配置比較復雜，手工配置很容易出錯，加大了測試團隊的風險。

除了開發和測試的分布式模式帶來的挑戰之外，由于 SOA 是一個基于服務的構架，服務粒度的細化導致在一個企業級 SOA 應用中會有大量的服務需要發布出來，可能導致的部署的 EAR 包比傳統構架的多，體系結構也比較復雜。有一個真實客戶的例子，在采用 SOA 構架后其 IT 架構包括如下幾部分：

• 50 個 Websphere 的集群 (cluster)，200 個應用服務器 (application server) 在 40 個節點 (node) 上。
• 整個應用程序包含 26 個 EAR 包在 11 個獨立的實例上 (instance)，這就意味這 11*26 的部署工作。
• 12 個 SIBus, 2 個 JMS queues，每個集群 (cluster) 一個數據源 (dada source)。

管理和配置這個復雜的環境無論對測試人員還是客戶來說都是一個噩夢，自動化部署不僅可以大大提高測試的工作效率、減少項目風險而且可以向客戶提供一種”one click”的解決方案，對客戶屏蔽諸多技術的細節和配置的復雜性，提高客戶對 SOA 技術的忠誠度。

本文將根據我們在項目中的經驗總結出一種每天按需求自動下載、部署、配置 Build 的自動化方案。

自動下載 SOA 組件

SOA 的分布式開發環境

下圖是一個很典型的 SOA 的開發和測試環境。

圖 2.1 典型的 SOA 開發環境 
 

在圖中所示的這種軟件開發環境中，Service 開發團隊和測試團隊位于中國，UI 開發團隊位于美國，Service 開發團隊和 UI 開發團隊都有自己的 Build Server，用于存放自己每天所發布的 Build，測試團隊有自己的一套 SOA 測試環境，它需要每天安裝和配置 SOA 的 Service 組件和 UI 組件用于測試。本章將介紹測試團隊如何在這種分布式環境中實現自動化測試。

自動獲取 Build

在當前的腳本語言中 Ant 和 Python 是最流行的兩種語言：Python 是一種非常靈活強大的動態腳本編程語言，具有完整的面向對象特性；Ant 是純 Java 語言編寫的，具有良好的跨平臺性，由于 Ant 的構建文件時以 XML 書寫，容易維護且結構清晰。我們將結合兩種語言各自的優點運用于我們的腳本之中。我們以 Windows 為例，整個自動化腳本的目錄結構如下所示：

圖 2.2 自動化腳本的目錄結構 
 

有幾個目錄需要重點介紹一下：

EAR：是我們存放下載后 Build 的路徑，他有兩個子目錄 service 和 UI 分別用于存放 SOA 的服務層和用戶界面層的 Build。

Lib: 存放應用程序所需要的共享庫，某些應用程序部署上后需要配置共享庫。

在 BuildScript 目錄下有一個 deployBuild.bat 文件，一個 buildToTest.py 文件。

圖 2.3 BuildScript 目錄下的文件 
 

deployBuild.bat 文件主要用于定義一些 WPS profile 的位置、Build 放置的位置、WPS 登錄用戶名和密碼等信息。

原文轉自：http://www.kjueaiud.com