考虑到更高的解决方案协调性和敏捷性，改用面向服务的体系架构 (SOA) 会给企业带来众多益处。进行平滑过渡需要特别关注质量，并认识到与
SOA 内的测试相关的独特挑战。通常，没有计划对测试能力进行必要调整，或调整不够明显。组织需要了解与改进服务架构相关的独特目标和挑战，并了解应当如何执行测试。本文将讨论利用
SOA、推荐的最佳实践和经验教训，来解决质量保证难题。
就和之前的其他项目一样，人们有兴趣处理包含面向服务的体系架构 (SOA) 的项目。然而，考虑到项目表现出的一些独特的测试挑战，可能要优化测试实践，以更好地满足特定于项目的
QA 要求。第一步是确保开发和测试团队熟悉项目中将引发独特挑战的各方各面。这些方面可能包括：
- 简单、易于使用、隐藏了复杂性的界面
- 开放性，以备将来重用
- 使用各种配套系统进行实现的技术复杂性
图 1. 异构连接和复杂性
- 必要的跨业务协调
- 可与底层应用程序逻辑区分开的、服务流内部的逻辑性
- 与配套应用程序安全性不同的服务安全性需求
图 2. 多处的逻辑和安全性
- 作为独立管理的 IT 组件的服务
这些因素独立或结合起来，都可能导致产生与测试相关的挑战。本文讨论了一些普遍遭遇到的挑战，以及可用于缓解这些痛苦的最佳实践。
在 SOA 环境中，测试团队超越了传统的以应用程序为中心的功能和性能测试。SOA 需要整合地测试界面和服务，这些界面和服务有助于组合利用不同的系统、平台以及相关安全标准。
要测试这些应用程序时，就提出了独特挑战。
服务可能不具有用户界面
传统上，应用程序拥有 GUI 或相关的用户界面，可用于手动或自动执行功能测试。在 SOA 中，环境服务可能没有界面。测试员处理不同技术（例如
SOAP 和 Web 服务）下的消息和网络协议。深度暴露的服务会封装底层流程，因而要确保充分的测试范围，这是一种挑战。
处理 Web 服务时，我们能使用基于标准的测试工具（如 SOAPUI）来应对挑战。这些工具能够为服务生成基于
Web Service Description Language (WSDL) 文件的测试客户机，然后客户机帮助测试员理解
Web 服务的运作和调用服务。
数据收集
单一 SOA 环境能利用来自不同内部人员和外部涉众的不同技术和不同数据格式。这需要 QA 团队验证所有技术和数据格式的整合。这种工作中非常关键的一个部分是在部署并执行所有测试方案之前收集正确的数据。如果事前收集了测试数据，这就确保了
QA 生命周期不会因为在特定测试周期中数据可能不可用而受到干扰。
这需要更广泛的设计阶段和 SOA 治理，以及 QA 团队与相关方面的协同参与。SOA 治理这一中央团队主持整体
SOA 工作，即管理并监控此工作，测试团队应当识别其测试数据需求，并与相关涉众合作，以便在服务开发进程中获取数据。SOA
治理流程应当确保 QA 团队的需求得到满足。这些实践确保了当整合测试所需服务就绪时，QA 团队将充分获得必要数据。
更高层次的整合需要更好的规划和战略，以解决可用性问题
在更传统的方法中，测试员可期待应用程序或业务功能通过单个项目、在通过 Web 界面向大众开放的单一应用程序服务器上得到交付。借助
SOA，应用程序逻辑可位于中间层，利用任意数量的技术而运作，驻留在部门甚至公司之外。这使得端到端测试即使在测试环境中都依赖于第三方。如果某重要的特定第三方系统不可用，如果
QA 团队没有做好准备，那么就可能干扰 QA 周期。QA 团队必须准备好应对所有状况。
图 3. 依赖于第三方的业务流程流
对于执行测试周期而遭遇这种干扰的 QA 团队而言，所有涉众都前瞻性地通知其停机时间，并为之作出计划，这十分关键。如
SOAPUI 和 Rational Application Developer (RAD) 等工具可用于创建
mock 占位符服务来帮助适应特定服务的停机时间和不可用性。
Mock 服务允许 QA 团队在降低对涉众的依赖性的同时运行端到端测试。QA 团队能创建与实际服务作用相似的占位符服务。这些服务是使用实际
WSDL 和受支持的原始服务模式而生成的。Mock 服务拥有一组响应。这些响应用于响应对 Mock 服务的请求。响应可以是随机的、循环的或基于特定规则/策略的。
图 4. 业务流程流对第三方的依赖 —— Mock 服务
如果原始服务出于任意原因而不可用，就可使用 Mock 服务。这有助于确保 QA 周期不受特定服务故障的负面影响。一旦定义了服务界面，测试员就能继续创建服务，以获取端到端解决方案，而不需等待实际服务得到开发。
Mock 服务还有助于隔离缺陷，同时调试问题、研究问题根源。由于 Mock 服务受到良好控制，它们有助于创建更加可控的环境，特别是在诊断缺陷之时。以这种方式，测试员就能推动不同的端到端方案，而且较少受到第三方位置的可能问题的影响。我们推荐为项目中每个
Web 服务都生成一个 Mock 服务。
安全挑战
由于 SOA 环境的特质是利用了独立服务，所以维护安全性就更具挑战性。安全解决方案必须应对安全性的所有典型方面
—— 即验证、授权、准确识别、消息完整性、认可、机密性/私密性和审计支持。这要求仔细地确立可靠的关系，特别要使用
WS-Security 标准。为了能够测试安全措施，关键是要了解所使用的标准、协议和约定，并具备相关技能。
同样，Web 服务是基于 Web 的，因而需要像关注任意 Web 解决方案一样关注它。仍然可应用例如
Rational AppScan [5] 等工具来测试其漏洞。
针对安全漏洞，必须采用常规的负面测试用例。列表将包含测试，以确保：
- 拒绝重放，即不应该接受稍后重新发送的复制消息
- 不可能发生中间人攻击
- 消息是机密的，不能未预先通知就进行改变
- 只有合法用户能访问服务（包括拒绝欺诈阴谋）
必须确保出色的异常管理
当不同服务通过一个公共层相互作用时，必须测试异常状况，并确保代码使用了基于规范的标准，以处理边缘/负面流程条件。业务流程流帮助模拟影响底层服务的业务事件的进展。如果任一个服务不响应或在某种意义上响应失败，则流程应当足够健壮以处理这种状况，并提供故障通知。在测试流程时，这些边缘条件必须得到识别和测试。
重用挑战
重用是 SOA 的主要益处之一。在开始采用 SOA 之时，单个服务会被数个或少数应用程序所使用；但很快，一些服务将被许多应用程序使用。如果这些服务没有计划在如此负载下运行，没有经过相关测试，那么一些使用它们的应用程序可能要遭受不可接受的响应时间。而且在最坏的情况下，服务没有经过彻底测试而且不能工作，那么对于整个组织而言，这种故障的影响可能是灾难性的，因为同时会有多个应用程序受到影响。
学习曲线
一些技术和标准（例如 SOAP、Web 服务、XML、BPEL 和 WS-Policy）不断发展。采用这些技术的过程会很缓慢，因而当企业执行现代化任务时，需要考虑相关学习曲线。QA
团队成员需要深刻理解这些技术与好处，这些技术和好处使他们能够有效地测试 SOA 解决方案。
实现 SOA 愿景，执行技术培训
如简介所述，对 SOA 普遍特征的认知和对 SOA 的期望是很重要的，这有助于 QA 工作集中化。因此，应当针对
SOA 环境的整体范围对 IT 团队进行培训，包括业务涉及哪些领域、提供服务要涉及哪些系统、哪些系统计划成为新服务使用者。他们应当了解与计划相关的标准、原则和治理。
与 SOA 计划培训一样，团队应当也乐于采用测试所必需的 Web 服务技术。这通常包括 XML（结构、名称空间和模式）和
WSDL。
因此，这些领域的培训方案是 SOA 计划中持续进行的一部分。
维护自动化服务整合测试套件
人们希望核心战略服务能易于使用，并且长期重用。它们简单的界面之下隐藏了复杂整合的底层后端系统。因此，一定也包含了更高的服务质量风险。任意服务实现堆栈层中的变更都可能导致服务功能的回归。在这种情况下，应当及早捕获回归、快速隔离回归，以便在发布下一版系统更新之前，确定并实现必要的调整。
为管理每个战略服务的质量，建议要在维护服务的同时维护一个自动化测试套件（查看 [2] 了解创建这种包含复合服务的套件的具体指南）。此套件必须根据需要执行，而几乎（或完全）不需要安装时间。此套件应当适用于服务堆栈每层中的主要组件。
相关的治理实践只能保证，如果已证明自动化整合测试套件存在并且受到维护，那么服务可用。
采用服务测试框架
要自动化并维护服务整合测试套件，必须开发和重用一些普遍功能。包括：
- 能够生成没有应用程序 UI 的测试工具
- 根据服务描述 (WSDL) 生成测试消息
- 输入变量，使用数据表
- 数据安装和卸载脚本
- 测试报表输出
- 预期结果的定义
- 针对堆栈的每个整合层执行测试（通常是通过一个单元测试环境）
- 模拟外部服务 (mock)
- 审查和验证来自所使用的应用程序的服务消息
- 通过分离的线程发送多条测试消息
这些功能打包在一个整合测试框架 (ITF) 内。框架通常由商业工具或开源工具组成，结合了定制和调整，可满足特定的环境要求。
ITF 不为各个服务重复实现这些功能，而应当作为单独的可重用资产进行维护，包含了常用的程序、工具和脚本。建议您从
Web 服务功能测试工具起步（参见 [3] 和 [4]），为框架打基础。
图 5. 整合测试框架 (ITF)
使用 Mock 服务，在与提供者整合之前为客户进行测试
Mock 可在实际提供者不可用时允许进行测试。这有助于服务测试开发，还有助于在与完整服务整合之前分离客户测试。
为支持不完善的项目时间安排，例如当服务仍然处于开发阶段时，客户需要进行其他测试，于是要提供 Mock
服务来代替实际服务。ITF 应当有能力生成 Mock 服务，以用于这样的情况。
图 6. Mock 服务
使用测试套件，在客户整合之前充分测试服务
在服务开发过程中，应当开发一种版本持续进化的自动化服务整合测试套件。这可简化必要的问题确定和调试工作。如果没实现这种开发，那么就比较难以确定某问题是客户的责任还是提供者的责任。
始终为性能测试作计划
性能测试用于测定新服务的可伸缩性和响应能力，应当是计划的一部分。也应当考虑为新客户进行性能测试，因为不同的客户有着不同的负载特性。
ITF 应当具备按比例增加并行请求数量的能力。
应当及早并持续地度量服务实现性能。不能等到最后，因为变更设计可能代价高昂。
为设置和验证安全性保留足够时间
在实现服务安全性之时，许多教训应当谨记于心：
- 当解决方案受到端到端的保护（例如利用令牌档案）时，调试服务握手可能很困难
- 负面案例测试方案比正面案例更加流行（例如正在验证和处理的消息）
- 利用使用端 UI，开发出的测试案例可验证这些用户依靠新解决方案能做些什么，以及配套应用程序允许他们做些什么。
- ITF 需要能够调用安全服务
- 只有 WS-Security 规范的子集能够由供应商和开源框架实现共同使用，从而为变通方案提供时间
- 为外部合作伙伴或客户进行测试时，应当计划利用客户端消息和参数记录，以便减少调试工作
设计监测和记录功能
为了快速识别和减少 SOA 实现中的问题，特别是涉及到复杂流程流时，推荐使用日志记录。日志记录应当可转换为多种详细程度，而且应当使跨系统的跟踪信息具有相关性，例如通过记录准确时间戳或者报头标识符。
采用环境发烟测试
SOA 解决方案通常依靠许多整合组件，例如 Enterprise Service Bus (ESB)
和网关。有了这许多可动部件，在完全部署到各环境之前，对这些组件的测试应当一切正常。如果环境和整合组件没有事先验证，那么要减少问题就更加困难和耗时。
采用测试驱动的开发的常用实践
本文概述的实践中，有一些可归类到常用的测试驱动开发 (TDD) 实践。TDD 建议及早开始测试并持续测试，例如测试每个系统版本。随着系统的演化，需要不同形式的测试工具，包括要能模仿或去除在黄金时间尚未准备好的部分。
由于许多 SOA 项目中存在复杂性和协调需求，增量式或迭代式的开发实践并不少见。推荐使用 TDD 原则，这是为了获得针对最新变更的基于测试的即时反馈，以完成这些项目。
仔细策划测试战略
测试战略概述了项目或版本细节，例如测试的责任和要执行的测试的类型。其计划应当包括培训、构建整合服务测试套件、独立客户测试、性能测试、安全性和依赖性管理（在一般情况下，相关组件不是在易于管理的步骤中发布的）。
为改善一致性，建议在每个可能情况下，使用一些原则作为默认实践。原则包括：
- 为每个新服务进行性能测试和测量
- 为每个新服务构建和执行整合测试套件
- 为系统更新的每个新子集执行整合测试套件
- 为新客户提供早期 Mock 服务或测试实际服务版本
详细测试计划原则现在也整合到了 SOMA[1] 当前版本之中，SOMA 是一种 IBM 方法。
| 
