关注您的 SOA 测试盲点

• 下载免费的 SOAPSonar 个人版

引言

Web 服务——现代面向服务架构（SOA）的基础——是自成一体、模块化的应用程序，可以在网络上进行描述、发布、定位和调用。Web 服务与操作系统、硬件平台、通信协议或编程语言无关，模糊了企业内部网络设备、安全产品、应用程序和其他 IT 资产之间的界限。如今，几乎所有 IT 资产都将其接口公开为 Web 服务描述语言（WSDL）接口，准备通过 SOAP/XML 进行消息传递。通过使用 SOAP 进行系统间消息传递，使用 WSDL 进行接口描述，IT 专业人员现在能够以前所未有的灵活性跨企业域集成 IT 资产。正是 Web 服务提供的这种分布式计算的灵活性，使得开发和部署一个健壮、有弹性且可靠的面向服务架构充满挑战。SOA 架构师、开发人员和测试人员现在有责任调整他们的测试技术、选择合适的测试工具并发展 Web 服务领域专业知识，以确保他们的 SOA 部署能够可靠且安全地实现业务价值。

在本文中，我们将描述 SOA 测试人员在最近的实际部署中遇到的常见 SOA 盲点。这些盲点和补救措施关注以下领域：

• 性能
• 安全
• SOAP 附件
• WSDL
• 互操作性

对于 SOA 测试的这 5 个领域，在接下来的章节中，您将学习如何识别常见的 SOA 盲点以及避免它们的技巧。

示例设置

为了识别和修复 SOA 盲点，目标 Web 服务的 WSDL 被加载到一个测试工具中，如图 1 所示。Web 服务客户端可以消费由各种 IT 资产发布的基于 WSDL 的 API，包括 ERP、CRM、RDBMS、应用程序服务器、ESB 以及 Salesforce.com、StrikeIron 和 Xignite 等按需托管服务。WSDL 文件提供了 SOAP 客户端通过 HTTP 协议向目标 Web 服务发送 SOAP 请求所需的所有必要结构。

图 1：使用 SOAPSonar 调用目标 Web 服务。

在随后的章节中，我们将使用图 1 中的测试设置作为一个简单的 Web 服务消费者-生产者测试场景，来识别 SOA 测试盲点，并描述与已识别盲点相关的补救技术和挑战。

性能盲点

1. Web 服务是独立的：现代 SOA 基于构建可被各种消费者访问的可重用 Web 服务。Web 服务的可重用性导致 Web 服务变得依赖于其他 Web 服务。当 SOA 测试人员直接评估 Web 服务“A”的性能特性时，他们可能不知道 Web 服务“A”可能依赖的“隐藏”Web 服务。如果不知道 Web 服务“A”可能依赖的内部或外部 Web 服务，测试人员就会认为性能瓶颈在 Web 服务“A”中。然而，真正的瓶颈可能存在于“A”所依赖的 Web 服务中。

补救措施：现代 Web 服务应用程序不是孤立运行的，而是与其他 Web 服务连接的。要追踪瓶颈的根本原因，可以采取以下选项：

• 通过识别链中的每个 Web 服务并使用特定的测试用例直接测试来隔离问题。这意味着要消费链中每个 Web 服务的 WSDL。
• 禁用下游 Web 服务，并用具有已知性能特性的相似测试 Web 服务替换被禁用的 Web 服务。使用这种模拟的下游 Web 服务，可以准确地确定“视线内”Web 服务的行为。
• 在测试事务流经链时，监控链中每个 Web 服务的 CPU 和内存统计信息。这将使测试人员对链中哪个服务是延迟的原因有一个大致的了解。

挑战：为了隔离 Web 服务的瓶颈，需要访问下游 WSDL 以模拟这些 Web 服务。公司在技术、法律和治理方面的障碍可能会阻止访问此类 WSDL。与下游第三方服务提供商的服务级别协议（SLA）可能不包含在产生交易成本的情况下进行测试的规定。

2. Web 服务与 Web 网站性能测量相同：网站测试人员关注许多性能特征，包括响应时间、事务失败/成功率和吞吐量。对于可扩展性测试，网站测试人员通常会增加进入网站的并发客户端数量，并观察其性能特征。测试人员密切关注响应时间，并确定延迟是否可接受。无论延迟如何，他们都会关注事务失败/成功率，并设定可接受的“503 - 服务不可用”百分比阈值。在 Web 服务为基础的 SOA 世界中，相互依赖的服务是常态，失败/成功率的衡量应该超越 HTTP 代码。在 Web 服务中，失败会作为 SOAP 故障包含在消息中。这些故障可能源自下游 Web 服务，并一直传播到调用客户端。理解 Web 服务何时达到其“性能拐点”需要比仅仅检查 HTTP 返回码的成功和失败更深入的内容意识。

