软件开发专业人士都知道测试是开发和部署的关键过渡，而部署又往往是软件开发项目的终极目标。要做面向服务架构(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的引进变得复杂，因为这些元素的性能将影响软件用户体验质量。测试一个完全策划的SOA应用程序负载下的性能，由于组件布局与工人的支持这一点相关而变得更复杂。除非所有的SOA组件都是托管在一个通用的数据中心，用很短的网络连接路径，用户体验质量可能有些许变化，这取决于工人的位置。

　　多地数据注入是测试网络连接应用程序唯一可靠的方式，并且这对于测试SOA应用程序尤其重要。在这个模型中的测试挑战在于，关联问题与原因，因为在网络中多个点发生的事件很难重复，以助于隔离问题。通过准确的事件时间戳来监控测试流是至关重要的。用户报告说，依靠数据日志可以记录影响应用程序性能问题，和事件处理的时间。

　　用户致力于敏捷开发实践是为了更快调试新代码，来回复错误或变更，可能会发现SOA不仅有帮助而且是一个挑战。因为SOA中的组件更为孤立，它可能会很快有一个新版本的组件，并且在不重复集成和负载测试主要部分的前提下重新部署。然而，SOA组件之间的交互性自然更高，所以测试SOA水平集成的重新部署可能耗时。

　　SOA重新部署测试最好的策略是，为非常结构化组件接口和消息流设计，避免自由格式的参数和松散的变量。让组件彻底地验证他们的参数 and/or 有WSDL模式表达参数范围明确。如果各个组件可以“自我整合”，那么在重新部署上更广泛的测试需求就降低,调试的速度变化，并且bug的修复增加。SOA测试是一种特殊的综合应用测试，特别因为SOA通常部署更多的组件和特殊，因为工作流交流至少可能更结构化。通过利用结构优势,可以减少广泛组件化带来的风险，以及彻底测试而不至于过度测试。