软件测试之互操作性测试及SOAP协议实践策略

赵霞 邱薇 高智杰

第二炮兵装备研究院科研试验中心

软件测试之互操作性测试及SOAP协议实践策略

赵霞 邱薇 高智杰

第二炮兵装备研究院科研试验中心

互操作性测试作为软件测试的一种重要测试类型在实践中易于与其他测试类型混淆，或测试不充分。本文描述了信息系统互操作性等级模型及互操作性测试的三个重要特征，并以SOAP协议测试为例，给出了互操作性测试从概念到实践的关键技术。

软件测试;互操作性测试;SOAP协议测试

引言

在信息系统领域，互操作性是一个很宽泛的概念。目前的信息系统主要基于计算机系统，因此，按照计算机系统机构来划分，信息系统的互操作性一般包括了硬件和软件两部分的互操作性问题。

IEEE标准化术语集给出的互操作性定义是：两个或多个系统或系统组件交换并使用所交换信息的能力。

我军目前对互操作性所做的定义是：两个或多个系统或应用之间交换信息并相互利用所交换的信息的能力[1]。

互操作性的三个本质特征：一、发生在两个或两个以上的实体之间，二、系统间能够交换信息，三、系统间能够利用所交换的信息。

1 信息系统互操作性等级模型

工程实践的经验表明, 问题领域的抽象模型对系统的创建和维护具有重要的参考价值。2003 年, Tolk提出了概念互操作性等级模型LCIM, 形成了概念域的5层互操作性等级模型[2]，见下表1:

表1 信息系统互操作性等级模型

表 1（续）

2 SOAP协议互操作性测试实例

SOAP 是一种简单的基于 XML 的协议，它使应用程序通过 HTTP 来交换信息。它提供了一种标准的方法，使得运行在不同的操作系统并使用不同的技术和编程语言的应用程序可以互相进行通信[3]。

协议的互操作性测试检查两个协议实现之间的兼容程度，协议一致性测试对协议实现的约束仍是功能性的，未精确到足以保证协议实现之间的互相可操作性，因为不同的协议实现对PDU的数据结构，参数的选取，尤其是参数值域的选定可能不相同。另外，协议的定义规范中对例外事件的处理规定往往不够全面，这是因为异常交互序列数量庞大，不亦枚举，所以实现者对异常的处理也不同[4]。

为测试SOAP协议的互操作性，选取了以下SOAP 服务器：

·Apache Axis SOAP Server

·Apache SOAP 2.2 Server

·WhiteMesa 2.7 SOAP Server

·IONA XMLBus

·SOAP::Lite

·EasySOAP++

·4S4C

·Microsoft ASP.NET Web Services

测试的范围：传输、XML 语法、数据类型等方面的内容。协议互操性测试的内容并不局限于此，本文只是针对典型状况进行描述。

2.1 传输

SOAP 1.1 规范允许在 HTTP 请求中发送 SOAP 消息。SOAP 规范将必选的SOAPAction 头添加到 HTTP 请求头中。SOAPAction 头的合法取值包括：

·空；

·一个用引号括起来的空字符串；

·任意的 URI；

为了研究这些互操作性问题，向SOAP 服务器发送一个请求并且在接收到时显示服务器响应。在更改 SOAPAction头的值之后将简单的 SOAP 请求发送给不同的服务器，从而查看服务器如何支持SOAP 1.1 规范所允许的三种头。

灵活性使 SOAP 实现能够选择它们自己的 SOAPAction 样式及其功能。同时引发了互操作性问题。

2.2 XML Schema

各种 SOAP 服务器对编制 SOAP 请求的过程中所使用的不同的 XML Schema版本表现出的行为往往不同。

对大量服务器进行了名称空间 URI 支持测试，发现 IONA XMLBus 不能成功处理 1999 URI，但是却向使用 2001 URI的请求返回了一个成功的响应。因此，IONA XMLBus 中的支持被限制为 2001 XML Schema 名称空间 URI。

2.3 数据类型

数据类型兼容性可能是 SOAP 互操作性中最重要的问题。如果两个应用程序不能理解彼此的数据类型，那么它们就不能执行有意义的数据交换，从而也就不能互操作。

使用 SOAP 进行传递的数据首先被序列化；即，数据值被转换成字符串以在XML 文档中传送。在目的地，这个字符串必须被反序列化，即，被转换成表示原来的值的数据类型。

