SOA服务测试??测试人员的黑洞？
对于IT人员来说，SOA已经不仅仅是一种技术，它代表了一种新的，更加宏观的设计和实施IT系统的方法论。那么对于整个IT系统的实施过程来说，每一个步骤都按照SOA的角度来考虑，来实施成为了SOA项目实施过程中的重点和难点。
接口开发的发展促成了SOA的发展，SOA的诸多优势之中接口规范的标准化是比较突出的一个。从EAI发展到SOA 的ESB，从各种不同的接口标准一统的Web Service，我们看到接口开发的演进过程，标准化、规范化的过程。
在SOA这种新的架构和设计思想下，接口合约(Interface contract)成为约束服务提供方和服务消费方的手段。对于开发人员来讲合约会转换为WSDL或者IDL这样的定义文件。有了这样的定义文件，提供方和消费方的开发人员可以并行的开发。在这种新的开发方式，大量的服务可以有效的复用，开发的效率和开发的服务都可以有效的扩展;在这种方式下，可以把某些任务分配另外的公司和合作伙伴。从这种方式来讲，SOA也方便了软件的外包和离岸开发。
然而，中国有句老话叫"兴一利必生一弊"，这种开发模式下对于测试人员来讲会有新的挑战。
首先，通过接口合约分配给不同开发商的服务，这些开发商内部如何有有效的机制来保证开发接口的质量和对于服务规范(SLA)的满足程度。
第二，在服务组装阶段(一个典型的例子是BPM的流程的开发会有这样的阶段)，如何有效的保证测试的顺利进行。
第一个阶段，服务开发阶段的功能测试(接口测试)。
有EAI系统或者接口系统开发经验的人都有知道接口的测试是一个比较繁琐和效率低下的过程。SOA规范了接口算是改进了一大步，但是它也没有解决接口测试的根本问题。对于开发和管理者来说，在集成测试之前，保证每个服务的功能测试都是很痛苦的，需要大量的工作。但是对于基于SOA的设计和实现来说，这么做会屏蔽组装(Assembly)阶段更大的，更具破坏性的风险。
我们知道接口合约在现实项目中往往是word文档或者excel格式的文档。对于很多技术实现的细节并没有描述，比较理想的情况下是有比较准确和细化的接口定义文件WSDL。在有了WSDL文件的基础上，我们可以制作一些服务的simulator或者客户端的simulator来模拟服务的调用和执行，但是如何有效的覆盖到所有的业务逻辑，需要测试人员和业务需求人员科学严谨的工作了。
接口开发有个金科玉律，不要把问题留集成测试。问题越早发现越好。
第二个阶段，服务的集成测试阶段(System Integration Test或Assembling Test)
在 IBM对于SOA的实施过程的方法论描述中，有一个叫做Assemble的阶段。这个阶段对于Service Testing有着详细的描述。但是在我看来，这些描述反应的问题是对于真实的商业环境来讲对于SLA的理解是这个阶段测试的重点。
这个阶段还会涉及到各个厂商的协同测试，因为对于跨多个公司开发服务的集成测试来讲，如何协调这些不同的组织，或者说利用什么样的工具和手段提高集成测试的效率，也是现阶段各个厂商和大的集成公司在相关的SOA文档和规范中没有涉及的。因此对于测试人员来说，细节的工作不好做，也缺乏整体的方法论指导的情况下，如何不能说测试人员会进入一个SOA测试的黑洞呢?
我正在参与一个基于SOA的集成项目，希望能在实践过程中找到这个问题的答案，也希望有机会与大家一起分享我的经验。