补救措施：错误状态的考虑应该比仅检查 HTTP 返回码更全面。为了识别失败/成功率，应考虑以下选项：

• 恰当使用 HTTP 成功和失败代码以及 SOAP 故障。在某些部署中，即使存在 SOAP 级别的失败，消费者也可能只需要 200 OK 的 HTTP 响应。这是一种非标准的方法。请遵守规范。
• 使用支持 Web 服务的性能工具，以便可扩展性测试不限于 HTTP 代码。SOAP 故障在性能测试期间应触发故障计数。
• 除了 HTTP 代码和 SOAP 故障之外，SOAP 消息中的业务（语义）数据也可能表明存在失败条件。通过使用 XPath，可以检查 SOAP 主体中的任何数据元素以查找业务级别的错误。例如，在可扩展性测试期间，如果股票报价响应返回负值，则发生了错误。在这种情况下，HTTP 代码甚至 SOAP 故障都表明没有错误。

挑战： SOA 实施者必须理解 Web 服务及其下游组件生成的 SOAP 故障。如果没有成为 Web 服务设计和开发过程的有机组成部分，SOA 实施者可能会创建不必要的盲点，使其无法看到和识别故障状态。这种无法看到 Web 服务故障条件的情况导致 Web 服务的性能特性变得毫无意义，仅简化为简单的网站性能配置文件。在诊断系统（在部署之前）时，在 SOAP 故障中传播过多的信息（如堆栈跟踪）是有益的，然而详细的 SOAP 故障存在风险，并且可能不必要地暴露公司基础设施的内部信息。这种信息泄露应该避免，并且在运行时部署中只应向消费者呈现可恢复的 SOAP 故障。最后，需要理解 SOAP 响应的业务背景，才能成功识别 SOAP 消息中缺乏 HTTP 错误或 SOAP 故障的错误。

安全盲点

1. 静态 SOAP 消息已足够： SOA Web 服务安全测试的一个关键部分是 WS-Security 验证。测试人员必须确保需要消息级安全（如 WS-Signatures、WS-Encryption 或 SAML）的目标 Web 服务能够无错误地消费这些消息。在这种测试中，一个常见的盲点发生在测试人员使用带有静态时间戳、随机数和安全标头的 SOAP 消息时。有关时间戳和安全元素的要求规定所有消息都必须具有唯一的线缆签名。静态消息应被消费服务器检测为过期消息或重放攻击。

补救措施：应开发回归套件，这些套件：

• 根据 WS-Security 1.1 规范的要求生成动态时间戳、随机数和安全令牌。
• 通过发送过期的消息来测试目标 Web 服务是否会响应过期的时间戳，并通过发送重复的随机数来检测重放攻击。
• 执行负载测试，其中每个 SOAP 请求都是唯一的。在负载测试期间，使用带有静态时间戳、随机数或安全令牌的 SOAP 消息应导致 SOAP 故障。

挑战：典型做法是将现有的 Web 应用程序测试工具改编为 Web 服务测试工具。生成静态 WS-Security 消息，并使用“复制粘贴”方案将消息加载到负载测试工具中。理解 WS-Security 的细微差别可能会让人不知所措，然而，培养这种技能并利用正确的工具对于构建安全且可扩展的 SOA 性能测试套件至关重要。

2. 仅进行正向测试用例已足够：大部分关注点放在正向测试用例上。对于更认真的测试人员，他们想要测试边界条件和执行负向测试，通常的方法是手动构建一些精选的负向测试，并将这些测试纳入回归套件。手动构建测试 Web 服务边界条件的负向测试用例效率低下且通常无效，并且通常基于“碰运气”的启发式方法。这种手动生成的负向测试可能有助于识别一些质量问题，但缺乏全面的覆盖，并且通常会导致 SOA 部署中留下盲点。

补救措施：通过自动化工具自动生成负向测试用例。这些工具应提供复杂的智能，用于基于以下内容生成测试用例：

• 目标 Web 服务接口的特定细节。从 WSDL 派生的负向测试用例。
• 能够根据 SOAP 响应定义成功和失败的标准。例如，如果使用负向测试用例调用的 Web 服务未返回 HTTP 错误或 SOAP 故障，则测试用例应指示失败条件。这种行为表明需要增强目标 Web 服务的异常管理。

