实现SOA愿景，执行技术培训

　　对SOA普遍特征的认知和对SOA的期望是很重要的，这有助于QA工作集中化。因此，应当针对SOA环境的整体范围对IT团队进行培训，包括业务涉及哪些领域、提供服务要涉及哪些系统、哪些系统计划成为新服务使用者。他们应当了解与计划相关的标准、原则和治理。

　　与SOA计划培训一样，团队应当也乐于采用测试所必需的Web服务技术。这通常包括XML（结构、名称空间和模式）和WSDL。

　　因此，这些领域的培训方案是SOA计划中持续进行的一部分。

　　维护自动化服务整合测试套件

　　人们希望核心战略服务能易于使用，并且长期重用。它们简单的界面之下隐藏了复杂整合的底层后端系统。因此，一定也包含了更高的服务质量风险。任意服务实现堆栈层中的变更都可能导致服务功能的回归。在这种情况下，应当及早捕获回归、快速隔离回归，以便在发布下一版系统更新之前，确定并实现必要的调整。

　　为管理每个战略服务的质量，建议要在维护服务的同时维护一个自动化测试套件（查看[2]了解创建这种包含复合服务的套件的具体指南）。此套件必须根据需要执行，而几乎（或完全）不需要安装时间。此套件应当适用于服务堆栈每层中的主要组件。

　　相关的治理实践只能保证，如果已证明自动化整合测试套件存在并且受到维护，那么服务可用。

　　采用服务测试框架

　　要自动化并维护服务整合测试套件，必须开发和重用一些普遍功能。包括：

　　能够生成没有应用程序UI的测试工具

　　根据服务描述（WSDL）生成测试消息

　　输入变量，使用数据表

　　数据安装和卸载脚本

　　测试报表输出

　　预期结果的定义

　　针对堆栈的每个整合层执行测试（通常是通过一个单元测试环境）

　　模拟外部服务（mock）

　　审查和验证来自所使用的应用程序的服务消息

　　通过分离的线程发送多条测试消息

　　这些功能打包在一个整合测试框架（ITF）内。框架通常由商业工具或开源工具组成，结合了定制和调整，可满足特定的环境要求。

　　ITF不为各个服务重复实现这些功能，而应当作为单独的可重用资产进行维护，包含了常用的程序、工具和脚本。建议您从Web服务功能测试工具起步（参见 [3] 和 [4]），为框架打基础。

　　图 1. 整合测试框架（ITF）

　　使用Mock服务，在与提供者整合之前为客户进行测试

　　Mock可在实际提供者不可用时允许进行测试。这有助于服务测试开发，还有助于在与完整服务整合之前分离客户测试。

　　为支持不完善的项目时间安排，例如当服务仍然处于开发阶段时，客户需要进行其他测试，于是要提供 Mock 服务来代替实际服务。ITF 应当有能力生成Mock服务，以用于这样的情况。

　　图 2. Mock服务

　　使用测试套件，在客户整合之前充分测试服务

　　在服务开发过程中，应当开发一种版本持续进化的自动化服务整合测试套件。这可简化必要的问题确定和调试工作。如果没实现这种开发，那么就比较难以确定某问题是客户的责任还是提供者的责任。

　　始终为性能测试作计划

　　性能测试用于测定新服务的可伸缩性和响应能力，应当是计划的一部分。也应当考虑为新客户进行性能测试，因为不同的客户有着不同的负载特性。

　　ITF应当具备按比例增加并行请求数量的能力。

　　应当及早并持续地度量服务实现性能。不能等到最后，因为变更设计可能代价高昂。

　　为设置和验证安全性保留足够时间

　　在实现服务安全性之时，许多教训应当谨记于心：

　　当解决方案受到端到端的保护（例如利用令牌档案）时，调试服务握手可能很困难

　　负面案例测试方案比正面案例更加流行（例如正在验证和处理的消息）

　　利用使用端UI，开发出的测试案例可验证这些用户依靠新解决方案能做些什么，以及配套应用程序允许他们做些什么。

　　ITF需要能够调用安全服务

　　只有WS-Security规范的子集能够由供应商和开源框架实现共同使用，从而为变通方案提供时间

　　为外部合作伙伴或客户进行测试时，应当计划利用客户端消息和参数记录，以便减少调试工作

　　设计监测和记录功能

　　为了快速识别和减少SOA实现中的问题，特别是涉及到复杂流程流时，推荐使用日志记录。日志记录应当可转换为多种详细程度，而且应当使跨系统的跟踪信息具有相关性，例如通过记录准确时间戳或者报头标识符。

　　采用环境发烟测试

　　SOA解决方案通常依靠许多整合组件，例如Enterprise Service Bus（ESB）和网关。有了这许多可动部件，在完全部署到各环境之前，对这些组件的测试应当一切正常。如果环境和整合组件没有事先验证，那么要减少问题就更加困难和耗时。

　　采用测试驱动的开发的常用实践

　　本文概述的实践中，有一些可归类到常用的测试驱动开发 (TDD) 实践。TDD 建议及早开始测试并持续测试，例如测试每个系统版本。随着系统的演化，需要不同形式的测试工具，包括要能模仿或去除在黄金时间尚未准备好的部分。

　　由于许多SOA项目中存在复杂性和协调需求，增量式或迭代式的开发实践并不少见。推荐使用TDD原则，这是为了获得针对最新变更的基于测试的即时反馈，以完成这些项目。

　　仔细策划测试战略

　　测试战略概述了项目或版本细节，例如测试的责任和要执行的测试的类型。其计划应当包括培训、构建整合服务测试套件、独立客户测试、性能测试、安全性和依赖性管理（在一般情况下，相关组件不是在易于管理的步骤中发布的）。

　　为改善一致性，建议在每个可能情况下，使用一些原则作为默认实践。原则包括：

　　为每个新服务进行性能测试和测量

　　为每个新服务构建和执行整合测试套件

　　为系统更新的每个新子集执行整合测试套件

　　为新客户提供早期Mock服务或测试实际服务版本

　　详细测试计划原则现在也整合到了SOMA[1]当前版本之中，SOMA是一种IBM方法。