SOA性能测试的重点是验证面向服务架构（SOA）方案在预期负载下能否满足业务对性能的要求。SOA压力测试的重点是确定SOA方案在它失败前所能承受的负载量——这里失败的定义是没有能力来满足一项或更多性能要求。

　　SOA——例子

　　在SOA测试中我们提供过一个简单的SOA方案：我们看过一个简单而又非常“粗”（大而复杂的服务）的SOA应用场景的例子。那个SOA方案满足了在线销售数字媒体的需要。服务层由具有Web功能的展现层、客户账户服务、目录服务、购物车服务、数字实现服务、客户历史服务和充当标准金融服务数据库的接口角色的账户服务。下面这个图表展示了SOA方案，我们将继续在它的基础上来作为讨论SOA性能和压力测试。

　　我们将使用一组简单的业务事件集来满足SOA性能和压力测试，这些事件代表这个SOA方案在真实的一天中发生的典型事件。在这种情况下我们将处理下面这些问题：

　　成员登录和目录浏览

　　非成员登录和目录浏览

　　成员登录和目录购买

　　非成员登录和成员资格应用

　　很显然还有更多的业务事件，或线程来补充这个应用场景，但是就讨论目的而言，对我们已经足够了。

　　SOA——性能和压力测试计划

　　性能或压力/负载测试要求团队对系统有深入了解：硬件、软件、固件、协议、事务和业务。除非容量测试对工程/系统的所有者而言是正在进行的操作， 这种类型的内行不会在一个组织内存在。测试经理必须和他的同事在操作、开发、测试和任何第三方IT提供者一起工作，使团队团结起来，能够处理系统的各个方面。这和其他性能和压力测试的约束没什么区别，但由于SOA应用场景分散的性质，是否存在有效的测试计划很关键。

　　SOA方案的复杂程度和流动的性质要求性能/压力测试团队采取一种演变方式来测试，从单线程到多线程，并最终到真实的一天中的性能/压力测试。不同于更多的传统应用场景，应该变成不断演变的，支持重复的性能测试方案。那是因为在当前的SOA方案场景内起作用而对方案的下次迭代却不起作用。记住，这是个不断演化的方案集。

　　SOA——单线程

　　SOA应用场景的挑战之一所产生的影响是使方案分散的性质。一个简化初始性能和压力测试成果的方法是处理每个业务事件或独立的业务线程——单线程方法。不推荐到性能/压力测试成果的地步，但在整个应用场景准备好以前，它没有使组织验证服务的稳定性和健壮性，还极大地简化了监视和故障检修。这相当于在性能/压力测试的透视下的单元和集成测试。危险现在变成了可能发生的互相作用和与业务事件无关的互相依赖。

　　对于性能/压力测试方案整体而言，这些单线程场景应该成为独立的组件——基本上是性能测试工具的一个模块集，能快速适应业务事件的任意组合。

　　SOA——多线程

　　一旦性能/压力测试团队验证了一系列相关的单线程以及对已发生的应用场景的任意调整，那么多线程性能和压力测试就可以开始了。多线程方法假设处于某个级别的单线程测试已经发生，从监视和负载的透视中才可能运用适当的工具，并已鉴定过相关的业务线程。团队选择跨越多个共同服务的业务线程，执行起活动来却是松耦合的。

　　举个例子，客户历史服务既跟踪临时的目录浏览（非购买事件）和目录购买（购买事件）。现在，在SOA应用场景和支持应用场景的任意调整中，团队能决定松耦合活动带来的普遍影响。再次重申，组件在变成有效的工具箱的过程中，你可以把每个场景当作独立的组件，这些工具箱又能快速地适应衡量业务事件的任意组合（期望的和非期望的）的任务。

　　SOA——真实的一天

　　这是典型的性能/压力测试在架构上期望业务映射样子和模拟负载的演练。在模拟期间，性能/压力测试团队——在一些相关者的帮助下——衡量在负载条件下架构的性能。

　　在SOA方案的背景下，决定性能失败的根源变得非常困难。事实上，如果早期单线程和多线程性能测试还没有发生的情况下，它是不可能失败的。通过建立起一个工具(场景)的模块集，团队能更轻松地适应SOA方案快速变化的各个方面。基本上，在快速演变的SOA应用场景的背景下，过去能被用于集中化应用的“整套”方案将变得无法操作。

　　SOA——第三方服务

　　在SOA应用空间中一个巨大的挑战是使用第三方服务的能力，并因此它受到诟病。在性能/压力测试的透视下，可以当成最容易出现问题的区域来测试。怎样在24/7范畴的生产环境下访问并测试一个服务？简短的回答是你无法做到，但组织能采取措施来减少或使性能失败的影响在第三方服务的一边显现出来。

　　首先，任何第三方服务不应该是关键任务。如果它们确实如此，就必须被服务层协定（SLA）所支持，SLA支持性能/压力测试的良好文档集。非关键第三方服务应该被这样的一种方式访问，就是及时地以一个引起失败细节的方式响应，这种方式应该不严重影响用户体验。这个功能应该在性能场景下测试，由这个场景虚设那个服务。

　　最终，尽管你不能直接测试第三方服务，你还可以用服务提供者的合作来测试第三方服务。如果提供者不愿意或不能合作，你的组织将考虑找到一个可替换的提供者。

　　SOA——结论

　　这个不断进化的SOA应用场景帮助满足今天复杂业务方案的需要和竞争激烈的上市时间的需要。它也为专业测试者呈现出新的挑战。尽管对那个挑战而言没有单一的解决方案，但是有很多可提供帮助的实践。

　　等待处理测试挑战的这些天到了最后时刻，在它接近尾声的时候抛砖引玉。对测试需求采取支持测试的弹性和测试制品的重用，取代一个有条理的（有方法的）、以需求为中心的和工具使能的方式。

  　关于作者：David W. Johnson是一位在多个行业的信息技术方面有超过20年经验的高级计算机系统分析师。他在业务需求分析、软件设计、软件开发、测试、培训、实施组织评估和业务方案的支持方面扮演过重要角色。David已经在过去的12年中开发过很多特别的专业技术，实现了“TestWare”，包括测试策略、测试计划、测试自动化和测试管理方案。你可以通过DavidWJohnson@Eastlink.ca联系到David。