使用黑盒、白盒和灰盒技术进行 SOA 测试

• 免费下载 SOAPSonar™ 个人版

一、引言

Web 服务是现代面向服务架构 (SOA) 的基础。典型的 Web 服务包括消费者和生产者之间的消息交换，通过无处不在的 HTTP 协议使用 SOAP 请求和响应。Web 服务生产者通过 Web 服务描述语言 (WSDL) 向潜在消费者宣传其服务——WSDL 是一个 XML 文件，其中包含可用操作、执行端点和预期的 SOAP 请求-响应结构等详细信息。 多年来开发的许多测试技术和方法论也适用于基于 Web 服务的 SOA 系统。通过功能、回归、单元、集成、系统和流程级别测试，测试方法论的主要目标是提高对目标系统能够以健壮、可扩展、可互操作和安全的方式交付功能的信心。 诸如黑盒、白盒和灰盒测试等技术应用于传统系统，也很好地映射到 Web 服务的部署中。然而，Web 服务部署的以下特性带来了独特的测试挑战： Web 服务本质上是分布式、平台和语言无关的。 Web 服务可以被链接，并依赖于其他可能随时更改的第三方 Web 服务。 Web 服务的归属权由多个利益相关者共享。 Web 服务的客户端开发人员通常只能访问接口（WSDL），而无法访问代码。 本文将探讨测试技术及其在 Web 服务中的应用。我们将使用一个简单的示例 Web 服务来说明每种技术及其相对的优缺点。最后，将介绍一种利用 WSDL 文件中丰富信息，将灰盒测试扩展到白盒测试领域的新颖方法。

关键概念 必要的测试技术 使用黑盒、白盒和灰盒测试技术是部署健壮 SOA 的关键。 灰盒测试最适合 Web 服务消费者 WSDL 中发布的 Web 服务操作提供了足够丰富的信息，供消费者从中获益于灰盒测试。 将灰盒测试的范围扩展到白盒测试领域 利用 Web 服务 WSDL，智能生成的测试可以使灰盒测试更接近白盒测试，而无需承担相应的负担。 自动生成的测试 基于 Web 服务 WSDL 的变异使开发人员能够自动生成测试，广泛地测试已发布操作的多个代码路径。

二、黑盒、白盒和灰盒测试在 Web 服务中的应用

A. 黑盒测试

定义：黑盒测试是指在对系统内部一无所知的情况下进行系统测试的技术。黑盒测试人员无权访问源代码，也不知道系统架构。黑盒测试人员通常通过用户界面与系统交互，提供输入并检查输出，而不知道输入是如何被操作的。在黑盒测试中，对目标软件进行一系列输入的测试，并观察输出是否正确。输出是如何生成的或盒子里面有什么对测试人员来说并不重要。

Web 服务示例：为了说明对示例 Web 服务的黑盒测试，我们展示了一个名为 Divide 的操作，它只是将两个整数 a 和 b 相除。黑盒测试人员不知道在后台执行 Divide 操作使用了什么操作系统、编程语言、第三方库或其他 Web 服务。

图 1：Divide 操作的黑盒测试示例。

如图 1 所示，黑盒测试人员能够向操作输入并查看输出。测试人员可能知道 Web 服务 WSDL 的位置，但完全不知道实现细节、程序执行状态和内部异常处理。测试人员有一个规范，并经过严格、耗时且往往是冗余的尝试值练习，以确保 Divide 操作按预期运行。

优点

• 高效测试——非常适合并高效处理大型代码段或单元。
• 无偏测试——通过分离 QA 和开发职责，清晰地将用户视角与开发人员视角分开。
• 非侵入性——不需要代码访问。
• 易于执行——可以扩展到大量中等技能的测试人员，他们无需了解实现、编程语言、操作系统或网络。

缺点

• 局部化测试——代码路径覆盖受限，因为只测试了有限数量的测试输入。
• 低效的测试编写——在没有实现信息的情况下，详尽的输入覆盖对实际代码路径的覆盖范围存在未知的好处，并且可能需要巨大的资源。
• 盲目覆盖——无法控制目标代码段或路径，这些代码段或路径可能比其他代码段更容易出错。

黑盒测试最适合快速测试场景和快速 Web 服务原型设计。这种 Web 服务测试技术通过快速抽查，提供对操作功能就绪性的快速反馈。黑盒测试也更适合输入有枚举值、或严格定义的范围或方面的操作，这样就不需要广泛的输入覆盖。

B. 白盒测试

定义：白盒测试是指在了解系统内部情况的情况下进行系统测试的技术。白盒测试人员可以访问源代码，并了解系统架构。白盒测试人员通常分析源代码，根据对源代码的了解推导出测试用例，最后针对特定的代码路径以达到一定的代码覆盖率。