挑战：自动生成负向和正向测试用例需要支持 Web 服务的复杂工具。由于注重降低成本，IT 部门可能会尝试使用现有的网站测试工具来开发无效且效率低下的基于启发式方法的负向和正向测试用例。然而，许多 SOA 部署已经认识到投资于自动化 Web 服务测试用例生成的 SOA 工具的投资回报。

SOAP 附件盲点

1. 附件是不会损坏的：SOAP 通常用于传输复杂的附件，如 MRI 图像、共同基金招股说明书和税务申报表。基于 MIME、DIME 和 MTOM 标准，任何二进制内容都可以作为 SOAP 附件进行传输。当将附件从客户端传输到 SOAP 服务器时，测试人员可能会收到 HTTP 200 OK 响应状态，但内容在传输过程中可能会损坏。仅依赖 HTTP 代码来评估 SOAP 附件传输可能会导致盲点，使 SOA 测试人员产生错误的成功感。

补救措施：为解决 SOAP 附件测试问题，可以采取以下选项：

• 开发回归套件，在传输前预先计算消息的校验和（MD5 或 SHA-1）。在传输 SOAP 附件后，测试人员应检索附件并重新计算校验和，确保上传和下载值匹配。
• 要求 Web 服务开发人员在上传完成后返回文档的校验和值。然后，测试人员可以将此值与预先计算的值进行比较。此测试技术无需下载文档；但是，这需要开发人员在其代码中添加计算和返回校验和值的功能。
• 考虑 WS-Security。对于熟悉 WS-Signatures 的复杂 SOA 部署，测试客户端可以对 SOAP 附件进行签名，Web 服务可以验证附件上的签名。此签名验证过程可确保传输的完整性。

挑战：SOAP 附件过程需要 SOA 部署具有一定的复杂性。虽然与传统的邮寄方式相比，通过电子传输大型文件可以带来显著的投资回报，但监管要求附件必须加密和签名。QA 专业人员必须彻底测试这些要求。投资能够处理各种附件标准、安全细微差别和互操作性问题的复杂工具，可以在测试 SOA 部署时提供显著的效率和准确性。

2. 大小无关紧要：好吧，事实并非如此！SOAP 附件的大小各不相同，从几 KB 到 GB。Web 服务端点的附件处理限制取决于供应商特定的内存处理方案。在实际应用中，像大型公司提交的税务申报单这样的附件可能达到几 GB，远远超过 32 位架构可寻址内存的 2GB 限制。Web 服务通常无法处理 GB 范围内的 SOAP 附件。

补救措施：为解决 SOAP 附件大小测试问题，应采取以下选项：

• 了解 SOAP 附件大小的业务需求，并构建回归套件来确定消息大小的断点。确保 Web 服务能够优雅地处理大于设定限制的消息。
• 与交易伙伴沟通测试和设定的附件大小阈值。

挑战：生成大型 SOAP 附件可能很困难。为大型 SOAP 附件开发、维护和运行回归测试需要 QA 团队投入大量的时间、精力，并产生高昂的成本。识别能够生成大型附件负载并为这些大型 SOAP 附件提供 WS-Security 的工具，对于部署可靠的 SOA 至关重要。

WSDL 盲点

1. 在局域网内进行测试已足够：Web 服务操作、输入/输出消息和消息数据类型在 WSDL 文件中都有详细定义。开发人员尝试将常见的数学结构（如业务地址、采购订单项目等）抽象为可重用的数据“类型”，并以模式定义（XSD）的形式表示。然后，这些模式定义被托管在外部，以便在整个企业中被 WSDL 重用。Web 服务开发人员只需通过 URI 将这些模式定义导入或包含在他们的 WSDL 中。SOA 测试人员遇到的一个最常见的盲点是，他们在内部局域网测试工具中使用了这些 WSDL，并成功运行了他们的测试套件。然而，一旦 WSDL 被移交给外部交易伙伴，防火墙通常无法访问模式 URI。随着企业内部重用的增加，这种重用是基于 Web 服务的 SOA 最强大的优势，这种盲点变得非常显著。

补救措施：为解决 SOAP 附件测试问题，应采取以下选项：

• 在内部测试 WSDL，并从广域网（WAN）外部的企业防火墙重复测试。这更接近于模拟外部交易伙伴的体验，并确保 Web 服务在移交给外部消费者时不会中断。
• 在将 WSDL 移交给外部交易伙伴时，将其“扁平化”。将模式的包含和导入内联，这样所有模式信息都直接出现在 WSDL 中，并且不再需要外部 URI 来访问模式定义。当防火墙限制阻止访问企业网络内部托管的模式定义时，这种 WSDL 扁平化可能是唯一的选择。

