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

　　SOA——例子

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

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

• 　　成员登录和目录浏览
• 　　非成员登录和目录浏览
• 　　成员登录和目录购买
• 　　非成员登录和成员资格应用

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

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

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

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

　　SOA——单线程

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

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

　　SOA——多线程

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

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