近年来，面向服务的架构（SOA）作为一种重要的架构一直受到很多关注。许多企业已经开始研究面向服务的解决方案，用来提高生产环境中的服务质量。

　　SOA带来了新的技术上的复杂与挑战，也使测试成为开发周期中的关键环节。开发团队需要考虑以下问题：

　　·如何知道方案是否已准备好？

　　·如何知道方案能否根据需求调整？

　　·如何知道是否可以从SOA方案中获得预期的业务灵活性？

　　这些都是测试SOA解决方案时需要解决的问题，但是许多测试团队还没有足够的经验来面对SOA解决方案的测试。

　　本文提供一些建议，用来帮助解决测试SOA解决方案时出现的问题。这些建议都是笔者过去三年里参与SOA项目的经验积累。

　　本文的主要目的是介绍经验和提出建议，不过在此之前，我们先从总体上介绍一下SOA的概念和测试团队面临的挑战。

　　SOA解决方案

　　在测试之前，应该先弄清楚SOA解决方案的框架。

　　一般来讲，SOA解决方案包含一系列由业务流程组成的服务，这些业务流程通过中间件实现。服务可能由其它服务组成，也可能是基本的服务单元。

　　这些服务可被客户端调用，包括portal应用的portlets组件，或者B2B解决方案的外部应用。这些服务可能会按照某种顺序被调用，比如根据（转移）判定（循环）回到前一步骤等，调用过程中可能还需要向使用人员提交任务，并等待处理结果。

　　服务实际上是IT资产的外部表现。IT资产可以是现有系统的一部分，也可以是根据特定需求创建的服务组件。 这些组件或是根据需要新创建的，或已提供对现有运营系统的访问，都是实现服务的基础。通常应该在服务与系统间嵌入服务组件，而不要直接从服务访问系统。

　　除了这些服务和实现组件，SOA解决方案还包括服务与组件的集成、服务质量、信息管理与治理等方面的内容。

　　测试SOA解决方案

　　SOA解决方案的测试目标与传统非SOA方案的测试目标相同，但SOA测试对测试人员有着更高的技术要求。同时，SOA测试对测试人员如何开始测试，以及测试使用的工具也有着不同的要求。SOA解决方案可能在各个层次上影响到测试属性的特征，所以除传统层次上的单元测试、集成测试等之外，SOA测试还需要考虑到两个新的层次：

　　·对外部服务层的测试；

　　·对调用服务的业务流程的测试。

　　测试SOA解决方案还有以下的特殊之处：

　　·可以独立地对服务频繁进行开发、转变，并实现可重用性，但服务必须能提供整体解决方案所需的功能。即使服务已经通过单元测试，并可以独立正常运行，当在系统中与其它组件交互时，仍可能产生一些集成测试方面的问题。

　　·服务可能没有图形界面（GUI-less），测试人员必须具备可以在这种情况下调用并测试服务的机制。

　　·用不同技术实现的服务，产生的问题也不同。

　　·使用第三方开发的服务包将带来一些特殊问题，开发团队也不能自由管理服务包的设计与实现。

　　·由于SOA解决方案是由各种服务组成的，因此需要认真考虑服务需求和问题判定方面的要求。

　　·由于异构环境下的各种服务必须协同运作，因此必须有严格的标准。

　　·SOA测试人员必须了解各种标准与技术。

　　·实际可用的服务组合肯定远远超出团队的测试能力，必须确定有限资源情况下的测试覆盖度。建议进行风险可控的测试。

　　·由于服务设计上的易用性，可能会被非预期程序或客户端调用，因此服务必须被完全封装并准确运行。

　　·要充分考虑性能特征。如果服务被设计为初始载入时每秒调用10次，之后每秒可以调用100次的模式，当其它客户端发现并尝试使用服务时会有什么后果？特别是当负载超出预设范围时，有没有有效的管理超载机制？

　　·各服务器端可能有不同的安全机制，包括不同的访问与使用规则，测试经理必须确定只提供给定业务流程对服务的访问。

　　所有这些软件系统中存在的问题都给测试团队带来极大的挑战。SOA项目中存在的这些问题的严重程度与解决难度，便是SOA测试与其它测试的区别。下面提供一些解决这些问题的建议。

　　解决SOA测试问题的建议

　　根据过去三年在SOA项目中的经验，我们为SOA测试团队总结了以下建议。这些建议并不是用来取代良好的测试设计、开发与执行流程，而是测试团队在复杂项目中应该做到的。