挑战：WSDL 的复杂性不断增加，并且随着对重用的关注，公司正在抽象模式定义并通过 URI 导入使其可访问。

2. WSDL 是为开发人员准备的：WSDL 是 SOA 中消费者和生产者之间最重要的合同。WSDL 通常由开发人员生成或编写，目的是使消费者能够进行集成。WSDL 的质量可能会有所不同。对于生成的 WSDL，WSDL 的质量取决于 WSDL 生成器以及开发人员用于生成 WSDL 的参数。对于 WSDL 在编写 Web 服务之前就已构建的自顶向下方法，手动合并多个 WSDL 操作、模式和绑定通常容易出错。在手动编写和自动生成的 WSDL 中，开发人员可能会执行简单的单元测试，但未能识别 WSDL 中的问题。例如，许多 IDE 提供默认命名空间（namespace=http://tempuri.org），开发人员可能不会更改。这会导致中介机构在尝试聚合和合并来自不同内部来源的 WSDL 时出现命名空间冲突。QA 测试人员在理解 WSDL 质量方面负有同等甚至更重要的责任。

补救措施：为解决 WSDL 质量问题，应采取以下选项：

• 深入研究 WSDL，了解如何识别 WSDL 质量。
• 启用 WSDL 质量评估流程，向开发团队提供关于其 WSDL 质量的反馈。

挑战：QA 专业人员应尽早成为 Web 服务开发过程的有机组成部分。SOA 项目的 WSDL 应该被 QA 团队充分理解，并且由于 WSDL 捕获了特定于业务的信息，QA 团队应该在 Web 服务项目的初始阶段理解业务目标。

互操作性盲点

1. 所有 Web 服务都可以相互通信：互操作性评估是 Web 服务部署中最重要的部分。Web 服务是为消费者开发的，独立于消费者运行的语言、操作系统或硬件。典型的 Web 服务消费者是用 Java、.NET 和 PHP 编写的。QA 测试人员负责确保已发布的 WSDL 可以被消费应用程序使用的语言所消费。

补救措施：为解决 SOAP 互操作性测试问题，应采取以下选项：

• 采用运行互操作性测试的 SOA 测试产品，例如 WSI-Basic Profile 和 WSI-Basic Security Profile 互操作性测试。这些测试强制执行允许跨语言互操作性的要求。例如，WSI-BP 要求 SOAP 消息类型为document/literal，而不是rpc/encoded。
• 建立一个包含常用语言（如 Java、.NET 和 PHP）以及常用解析器（如 AXIS 和 XFire）的 Web 服务消费者的测试套件。
• 测试不同版本的语言框架。例如，.NET WSE 2.0 对批量加密使用 AES-128。然而，WSE 3.0 默认使用 AES-256。

挑战：构建一个全面的 SOA 测试平台充满挑战，尤其是在需要广泛推广的情况下。随着更复杂的操作（如 WS-Signatures、WS-Encryption、附件处理）被添加到组合中，互操作性问题会加剧。现在有更多的配置选项需要测试。投入前期时间和精力，构建基于商业 SOA 测试产品的自动化套件，对于应对部署高度可互操作的 SOA 的挑战至关重要。

结论

基于 Web 服务的 SOA 的承诺在于跨分布式环境的可重用性。开发 Web 服务的便捷性给 SOA 测试人员带来了巨大的压力，需要确保 Web 服务是健壮、可靠、安全且可扩展的。通过与开发团队协作、对 Web 服务技术的日益理解以及使用全面的 SOA 测试工具，SOA 测试人员可以确保 SOA 测试盲点得到减少，如果不能完全消除的话。

关于 Crosscheck Networks

下载免费的 SOAPSonar 个人版

Crosscheck Networks 专注于提供**SOA 诊断**产品。Crosscheck 的旗舰产品 **SOAPSonar** 减轻了测试 Web 服务的痛点。它提供全面的无代码 Web 服务测试，界面直观。简单的导航、拖放式 WSDL 加载、拖放式测试套件管理、复杂 WSDL 支持（WSDL 和 XSD 导入）以及先进的性能技术，使得验证 Web 服务变得容易。SOAPSonar 提供跨 SOA 测试的四个支柱（功能回归、性能测试、互操作性符合性和漏洞评估）的全面测试。