軟件測試之互操作性測試及SOAP協(xié)議實踐策略

趙霞 邱薇 高智杰

第二炮兵裝備研究院科研試驗中心

軟件測試之互操作性測試及SOAP協(xié)議實踐策略

趙霞 邱薇 高智杰

第二炮兵裝備研究院科研試驗中心

互操作性測試作為軟件測試的一種重要測試類型在實踐中易于與其他測試類型混淆，或測試不充分。本文描述了信息系統(tǒng)互操作性等級模型及互操作性測試的三個重要特征，并以SOAP協(xié)議測試為例，給出了互操作性測試從概念到實踐的關(guān)鍵技術(shù)。

軟件測試;互操作性測試;SOAP協(xié)議測試

引言

在信息系統(tǒng)領(lǐng)域，互操作性是一個很寬泛的概念。目前的信息系統(tǒng)主要基于計算機系統(tǒng)，因此，按照計算機系統(tǒng)機構(gòu)來劃分，信息系統(tǒng)的互操作性一般包括了硬件和軟件兩部分的互操作性問題。

IEEE標(biāo)準(zhǔn)化術(shù)語集給出的互操作性定義是：兩個或多個系統(tǒng)或系統(tǒng)組件交換并使用所交換信息的能力。

我軍目前對互操作性所做的定義是：兩個或多個系統(tǒng)或應(yīng)用之間交換信息并相互利用所交換的信息的能力[1]。

互操作性的三個本質(zhì)特征：一、發(fā)生在兩個或兩個以上的實體之間，二、系統(tǒng)間能夠交換信息，三、系統(tǒng)間能夠利用所交換的信息。

1 信息系統(tǒng)互操作性等級模型

工程實踐的經(jīng)驗表明, 問題領(lǐng)域的抽象模型對系統(tǒng)的創(chuàng)建和維護具有重要的參考價值。2003 年, Tolk提出了概念互操作性等級模型LCIM, 形成了概念域的5層互操作性等級模型[2]，見下表1:

表1 信息系統(tǒng)互操作性等級模型

表 1（續(xù)）

2 SOAP協(xié)議互操作性測試實例

SOAP 是一種簡單的基于 XML 的協(xié)議，它使應(yīng)用程序通過 HTTP 來交換信息。它提供了一種標(biāo)準(zhǔn)的方法，使得運行在不同的操作系統(tǒng)并使用不同的技術(shù)和編程語言的應(yīng)用程序可以互相進行通信[3]。

協(xié)議的互操作性測試檢查兩個協(xié)議實現(xiàn)之間的兼容程度，協(xié)議一致性測試對協(xié)議實現(xiàn)的約束仍是功能性的，未精確到足以保證協(xié)議實現(xiàn)之間的互相可操作性，因為不同的協(xié)議實現(xiàn)對PDU的數(shù)據(jù)結(jié)構(gòu)，參數(shù)的選取，尤其是參數(shù)值域的選定可能不相同。另外，協(xié)議的定義規(guī)范中對例外事件的處理規(guī)定往往不夠全面，這是因為異常交互序列數(shù)量龐大，不亦枚舉，所以實現(xiàn)者對異常的處理也不同[4]。

為測試SOAP協(xié)議的互操作性，選取了以下SOAP 服務(wù)器：

·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 語法、數(shù)據(jù)類型等方面的內(nèi)容。協(xié)議互操性測試的內(nèi)容并不局限于此，本文只是針對典型狀況進行描述。

2.1 傳輸

SOAP 1.1 規(guī)范允許在 HTTP 請求中發(fā)送 SOAP 消息。SOAP 規(guī)范將必選的SOAPAction 頭添加到 HTTP 請求頭中。SOAPAction 頭的合法取值包括：

·空；

·一個用引號括起來的空字符串；

·任意的 URI；

為了研究這些互操作性問題，向SOAP 服務(wù)器發(fā)送一個請求并且在接收到時顯示服務(wù)器響應(yīng)。在更改 SOAPAction頭的值之后將簡單的 SOAP 請求發(fā)送給不同的服務(wù)器，從而查看服務(wù)器如何支持SOAP 1.1 規(guī)范所允許的三種頭。

靈活性使 SOAP 實現(xiàn)能夠選擇它們自己的 SOAPAction 樣式及其功能。同時引發(fā)了互操作性問題。

2.2 XML Schema

各種 SOAP 服務(wù)器對編制 SOAP 請求的過程中所使用的不同的 XML Schema版本表現(xiàn)出的行為往往不同。

對大量服務(wù)器進行了名稱空間 URI 支持測試，發(fā)現(xiàn) IONA XMLBus 不能成功處理 1999 URI，但是卻向使用 2001 URI的請求返回了一個成功的響應(yīng)。因此，IONA XMLBus 中的支持被限制為 2001 XML Schema 名稱空間 URI。

2.3 數(shù)據(jù)類型

數(shù)據(jù)類型兼容性可能是 SOAP 互操作性中最重要的問題。如果兩個應(yīng)用程序不能理解彼此的數(shù)據(jù)類型，那么它們就不能執(zhí)行有意義的數(shù)據(jù)交換，從而也就不能互操作。

使用 SOAP 進行傳遞的數(shù)據(jù)首先被序列化；即，數(shù)據(jù)值被轉(zhuǎn)換成字符串以在XML 文檔中傳送。在目的地，這個字符串必須被反序列化，即，被轉(zhuǎn)換成表示原來的值的數(shù)據(jù)類型。