Web 服务示例：为了说明白盒测试，图 2 展示了一组简单的 C# 操作。第一个操作 Divide 接受两个整数，并返回 a 除以 b，没有对输入值进行检查。第二个操作 safeDivide 接受两个字符串参数输入，但与第一个操作 Divide 不同，safeDivide 操作具有广泛的异常处理机制，可以安全地捕获数据类型或数据值不正确的情况。

白盒测试人员在了解这两个操作的详细信息后，可以轻松地创建有效的测试用例，以测试边界条件。仅通过观察代码，白盒测试人员就可以立即尝试

• 零除场景，将分母 b 设置为零。
• 整数溢出场景，将整数 a 的值设置为 > ± 2,147,483,647。
• 正交数据类型，例如，浮点数、日期、十进制数据类型。
• 特殊字符。

图 2：两个 Web 服务操作的白盒测试示例。

对 safeDivide 操作执行的简单的零除测试，按预期返回一个基础错误代码 -1。然而，对 Divide 操作执行相同的零除测试会在 SOAP 响应中产生以下冗长的堆栈跟踪：

1. <soap:Fault>
2.   <faultcode>soap:Server</faultcode>
3.      <faultstring>System.Web.Services.Protocols.SoapException: Server was 
            unable to process request. --- System.DivideByZeroException: 
            Attempted to divide by zero. at DivideService.Divide(Int32 a, Int32 b)
            End of inner exception stack trace ---
4.   </faultstring>\
5. </soap:Fault>

在 Divide 操作中，白盒测试人员可以快速识别并随后验证，目标操作没有自定义异常，而是依赖于运行 Web 服务的供应商容器来处理异常。然后，测试人员会将这种缺乏异常处理的情况指出来，并使其与使用 try-catch 流程进行异常处理的 safeDivide 操作保持一致。黑盒测试人员或许可以通过盲测识别弱点，但是，所需的工作量和迭代次数将很大，并且尤其在程序复杂性增加时，发现此类缺陷的概率会很低。

优点

• 提高有效性——交叉检查设计决策和假设与源代码的对比可能勾勒出健壮的设计，但实现可能与设计意图不符。
• 完全覆盖代码路径——所有可能的代码路径都可以被测试，包括错误处理、资源依赖和其他内部代码逻辑/流程。
• 早期缺陷识别——分析源代码并根据实现细节开发测试，使测试人员能够快速找到编程错误。
• 揭示隐藏的代码缺陷——访问源代码可以加深理解，并发现程序模块未预期的隐藏行为。

缺点

• 难以扩展——需要对目标系统、测试工具和编程语言以及建模有深入的了解。这限制了熟练和专业测试人员的可扩展性。
• 难以维护——需要源代码分析器、调试器和故障注入器等专用工具。
• 文化冲突——开发人员和测试人员之间的界限开始模糊，这可能会引起文化冲突。
• 高度侵入性——要求代码修改是通过交互式调试器完成的，或者通过实际更改源代码来完成的。这对于小型程序来说可能足够了；然而，对于大型应用程序来说，它的可扩展性较差。对于网络或分布式系统无效。

白盒测试最适合开发周期的早期 Web 服务，此时开发人员和测试人员可以协作查找缺陷。白盒测试对于大型 SOA 部署存在问题，因为服务的分布式特性使得第三方 Web 服务可以很容易地从其他 Web 服务中调用。这导致对编程语言、操作系统和硬件平台知识的缺乏。与调用在同一内存空间中运行的共享库中的函数不同，分布式 Web 服务提供了额外的访问挑战，使得跨 SOA 的白盒测试几乎不可能。

C. 灰盒测试

定义：灰盒测试是指在对系统内部有有限了解的情况下进行系统测试的技术。灰盒测试人员可以访问详细的设计文档，其中包含超越需求文档的信息。灰盒测试是基于状态模型或目标系统架构图等信息生成的。

Web 服务示例：为了说明灰盒测试，图 3 展示了简单的 Divide 和 safeDivide 操作的 Web 服务描述语言 (WSDL) 文件。第 3-36 行显示了消息的数据类型。这些行，以及第 23-24 行和第 43-45 行，指向使用无界字符串的 safeDivide 请求消息。即使没有源代码或二进制文件，这也表明测试人员应该尝试缓冲区溢出类型的边界条件。

在无法访问源代码或二进制文件的情况下，Web 服务测试人员只能通过 WSDL 文件来消费和调用 Web 服务。通过 WSDL 中提供的丰富信息，以及无法修改代码或二进制文件进行白盒测试，Web 服务测试人员可以利用 Web 服务的位置、传输协议（第 82 行）、数据类型（第 3-36 行）等详细信息，为编写智能、高效且高度有针对性的测试用例提供显著的优势。