将 XML Schema 数据类型映射到适当的本机数据类型是由 SOAP 实现负责的。如果两个本机数据类型不一致，即，此时 XML 中的同一种数据类型在不同的实现中有不同的值，就可能产生问题。

Float（浮点） 与 float 有关的常见问题出现在无穷大的表示上。XML Schema用字符串 INF 表示无穷大。在请求中将 INF 作为 float 无穷大发送，Apache SOAP 2.2 服务器以 Infinity 返回它，而Apache Axis 则返回 INF。

通过发送 SOAP 请求对 MS SOAP Toolkit 3.0 服务器进了测试。它返回一个服务器端的故障代码，且不能将float 无穷大值 INF 反序列化，如同故障字符串 “SoapMapper:Converting data for SoapMapper failed inside the typemapper” 所指出的那样。

另一个问题与 float 精度支持有关。把 1.23456789E38 作为 float 发送给几台 SOAP 服务器。IONA XMLBus 返回1.23456789E38，White Mesa 2.7 服务器返回 1.234568E38，而 MS SOAP ToolKit 3.0 服务器返回 1.23456786051167E+38。尽管这指出了各个实现正在进行互操作的事实，但是这些实现仍然不能将数据重新生成为它的原始值。

Decimal（十进制） 对于 decimal ，XML Schema 规范要求实现要支持的最少位数是 18 位。因为在规范中没有定义上限，所以各个实现可以随意设置它们的上限。Microsoft ASP.NET Web Services和 WhiteMesa 2.7 给出的精度最多达 28位，而 Apache Axis 可以精确支持数百位。这种支持上的差异意味着，当一个Apache Axis 实现向 WhiteMesa 2.7 实现发送一些大小超过 28 位的 decimal 数字时，额外的精度将被截断，从而造成数据不一致。

DateTime（日期时间） XML Schema中用于时间和日期信息的数据类型是dateTime 。White Mesa 2.7 给出的精度为秒。Apache SOAP 2.2 和 Apache Axis 用 java.util.Date 类表示一个特定的时间实例，精度为毫秒。Microsoft ASP.NET Web Services 使用 Date 类型，该类型可以表示精度为纳秒的时间。

一个基于.NET 的 SOAP 客户机端实现向 SOAP 2.2 实现或 White Mesa 2.7 实现发送 dateTime 信息， dateTime中额外的精度将被丢失，从而导致数据不一致性。在 XML Schema 中，精度达到秒是强制性的，而秒的小数部分则是可选的且合法的。

字节数组（Byte Array） SOAP 允许以字节数组的形式交换数据。字节数组在被放入一个 XML 文档中之前，它必须是base64 编码的。由于本机数据类型格式的差异，一些实现返回的是不一致的值。一些实现通过对已经进行 base64 编码的值进一步进行 base64 编码来返回值。

测试得出，当 Apache SOAP 2.2 和IONAXMLBus 交换 base64 编码的字节数组时，存在互操作性问题。

数组（Array） 数组形式的数据对实现来说是一个困难的测试，尤其是当情形复杂，使用嵌套的数组、多维数组以及嵌套结构（struct）时。

struct 是一种复杂的、用户定义的数据类型，它可以包含简单的或更复杂的数据类型。具有 C 语言编程经验的读者可能会想在 C struct 和 XML Schema struct 之间做一个类比。 测试表明所有 SOAP 实现对于简单类型和复杂类型的数组都没有问题。

在 SOAP 中，还有其它可能引发互操作性问题的地方。这些问题可能会因引擎无法处理 mustUnderstand SOAP 头而显露出来。

3 结语

目前，互操作性测试尚不完善，主要表现在：互操作性测试需求和内容不够清晰；缺乏合适的互操作性测试标准；缺乏有效的互操作性测试方法；缺乏权威的评测、认证机构等。

[1]GJB/Z144-2004指挥自动化系统互操作等级及评估

[2]Tolk,Andreas.Compos able Mission Spaces and M&S Repositories-Applicability of Open Standards [A].2004 Spring Simulation Interoperability Workshop, Orlando Florida,2004.

[3]张仙伟，张璟.Web服务的核心技术之一——SOAP协议.电子科技，2010年，03期

[4]李华,叶新铭,曾敏,等.基于XM L 的协议一致性测试系统的设计与实现[J].计算机科学, 2006, 10: 275～278.

10.3969/j.issn.1001-8972.2012.19.023