软件开发专家知道测试是开发与部署之间过渡的关键，部署一直以来都是软件项目的目标。要想测试面向服务架构(SOA)应用程序，就必须通过扩大单元测试、扩大负载测试的范围，分别测试编制、集成和基于组件结构的信息流来使三级测试过程适应SOA原则。

应用程序测试通常是三阶段流程。第一阶段流程，应用程序组件通过开发人员根据所制定的规范来确保它们的功能从而实现“单元测试”。第二阶段流程，这些组件被整合起来完成应用程序的开发，然后进行“系统测试”或“集成测试”以确保应用程序和功能关系间的工作流达到预期的要求。最后一阶段流程，对应用程序进行“负载测试”或“试点测试”来模拟实际的部署环境。SOA应用程序可以遵循相同的模式，但每个阶段都会有特殊规定，以适应特殊性质的基于组件的松耦合程序。

SOA松耦合要求程序组件具有“即服务”组件的功能来展示应用程序完整的运行过程。将SOA组件视为服务于单元测试的应用程序是十分重要的，这就意味着结合以上三阶段测试，并在每个SOA服务/组件运行这三个阶段。

服务接口是SOA组件测试的关键。通过描述生产服务的SOAP/WSDL确保单元测试以真正的服务形式对组件进行测试。用户报告称，基础软件测试经常会忽视服务接口，将其延迟到后期的集成测试，在安装前这种项目允许的延迟会积淀许多服务规范问题。适当的服务接口测试通常需要通过SOA/SOAP接口使测试生成器运作，从而确保在所有可能的条件中都可以进行测试。

考虑到这一点，我们在验证过程中添加了基础负载测试，以确保组件的性能可以满足总体目标。对一系列SOA组件进行性能测试会更加复杂，这是因为所有可能的路径都是难以核实的。如果每个组件分别进行负载测试，那么可以在不同情况下，通过为每个路径绘制工作流和总结延迟来预测应用程序的性能。这便可作为一个指标来比较实际的负载测试结果。

在SOA中，集成测试的目标是三个，而不是一个。SOA应用程序不同于普通的应用程序，因为它们通常在编制软件时引入一个新的组件，即应用于连接SOA组件的消息/服务总线技术。在许多SOA应用程序中，组件间的信息管理是由一个业务流程执行语言(BPEL)模板所控制，这同样是一个测试的新元素。只有当这两个“新”的元素经过测试后，才可以测试普通组件间的集成。事实上，“集成”测试并非组件测试而是优先于单元测试的测试系统，这说明了本文前面概论所说的提升组件验证标准的重要性。

至少应用程序架构师早期所开发的应用程序原型中，大多数SOA应用程序都有自己的BPEL。如果BPEL基础主路径和相关的数据都可以从该流程和单元测试中获取，那么他们就可以用来验证信息/服务总线编制软件的功能。确保BPEL能正确地驱动组件序列，及信息/服务总线软件与组件之间的接口是正确的，这非常重要的。这样组件就可以进行正确的访问，SOAP信息格式也可以重新测试;它们在基础水平的单元测试过程中也已经被验证过。当主测试完成时，二级逻辑路径可以通过相同的BPEL组件序列测试系统进行测试。

SOA应用程序中的负载测试也是通过信息/服务总线和BPEL介入而完成的，这是因为这些元素的性能将影响应用程序的质量体验(QoE)。为了确保负载下的性能而对SOA应用程序进行测试，则更有可能因为组件与员工支持点的相对性位置，而变得复杂。除非所有的SOA组件都是托管在一个带有短网络连接路径的通用数据中心中，QoE才有可能因为员工的位置而有所变化。

多地点的数据注入是网络连接程序唯一可靠的测试方式，它对SOA应用程序尤其重要。这种测试模式所面临的挑战是要找出相关问题的原因，这是因为网路中多地点所发生事件的具体时机，对于问题的解决是难以重复的。对事件时间准确标记的测试流监控是必不可少的。用户报告称，依靠数据记录器可能会出现问题，因为记录器会影响应用程序的性能，同时也影响事件处理的时机。

用户致力于敏捷开发实践，旨在调试新代码，对漏洞或者寻找SOA有用性和挑战性方面的更改做出更快速的反应。由于SOA中的组件都是比较孤立的，所以它能够迅速地编写新版本组件，并且在不重复主要部分和负载测试的前提下进行部署。然而，SOA组件间的交互性自然比较高，所以为了部署而对SOA水平集成进行测试可能会耗时。

重新部署SOA测试的最佳策略是，为非常结构化的组件接口和信息流进行设计，避免其出现自由格式的参数和松散的变量。让组件彻底地验证其参数，或采用WSDL模式明确表示参数的范围。如果组件可以“自我集成”，那么重新部署的更广泛的测试需求降低了，而调试变化和漏洞修复的速度却提升了。

SOA测试是集成应用测试的一种特殊情况，因为SOA通常部署较多的组件，并且工作流的交换过于结构化。通过利用结构化，可以降低大量组件化产生的风险，对没有通过测试的组件进行测试。