SOA——多线程

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

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

　　SOA——真实的一天

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

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

　　SOA——第三方服务

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

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

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

　　SOA——结论

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

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