图 3：Divide 和 safeDivide 操作的 WSDL 文件（部分折叠）。

优点

• 提供联合优势——在可能的情况下，利用黑盒和白盒测试的优点。
• 非侵入性——灰盒不依赖于访问源代码或二进制文件。相反，它基于接口定义、功能规范和应用程序架构。
• 智能测试编写——基于可用的有限信息，灰盒测试人员可以编写智能测试场景，特别是在数据类型处理、通信协议和异常处理方面。
• 无偏测试——测试人员和开发人员之间的界限仍然存在。仅在接口定义和文档之间进行交接，而无需访问源代码或二进制文件。

缺点

• 部分代码覆盖——由于没有源代码或二进制文件，遍历代码路径的能力仍然受限于通过可用信息推导出的测试。覆盖范围取决于测试人员的编写技能。
• 缺陷识别——分布式应用程序固有的缺陷识别难度。灰盒测试仍然依赖于系统抛出异常的程度，以及在分布式 Web 服务环境中这些异常的传播程度。

Web 服务固有的分布式特性以及对源代码或程序二进制文件的访问缺失，使得在 SOA 中进行白盒测试变得不可能。WSDL 作为基于 Web 服务的 SOA 中消费者和生产者之间的事实契约，提供了丰富的信息来构建智能高效的灰盒测试。WSDL 提供了丰富的信息来构建和自动化这些测试，以改进 Web 服务部署。

三、将灰盒推向白盒测试

通过 WSDL——Web 服务 API——测试人员可以深入了解 Web 服务的协议、数据类型、操作预期和错误处理能力。可以编写和运行智能高效的灰盒测试，以根据 WSDL 中提供的信息确定缺陷。然而，对于提高测试效率，迫切需要根据可用信息自动化测试生成过程。

XSD-Mutation™ 是 Crosscheck Networks 的 SOAPSonar™ Enterprise 产品中一项正在申请专利的自动化技术。利用 WSDL 中的信息，可以生成一系列正面和负面的测试用例，以发现目标 Web 服务中的缺陷。测试变异可能发生在数据类型、数据值、消息结构或协议绑定级别。虽然 WSDL 未显示内部编程信息，例如两个操作的相对异常处理能力，但通过变异生成的测试，可以快速揭示应用程序异常处理的代码逻辑和健壮性。

使用这些技术，可以在不访问源代码或二进制文件的情况下，对 Web 服务进行彻底的测试。在黑盒-白盒测试光谱上，此类测试技术将中间的灰盒测试推向了更接近白盒测试的端点，而无需承担相应的成本或侵入性。此外，鉴于在分布式 Web 服务 SOA 中白盒测试甚至不是一种选择，唯一可行的选择是首先从灰盒测试开始，并使用 SOAPSonar™ 等自动化工具将灰盒推向白盒测试。变异技术为测试光谱增加了新的测试“频率”，使测试用例更接近完整的白盒“频率”集。

四、总结与建议

基于 Web 服务的 SOA 在促进不同部门或贸易伙伴的异构应用程序集成方面发挥着重要作用，从而提高业务生产力。Web 服务的分布式特性使得灰盒测试成为检测 SOA 内部缺陷的理想选择。黑盒测试提供了快速的功能测试，可用于分布式服务；然而，由于黑盒测试的“盲目”性质，测试覆盖率有限、效率低下且冗余。白盒测试对于 Web 服务来说不切实际，因为在 Web 服务部署中通常无法访问源代码或二进制文件。通过利用 WSDL 文件提供的丰富信息，可以生成智能高效的灰盒测试。此外，可以使用诸如消息变异等先进技术来自动生成大量的测试，这些测试可以在不访问源代码或二进制文件的情况下提取程序内部信息——异常处理、状态、流程。这些技术将灰盒测试推向了更接近白盒测试的结果，而无需应对其成本或侵入性。

五、关于 Crosscheck Networks SOAPSonar™

Crosscheck Networks 构建了 SOAPSonar™，为您提供全面、无代码的测试，设置和运行都极其简便。您将在几分钟内生成功能、性能、互操作性和漏洞报告，并通过 SOAPSonar™ 及其正在申请专利的 XSD-Mutation™ 技术利用非侵入性且高效的灰盒测试技术。

• 免费下载 SOAPSonar™ 个人版

联系信息

• 网站：http://www.crosschecknet.com/
• 电子邮件：support@crosschecknet.com
• 电话：1-888-CROSSCK (276-7725)

1617-938-3956（美国以外地区）

<Crosscheck your Web Services/>™