　　及早建立测试环境

　　仅仅测试服务的交付能力（即功能测试）是不够的。SOA方案中有新的软件层。包括：

　　·企业服务总线（ESB）

　　·业务流程编排引擎

　　可能还包括外部的安全子系统、入口子系统、Web服务网关和主数据子系统。确定基本的测试环境，保证对方案的测试不会变成对环境的测试，尽早建立并验证测试环境可以最大程度地减少这种问题。

　　渐增测试方案

　　SOA方案是建立在服务与服务编排的基础之上。瀑布模型会让开发陷入僵局，因为这种模型不能及时发现问题所在。应该及时对新服务和编排进行测试，这样才能及时进行调整并将问题反馈回开发团队，便于开发团队改进开发流程与方法。

　　项目早期要测试至少一到两项端对端的服务

　　建立好测试环境后，应该马上对其进行验证。最好的验证方法是测试一到两项涉及环境所有主要因素的服务。这有利于测试人员掌握测试环境，并且可以确定环境能否正常运行，而没有任何错误的假设条件。

　　用模拟服务“打桩”，以保证对方案的其它部分进行测试

　　由于测试初期有许多不可用因素，应该尽量利用桩（stub）来实现早期测试。要确保对桩的追踪，并在项目尾期将其移除。

　　测试团队的知识准备

　　SOA方案可能不仅对部分架构与开发人员有新技术和知识上的要求，对测试团队也同样有类似要求，因此要随时做好学习的准备。

　　使用工具支持测试流程

　　测试SOA方案很复杂。随着测试方案中服务的增多，或业务流程编排的变化，需要设计更多的测试用例。使用测试工具可以大大提高测试效率，同时减少测试中可能出现的错误，提高测试结果的质量。

　　及早验证服务模型

　　根据业务分析与方案架构开发的服务模型是SOA方案的核心。及早验证服务模型可以确保方案的正确性。

　　及早开发方案的性能模型，包括服务的性能预算

　　因为性能涉及许多软件层和服务编排上的问题，如处理不当可能会导致无法预料的后果。设计方案时及早根据需求建立性能模型有助于确定需特别注意的区域。并且，方案中各种元素的性能预算（执行给定操作的可用时间）有助于开发人员与测试人员将注意力集中到问题区域，即超出预算的地方，而不是让性能工程师在整个方案中漫无目的地寻找问题所在。

　　服务质量目标的测试

　　SOA方案的服务质量目标可以用SOA方案中的系统管理软件进行测试。

　　采用基于风险的测试方法

　　和所有大型项目一样，我们可能没有无限的时间和资源进行测试。这意味着我们必须将测试的注意力集中到方案中最重要的部分。为实现这个目的，最好的方法是依据复杂性、故障影响力和调用频率等对方案进行风险评估。然后根据风险评估的结果，按照优先级进行测试。

　　设计服务测试方案时无需考虑底层的实现技术细节

　　服务是IT组件的外部表现。客户端不受IT组件变化的影响是SOA的原则之一。测试服务时不考虑实现细节可以验证这一原则。

　　测试服务的可重用性

　　服务是本着易用及可被多个客户端使用的原则设计的。因此，测试人员应该考虑验证服务的可重用性。

　　注意测试外部服务

　　许多SOA解决方案使用来自其它企业的服务。及早对这些服务进行测试，以确保其运行正常，可以有效减少项目开发过程中的不确定性与过失。

　　除服务外，还要考虑对业务流程的测试

　　SOA解决方案比传统方案为IT项目带来更多关于流程设计与开发上的问题。这意味着不仅要测试基础的服务与IT组件，还要对流程进行测试。测试应该使用过程模型，描述系统的预期行为作为参考。许多过程模拟工具都有模拟机制，可以提供流程测试的信息，并支持流程测试。

　　除服务/流程测试外还要考虑中介类的测试

　　企业服务总线中的中介类在SOA解决方案中扮演着极为重要的角色。这意味着测试时需要确定中介类能否正常工作。测试人员必须确定诸如动态选择和转换等功能在各种情况下都能正常运行。

　　总结

　　我们阐明了SOA测试中的一些重要问题，并重点提出测试SOA解决方案面临的新挑战。希望这些建议能为初次测试SOA解决方案的团队提供帮助。