SOA,测试人员的噩梦?
对于IT人员来说, SOA 已经不仅仅是一种 技术 ,它代表了一种新的,更加宏观的设计和实施IT系统的方法论。那么对于整个IT系统的实施过程来说,每一个步骤都按照SOA的角度来考虑,来实施就成为了SOA项目实施过程中的重点和难点。 接口 开发 的发展促成了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)阶段更大的,更具破坏性的风险。
原文转自:http://www.ltesting.net