將 XML Schema 數(shù)據(jù)類型映射到適當(dāng)?shù)谋緳C數(shù)據(jù)類型是由 SOAP 實現(xiàn)負責(zé)的。如果兩個本機數(shù)據(jù)類型不一致，即，此時 XML 中的同一種數(shù)據(jù)類型在不同的實現(xiàn)中有不同的值，就可能產(chǎn)生問題。

Float（浮點） 與 float 有關(guān)的常見問題出現(xiàn)在無窮大的表示上。XML Schema用字符串 INF 表示無窮大。在請求中將 INF 作為 float 無窮大發(fā)送，Apache SOAP 2.2 服務(wù)器以 Infinity 返回它，而Apache Axis 則返回 INF。

通過發(fā)送 SOAP 請求對 MS SOAP Toolkit 3.0 服務(wù)器進了測試。它返回一個服務(wù)器端的故障代碼，且不能將float 無窮大值 INF 反序列化，如同故障字符串 “SoapMapper:Converting data for SoapMapper failed inside the typemapper” 所指出的那樣。

另一個問題與 float 精度支持有關(guān)。把 1.23456789E38 作為 float 發(fā)送給幾臺 SOAP 服務(wù)器。IONA XMLBus 返回1.23456789E38，White Mesa 2.7 服務(wù)器返回 1.234568E38，而 MS SOAP ToolKit 3.0 服務(wù)器返回 1.23456786051167E+38。盡管這指出了各個實現(xiàn)正在進行互操作的事實，但是這些實現(xiàn)仍然不能將數(shù)據(jù)重新生成為它的原始值。

Decimal（十進制） 對于 decimal ，XML Schema 規(guī)范要求實現(xiàn)要支持的最少位數(shù)是 18 位。因為在規(guī)范中沒有定義上限，所以各個實現(xiàn)可以隨意設(shè)置它們的上限。Microsoft ASP.NET Web Services和 WhiteMesa 2.7 給出的精度最多達 28位，而 Apache Axis 可以精確支持數(shù)百位。這種支持上的差異意味著，當(dāng)一個Apache Axis 實現(xiàn)向 WhiteMesa 2.7 實現(xiàn)發(fā)送一些大小超過 28 位的 decimal 數(shù)字時，額外的精度將被截斷，從而造成數(shù)據(jù)不一致。

DateTime（日期時間） XML Schema中用于時間和日期信息的數(shù)據(jù)類型是dateTime 。White Mesa 2.7 給出的精度為秒。Apache SOAP 2.2 和 Apache Axis 用 java.util.Date 類表示一個特定的時間實例，精度為毫秒。Microsoft ASP.NET Web Services 使用 Date 類型，該類型可以表示精度為納秒的時間。

一個基于.NET 的 SOAP 客戶機端實現(xiàn)向 SOAP 2.2 實現(xiàn)或 White Mesa 2.7 實現(xiàn)發(fā)送 dateTime 信息， dateTime中額外的精度將被丟失，從而導(dǎo)致數(shù)據(jù)不一致性。在 XML Schema 中，精度達到秒是強制性的，而秒的小數(shù)部分則是可選的且合法的。

字節(jié)數(shù)組（Byte Array） SOAP 允許以字節(jié)數(shù)組的形式交換數(shù)據(jù)。字節(jié)數(shù)組在被放入一個 XML 文檔中之前，它必須是base64 編碼的。由于本機數(shù)據(jù)類型格式的差異，一些實現(xiàn)返回的是不一致的值。一些實現(xiàn)通過對已經(jīng)進行 base64 編碼的值進一步進行 base64 編碼來返回值。

測試得出，當(dāng) Apache SOAP 2.2 和IONAXMLBus 交換 base64 編碼的字節(jié)數(shù)組時，存在互操作性問題。

數(shù)組（Array） 數(shù)組形式的數(shù)據(jù)對實現(xiàn)來說是一個困難的測試，尤其是當(dāng)情形復(fù)雜，使用嵌套的數(shù)組、多維數(shù)組以及嵌套結(jié)構(gòu)（struct）時。

struct 是一種復(fù)雜的、用戶定義的數(shù)據(jù)類型，它可以包含簡單的或更復(fù)雜的數(shù)據(jù)類型。具有 C 語言編程經(jīng)驗的讀者可能會想在 C struct 和 XML Schema struct 之間做一個類比。 測試表明所有 SOAP 實現(xiàn)對于簡單類型和復(fù)雜類型的數(shù)組都沒有問題。

在 SOAP 中，還有其它可能引發(fā)互操作性問題的地方。這些問題可能會因引擎無法處理 mustUnderstand SOAP 頭而顯露出來。

3 結(jié)語

目前，互操作性測試尚不完善，主要表現(xiàn)在：互操作性測試需求和內(nèi)容不夠清晰；缺乏合適的互操作性測試標(biāo)準(zhǔn)；缺乏有效的互操作性測試方法；缺乏權(quán)威的評測、認證機構(gòu)等。

[1]GJB/Z144-2004指揮自動化系統(tǒng)互操作等級及評估

[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服務(wù)的核心技術(shù)之一——SOAP協(xié)議.電子科技，2010年，03期

[4]李華,葉新銘,曾敏,等.基于XM L 的協(xié)議一致性測試系統(tǒng)的設(shè)計與實現(xiàn)[J].計算機科學(xué), 2006, 10: 275～278.

10.3969/j.issn.1001-8972.2012.19.023