【IT168 技术文章】

　　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 组件用于测试。本章将介绍测试团队如何在这种分布式环境中实现自动化测试。