SoapUI 快速指南

---

---

SOAP - 簡介

SOAP 是 Simple Object Access Protocol 的縮寫。它由全球資訊網聯盟 (W3C) 在 https://www.w3.org/TR/2000/NOTE-SOAP-20000508 中定義如下：

SOAP 是一種用於在分散的分散式環境中交換資訊的輕量級協議。它是一種基於 XML 的協議，包含三個部分：一個信封，用於定義描述訊息內容和如何處理訊息的框架；一組編碼規則，用於表達應用程式定義的資料型別的例項；以及表示遠端過程呼叫和響應的約定。

SOAP - 重要特性

以下是 SOAP 的一些重要特性。

• 它是一種旨在透過網際網路進行通訊的通訊協議。

• 它可以擴充套件 HTTP 用於 XML 訊息傳遞。

• 它為 Web 服務提供資料傳輸。

• 它可以交換完整文件或呼叫遠端過程。

• 它可以用於廣播訊息。

• 它既獨立於平臺，也獨立於語言。

• 它是定義傳送什麼資訊以及如何傳送資訊的 XML 方式。

• 它使客戶端應用程式能夠輕鬆連線到遠端服務並呼叫遠端方法。

儘管 SOAP 可用於各種訊息傳遞系統，並且可以透過各種傳輸協議傳遞，但 SOAP 的初始重點是透過 HTTP 傳輸的遠端過程呼叫。其他框架（如 CORBA、DCOM 和 Java RMI）提供了與 SOAP 類似的功能，但 SOAP 訊息完全用 XML 編寫，因此具有獨特的平臺和語言獨立性。

SOAP - 訊息

SOAP 訊息是一個普通的 XML 文件，包含以下元素：

• 信封 - 定義訊息的開始和結束。它是一個必選元素。

• 頭部 - 包含訊息的任何可選屬性，這些屬性用於在中間點或最終終點處理訊息。它是一個可選元素。

• 主體 - 包含構成正在傳送的訊息的 XML 資料。它是一個必選元素。

• 錯誤 - 一個可選的 Fault 元素，提供有關在處理訊息期間發生的錯誤的資訊。

所有這些元素都在 SOAP 信封的預設名稱空間中宣告：

https://www.w3.org/2001/12/soap-envelope

SOAP 編碼和資料型別的預設名稱空間為：

https://www.w3.org/2001/12/soap-encoding

注意 - 所有這些規範都可能發生變化。因此，請隨時更新 W3 網站上提供的最新規範。

SOAP - 訊息結構

以下程式碼塊描述了 SOAP 訊息的一般結構：

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope> 

SOAP - 什麼是 REST？

REST 是 Representational State Transfer 的縮寫。它可以定義為一種設計軟體的架構風格。REST 不是規範或 W3C 標準。因此，使用 RESTful 服務更容易。它不需要任何中介軟體規範框架。

REST - 重要特性

以下是 REST 的一些重要特性。

• 它依賴於無狀態、客戶端-伺服器、可快取的通訊協議 - 幾乎在所有情況下都使用 HTTP。

• 它是 Web 服務和 RPC（遠端過程呼叫）如 SOAP-WSDL 的輕量級替代方案。

• 它用唯一的 ID 或 URI 表示所有內容。

• 它使用標準的 HTTP 方法，例如 GET、POST、PUT、DELETE。

• 它將源連結在一起。

• REST 資源可以有多種表示形式。

• 任何命名資訊都被視為資源。例如：影像、人員、文件，都可以被視為資源示例，並表示為唯一的 ID 或 URI。

• 基於 HTTP 的全球資訊網本身可以被視為基於 REST 的架構。

REST 服務獨立於平臺和語言。由於它基於 HTTP 標準，因此它可以在防火牆存在的情況下輕鬆工作。與 Web 服務一樣，REST 沒有提供任何內建的安全、會話管理、QoS 保證，但可以透過構建在 HTTP 之上的方式來新增這些功能。對於加密，REST 可以用於 HTTPS 之上。

SoapUI - 簡介

SoapUI 是一種可用於功能和非功能測試的工具。它不僅限於 Web 服務，儘管它是 Web 服務測試中事實上的工具。

SoapUI - 重要特性

以下是 SoapUI 的一些重要特性。

• 它能夠充當客戶端和服務的角色。

• 它使使用者能夠使用單個環境快速有效地建立功能和非功能測試。

• 它根據 GNU Leaser 通用公共許可證 (LGPL) 的條款獲得許可。

• 它完全使用 JAVA 平臺實現。

• 它支援 Windows、Mac、多種 Linux 版本。

• 它允許測試人員在不同的 Web API 上執行自動化的功能、迴歸、合規性和負載測試。

• 它支援所有標準協議和技術來測試各種 API。

SoapUI 可用於測試完整的 RESTful API 和 SOAP Web 服務測試。它支援功能測試、效能測試、互操作性測試、迴歸測試、負載測試等等。

它既使用者友好，又易於將功能測試轉換為非功能測試，例如負載、壓力測試。

SoapUI - 功能

SoapUI 在以下五個方面非常豐富：

• 功能測試
• 安全測試
• 負載測試
• 協議和技術
• 與其他工具整合

讓我們進一步瞭解這些功能。

功能測試

• SoapUI 允許測試人員在 SoapUI 中編寫功能性 API 測試。

• SoapUI 支援拖放功能，從而加快指令碼開發。

• SoapUI 支援除錯測試，並允許測試人員開發資料驅動的測試。

• SoapUI 支援多個環境，從而方便地在 QA、Dev 和 Prod 環境之間切換。

• SoapUI 允許高階指令碼編寫（測試人員可以根據場景開發自定義程式碼）。

安全測試

• SoapUI 執行一整套漏洞掃描。

• SoapUI 防止 SQL 注入以保護資料庫安全。

• SoapUI 掃描由文件大小過大引起的堆疊溢位。

• SoapUI 掃描跨站點指令碼，當服務引數在訊息中公開時發生。

• SoapUI 執行模糊測試和邊界掃描以避免服務的異常行為。

負載測試

• SoapUI 將負載測試分佈到 n 個 LoadUI 代理上。

• SoapUI 可以輕鬆模擬高容量和現實世界的負載測試。

• SoapUI 允許高階自定義報告以捕獲效能引數。

• SoapUI 允許端到端系統效能監控。

協議與技術

SoapUI 支援廣泛的協議：

• SOAP – 簡單物件訪問協議
• WSDL – Web 服務定義語言
• REST – 表述性狀態轉移
• HTTP – 超文字傳輸協議
• HTTPS – 超文字傳輸協議安全
• AMF – Action 訊息格式
• JDBC – Java 資料庫連線
• JMS – Java 訊息服務

與其他工具整合

• Apache Maven 專案
• HUDSON
• JUnit
• Apache - Ant 等等。

SoapUI - NG Pro

SoapUI 是一個具有基本測試功能的開源免費版本工具，而 SoapUI NG Pro 是一款商業化工具，具有高階報告、資料驅動功能等功能。

比較

下表比較了 SoapUI 和 SoapUI NG Pro 的各種功能。

SoapUI - 安裝與配置

SoapUI 是一款跨平臺工具。它支援 Windows、Linux 和 Mac 作業系統。

先決條件

• 處理器 - 1GHz 或更高 32 位或 64 位處理器。

• RAM - 512MB RAM。

• 硬碟空間 - 安裝至少需要 200MB 硬碟空間。

• 作業系統版本 - Windows XP 或更高版本，MAC OS 10.4 或更高版本。

• JAVA - JAVA 6 或更高版本。

下載過程

步驟 1 - 訪問 www.soapui.org 並點選下載 SoapUI。

步驟 2 - 點選“獲取”下載 SoapUI 開源版。它將開始在系統中下載 112MB 的 .exe 檔案。等待下載過程完成。

安裝過程

步驟 1 - 下載後，以“以管理員身份執行”的方式執行 .exe 檔案。

Windows 將啟動安裝過程，如下面的螢幕截圖所示。

步驟 2 - 安裝完成後，過程視窗將顯示以下螢幕，點選下一步。

步驟 3 − 接受許可協議並點選下一步。

步驟 4 − 選擇安裝目錄或保留系統選擇的預設路徑。點選下一步。

步驟 5 − 選擇要安裝的元件。點選下一步。

步驟 6 − 接受 HermesJMS 的許可協議並點選下一步。

步驟 7 − 選擇儲存教程的目標目錄並點選下一步。

步驟 8 − 選擇開始選單資料夾位置，或者保留預設位置，然後點選“下一步”。

步驟 9 − 啟用“建立桌面圖示”複選框並點選“下一步”。

現在，安裝開始。完成安裝需要幾分鐘。

步驟 10 − 安裝完成後，在以下向導中點選完成。

點選完成之後，SoapUI 將啟動。

• 選單欄
• 工具欄
• 專案導航欄
• 工作區屬性
• 日誌面板

配置過程

第一步是建立一個可以包含多個專案的的工作區。

步驟 1 − 轉到檔案 → 新建工作區。

步驟 2 − 新增工作區名稱並點選確定。

步驟 3 − 現在，選擇儲存工作區 xml 的路徑。

步驟 4 − 選擇路徑並點選儲存。

工作區建立如下面的螢幕截圖所示。還顯示了工作區屬性。

SoapUI - WSDL

WSDL 代表 Web 服務描述語言。它是一種描述 Web 服務的標準格式。WSDL 由微軟和 IBM 共同開發。WSDL 發音為“wiz-dull”，拼寫為“W-S-D-L”。

WSDL ─ 簡史

2001 年 3 月，Ariba、IBM 和微軟將 WSDL 1.1 作為 W3C 說明提交給 W3C XML 活動，用於描述 XML 協議的服務。

WSDL 1.1 尚未獲得全球資訊網聯盟 (W3C) 的認可，但它剛剛釋出了 2.0 版的草案，該草案將成為建議 (正式標準)，並因此獲得 W3C 的認可。

WSDL ─ 注意要點

WSDL 是一種基於 XML 的協議，用於在分散和分散式環境中進行資訊交換。WSDL 的其他一些功能如下：

• WSDL 定義描述瞭如何訪問 Web 服務以及它將執行哪些操作。

• 它是一種用於描述如何與基於 XML 的服務互動的語言。

• 它是通用描述、發現和整合 (UDDI) 的組成部分，UDDI 是一個基於 XML 的全球業務註冊中心。

• WSDL 是 UDDI 使用的語言。

WSDL 用法

WSDL 通常與 SOAP 和 XML Schema 結合使用，以透過網際網路提供 Web 服務。連線到 Web 服務的客戶端程式可以讀取 WSDL 以確定伺服器上有哪些可用功能。使用的任何特殊資料型別都以 XML Schema 的形式嵌入到 WSDL 檔案中。然後，客戶端可以使用 SOAP 實際呼叫 WSDL 中列出的其中一個函式。

理解 WSDL

WSDL 將 Web 服務分解成三個特定且可識別的元素，這些元素一旦定義即可組合或重用。

WSDL 的三個主要元素可以分別定義為：

• 型別
• 操作
• 繫結

WSDL 文件包含各種元素，但它們包含在這三個主要元素中，這些元素可以作為單獨的文件開發，然後可以組合或重用以形成完整的 WSDL 檔案。

在本教程中，我們使用 CurrencyConverter WSDL：http://www.webservicex.net

格式和元素

CurrencyConverter WSDL 將如下所示：

WSDL ─ 埠型別

<portType> 元素將多個訊息元素組合成一個完整的一路或往返操作。例如，<portType> 可以將一個請求訊息和一個響應訊息組合成一個請求/響應操作。這最常用於 SOAP 服務。portType 可以定義多個操作。

示例

• portType 元素定義了一個名為 ConversionRate 的單個操作。
• 該操作包含一個輸入訊息 ConversionRateHttpPostIn。
• 輸出訊息的操作為 ConversionRateHttpPostOut。

操作模式

WSDL 支援四種基本的操作模式：

單向

服務接收一條訊息。因此，該操作只有一個輸入元素。單向操作的語法為：

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

請求 ─ 響應

服務接收一條訊息併發送響應。因此，該操作包含一個輸入元素，後跟一個輸出元素。為了封裝錯誤，還可以指定一個可選的故障元素。請求-響應操作的語法為：

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

請求 ─ 響應

服務傳送一條訊息並接收響應。因此，該操作包含一個輸出元素，後跟一個輸入元素。為了封裝錯誤，還可以指定一個可選的故障元素。請求-響應操作的語法為：

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

通知

服務傳送一條訊息。因此，該操作只有一個輸出元素。以下是通知操作的語法：

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

WSDL ─ 繫結 & 服務

<binding> 元素提供了有關 portType 操作如何實際透過網路傳輸的具體詳細資訊。

• 繫結可以透過多種傳輸方式提供，包括 HTTP GET、HTTP POST 或 SOAP。

• 繫結提供了有關用於傳輸 portType 操作的協議的具體資訊。

• 繫結提供了服務所在位置的資訊。

• 對於 SOAP 協議，繫結為 <soap:binding>，傳輸是在 HTTP 協議之上的 SOAP 訊息。

• 您可以為單個 portType 指定多個繫結。

服務

<service> 元素定義了 Web 服務支援的埠。對於每個支援的協議，都有一個埠元素。service 元素是埠的集合。

Web 服務客戶端可以從 service 元素中瞭解以下內容：

• 在哪裡訪問服務，
• 透過哪個埠訪問 Web 服務，以及
• 通訊訊息是如何定義的。

service 元素包含一個 documentation 元素，用於提供人類可讀的文件。

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service> 

SoapUI - 專案

SoapUI 專案是所有 SoapUI 測試的中心點。建立專案後，使用者可以建立和執行功能測試、負載測試、建立模擬服務等等。

在本章中，我們將討論兩件事 - 如何：

• 建立 SOAP 專案
• 新增 WSDL

建立 SOAP 專案

步驟 1 − 在螢幕左側的導航器中，右鍵單擊“專案”並選擇“新建 SOAP 專案”。

或者轉到檔案並選擇新建 Soap 專案。

選擇後，將開啟一個新的彈出視窗 - 新建 Soap 專案。

步驟 2 − 專案名稱：輸入專案名稱 - 它是使用者輸入欄位。初始 WSDL：這不是強制性的。這取決於使用者。使用者可以提供 WSDL 或在建立專案後新增。

在本例中，我們建立了一個專案並在稍後添加了 WSDL。

步驟 3 − 點選確定。它將建立一個新專案，並且將在左側導航面板上可見。

新增 WSDL

SOAP 專案基於 WSDL。不必從匯入 WSDL 開始，但它使測試更容易，因為 WSDL 包含測試 Web 服務所需的所有資訊，例如有關請求和響應的資訊、它們包含的內容等等，從而簡化了 SoapUI 測試。

步驟 1 − 要新增 WSDL，請右鍵單擊專案名稱 (SOAP – Example) 並選擇新增 WSDL。

選擇後，將顯示 WSDL 嚮導。

步驟 2 − WSDL 位置：輸入 WSDL 作為 http://www.webservicex.com 或從計算機中瀏覽它。

步驟 3 − 一旦輸入 WSDL，3 個複選框 - 建立請求、建立測試套件、建立模擬服務將被啟用。根據需求，使用者可以選中一個或多個複選框。

預設情況下，選中建立請求的複選框。

步驟 4 − 點選確定。WSDL 已成功新增到專案中。可以透過觀察左側導航面板進行驗證。在專案內部，有多個操作，並且根據 WSDL 添加了請求。

詳細資訊檢視

要獲取專案的更多詳細資訊，請雙擊專案名稱，它將開啟一個包含各種詳細資訊的新視窗。

在概述選項卡中，提供了各種資訊，例如：

• 檔案路徑 − 它顯示儲存的專案 xml 的位置。

• 介面摘要 − 與之關聯的介面名稱和 WSDL。

• 測試摘要 − 它顯示新增到專案的測試套件、測試用例、測試步驟、斷言。

使用者可以雙擊介面名稱以獲取介面詳細資訊。它將開啟一個新視窗並顯示與 WSDL 相關的資訊。這些資訊對於瀏覽和檢查 WSDL 非常有用。

在概述選項卡中，它列出了 WSDL 定義、定義部分和操作詳細資訊。

同樣，服務端點列出了端點的詳細資訊。

在 WSDL 內容選項卡中，提供了 XML/schema 格式的 WSDL 的所有詳細資訊，如下面的螢幕截圖所示。

SoapUI - 測試套件

測試套件是測試用例的集合，可用於將功能測試分組到邏輯單元中。可以在 SoapUI 專案中建立任意數量的測試套件以支援大量的測試場景。

測試套件的建立

步驟 1 − 在專案中，右鍵單擊介面（專案名稱旁邊），然後單擊“生成測試套件”。

這裡，SOAP – Example 是專案名稱，而 CurrencyConvertorSoap 和 CurrencyConvertorSoap12 是介面。

步驟 2 − 將開啟一個新的嚮導。根據需求選擇選項。

步驟 3 − 完成選擇後，點選確定。

步驟 4 − 選中生成負載測試的複選框。這將為在此測試套件中建立的每個測試用例生成一個負載測試。

步驟 5 − 在新的嚮導中輸入測試套件名稱，然後點選確定。

建立的測試套件顯示在導航面板中，如下面的螢幕截圖所示。

步驟 6 − 雙擊測試套件名稱，測試套件視窗將在右側面板開啟。由於沒有新增測試用例，因此它是空白的。

測試套件屬性可以在導航面板底部檢視。可以在測試套件級別新增新的自定義屬性。

SoapUI - 測試用例

測試用例是一組用於測試 Web 服務某些特定方面的測試步驟的集合。使用者可以向測試套件新增 n 個測試用例，甚至可以將它們模組化以相互呼叫，以實現複雜的測試場景。

建立測試用例

步驟 1 − 在測試套件中，使用者可以新增多個測試用例。右鍵單擊測試套件並選擇“新建測試用例”。

步驟 2 − 輸入測試用例的名稱，然後單擊“確定”。

建立的測試用例目前沒有測試步驟。所有型別的可用測試都添加了零測試步驟的測試用例。新增測試步驟後，括號中的數字將自動更改。功能測試步驟應進入“測試步驟”，而效能測試步驟應進入“負載測試”，安全測試步驟應進入“安全測試”。

步驟 3 − 雙擊測試用例名稱，右側面板上將開啟一個測試用例視窗。由於沒有新增測試步驟，因此它為空白，如下面的螢幕截圖所示。

SoapUI - 測試步驟

測試步驟是 SoapUI 中功能測試的“構建塊”。它們被新增到測試用例中，用於控制執行流程並驗證要測試的 Web 服務的功能。

插入測試步驟

步驟 1 − 右鍵單擊測試步驟。新增步驟並從列表中選擇一個合適的測試步驟。例如，如果使用者必須測試 REST Web 服務，則使用者將選擇 REST 測試請求。

步驟 2 − 透過選擇“測試步驟”→“新增步驟”→“SOAP 請求”來新增一個測試步驟以驗證匯入的 SOAP 請求。

步驟 3 − 在嚮導中輸入測試步驟的名稱，然後單擊“確定”。

單擊“確定”後，將彈出一個對話方塊以選擇要呼叫的操作。列出了所有操作，使用者可以選擇他們想要呼叫的操作。

將列出兩個操作。這兩個操作都相同，只是使用的 SOAP 版本不同。CurrencyConvertorSoap 使用 SOAP 版本 1.1，而 CurrencyConvertorSoap12 使用 SOAP 版本 1.2。

步驟 4 − 選擇第一個 – CurrencyConvertorSoap 並單擊“確定”。

在新增測試用例時，可以新增不同的標準斷言。斷言也稱為 SOAP 請求/響應的檢查點/驗證點。

步驟 5 − 讓我們建立一個具有預設選項的測試用例，這意味著建立一個沒有任何以下驗證點的測試步驟：

• 執行測試後，驗證響應訊息是否為 SOAP。
• 驗證響應架構是否有效。
• 驗證 SOAP 響應是否包含 FAULT。

步驟 6 − 單擊“確定”後，將彈出以下請求 XML 螢幕截圖。

由於添加了功能測試步驟，因此測試步驟計數現在增加到 1。類似地，在新增負載和安全測試步驟後，相應的數字會根據新增的步驟數量自動增加。

SoapUI - 請求與響應

請求設定

在這裡，我們將執行將貨幣從 INR 轉換為 USD 的操作。

• FromCurrency – INR
• ToCurrency – USD

接下來，將這些輸入輸入到問號所在的位置，這些輸入將作為請求 XML 傳送。將這些值放入相應的 XML 標籤後，單擊“提交請求”按鈕以檢查響應。

響應

提交請求後，Web 服務請求將由 Web 伺服器處理併發送回響應，如下面的螢幕截圖所示。

透過讀取響應，可以得出結論，1 個 INR 單位 = 0.0147 個 USD 單位。

HTTP 請求

SOAP 訊息透過 HTTP 協議傳輸。要檢視 HTTP 請求，請單擊 SoapUI 請求視窗（左側）中的“RAW”。

請求釋出到 Web 伺服器。因此，使用 Http 的 POST 方法。

SOAP 請求在 http 訊息的主體中傳輸，如下所示。

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5) 

HTTP 響應

單擊 SOAP-UI 響應視窗中的“RAW”選項卡以瞭解響應如何透過 HTTP 傳送。

處理請求後，將顯示 http 響應程式碼 (200)，這意味著它是成功的。Web 伺服器已成功處理它。

SOAP 響應作為 HTTP 訊息主體的一部分發送回客戶端。

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316 

以下 HTTP 程式碼用於 Web 伺服器傳送響應，對於除錯非常有用。

SoapUI - 屬性

屬性是使用 SoapUI 進行更高階測試的核心方面。功能測試屬性用於引數化測試的執行和功能。

• 屬性可用於儲存服務的端點，從而可以輕鬆更改測試執行期間使用的實際端點。

• 屬性可用於儲存身份驗證憑據，從而可以輕鬆地在中心位置或外部檔案中管理這些憑據。

• 屬性可用於在測試執行期間傳輸和共享會話 ID，以便多個測試步驟或測試用例可以共享相同的會話。

定義屬性

可以在專案的多個級別定義屬性。

• 可以在專案級別定義專案級通用的屬性。

• 類似地，可以在其各自的級別定義測試套件和測試用例特定的屬性。

• 專案特定屬性在“自定義屬性”選項卡中定義。

例如，可以透過單擊“+”符號並輸入屬性名稱和值來在專案級別定義屬性“ToCurrency”。

訪問屬性

可以使用屬性擴充套件在專案的任何位置訪問屬性。

結構如下：

• ${#Project#PropertyName} – 適用於專案級別

• ${#TestSuite#PropertyName} – 適用於測試套件級別

• ${#TestCase#PropertyName} – 適用於測試用例級別

• ${TestStepName#PropertyName} – 適用於測試步驟級別

• ${#MockService#PropertyName} – 適用於模擬服務屬性

• ${#Global#PropertyName} – 適用於全域性屬性，位於“檔案”→“首選項”→“全域性屬性”選項卡中。此屬性可在所有專案中使用

• ${#System#PropertyName} – 適用於系統屬性，位於“幫助”→“系統屬性”中

• ${#Env#PropertyName} – 適用於環境變數

相同的結構可以放在請求 XML 中，以便在執行時獲取特定屬性的值。

屬性也可以被視為計算機程式中的變數。如果使用者想要定義一些可以在其他地方使用的內容，則屬性非常有用。屬性也可以動態定義，但它依賴於 Groovy 指令碼。

SoapUI - 屬性傳遞

有時需要從響應訊息中提取某些值並將其包含在後續請求中。在這種情況下，我們需要有一種機制來檢索指定的值並將其傳輸到專案的其他元素。SoapUI 透過屬性傳輸測試步驟支援此類功能。

新增屬性傳輸

步驟 1 − 選擇測試用例或測試步驟，右鍵單擊→新增步驟→屬性傳輸。

步驟 2 − 輸入測試步驟名稱，然後單擊“確定”。

步驟 3 − 新增 RateTransfer 步驟，並將開啟一個新的嚮導。

步驟 4 − 單擊屬性傳輸視窗左上角的“新增新的屬性傳輸”圖示 +。系統將提示您輸入傳輸的名稱。輸入 Rate 並單擊“確定”。

傳輸屬性

建立傳輸後，源和目標窗格需要指定相關的 XPath 表示式以提取和替換屬性值。在“源”旁邊的下拉框中，列出了可用作屬性傳輸源的 SoapUI 專案的各個級別。預設情況下，將顯示最接近的測試步驟。

在本例中，它是請求 – INR 到 USD測試步驟。在“屬性”旁邊的下拉列表中顯示了傳輸中使用的源屬性，該屬性可以是請求、響應或服務端點。

步驟 1 − 選擇“響應”並轉到“路徑語言”。使用者可以選擇 XPath、Xquery 或 Jason 來定義屬性。在本例中，選擇 XPath。

步驟 2 − 要獲取源 xml 的宣告，請單擊 ns 並指定 XPath。

步驟 3 − 指定要將從上述 XPath 表示式中提取的值傳輸到的目標。為此，請使用屬性傳輸視窗底部的目標窗格。

步驟 4 − 傳輸從 RequestINRtoUSD 步驟的響應中提取的 ConversionRateResult 值。

目標 − 屬性

屬性 − ConversionRate（添加了一個新屬性，最初沒有值）。

步驟 5 − 測試用例成功執行後，屬性“ConversionRate”將根據響應進行更新。

以下是初始螢幕截圖。

以下是成功執行後的螢幕截圖。

類似地，目標可以是下一個請求 XML。如果目標是 SOAP 請求，我們需要提供 XPath 以識別目標屬性。

SoapUI - 日誌面板

日誌窗格儲存有關客戶端和伺服器之間事務的完整資訊。使用者將能夠看到日誌窗格的各個選項卡。在本章中，我們將討論在使用 SoapUI 時最常用的日誌窗格。

SoapUI 日誌

SoapUI 日誌顯示來自 Web 伺服器的響應資訊。相同的資訊儲存在 SOAP-UI 安裝資料夾下的“bin”目錄中的 soapui.log 檔案中。

HTTP 日誌

HTTP 日誌顯示所有 HTTP 資料包傳輸。HTTP 日誌中顯示了“RAW”中的所有資訊。

錯誤日誌

錯誤日誌顯示整個專案會話期間遇到的所有錯誤。相同的資訊可在 SoapUI 安裝位置的“bin”目錄中的“soapui-errors.log”中找到。

記憶體日誌

此選項卡監視記憶體消耗並以圖表的形式顯示它，如下面的螢幕截圖所示。當執行記憶體密集型操作時，它確實很有幫助。

SoapUI - 斷言

斷言可以解釋為檢查點或驗證點。將請求傳送到 Web 伺服器後，將收到響應。需要驗證響應是否包含預期的資料。為了驗證響應，SoapUI 具有斷言功能。

注意事項

• 斷言用於驗證測試步驟在執行期間收到的訊息。

• 它將訊息的一部分或整個訊息與某個預期值進行比較。

• 可以向測試步驟新增任意數量的斷言，每個斷言都驗證響應訊息的某些不同方面和內容。

• 測試步驟執行後，其所有斷言都將應用於收到的響應，如果任何斷言失敗，則測試用例檢視中將標記測試步驟已失敗。

• 測試執行日誌中顯示失敗的條目。

斷言型別

SoapUI 支援響應中的各種斷言。

以下是 SoapUI 支援的斷言列表。

SoapUI - 故障排除

在 SoapUI 中，使用者會遇到許多通用問題，這些問題可以透過一點警惕性解決。以下是一些最常見的問題：

問題 - 名稱空間定義錯誤。使用正確的名稱空間。名稱空間應為 Web 服務所在的 URL。

解決方案 - 如果在開發指令碼斷言時丟擲錯誤，請使用“log.info”列印變數的內容。

問題 - 如果收到錯誤程式碼作為響應 XML，則可能是由於輸入無效。

解決方案 - 驗證請求 XML 的輸入。

示例 - 在貨幣轉換器中，如果“FromCurrency”的輸入為“123”（不存在），則輸出會丟擲錯誤程式碼“SOAP-Client”，這意味著問題出在從客戶端傳遞的引數上。

請求

響應

問題 - 使用 XPath 或 XQuery 時，當前響應中沒有匹配項。

解決方案 -

• 定義 XPath 或 XQuery 時使用正確的語法。
• 驗證在宣告名稱空間時使用了冒號而不是點。
• 確保 XPath 和 XQuery 正確。

SoapUI - 效能測試

效能測試是 Web 服務測試中最常見的關鍵檢查點之一。效能測試定義為人為建立或模擬負載，並衡量環境如何處理它。

這意味著它不一定必須是系統在高負載下的效能表現，它也可以是系統在基本負載或預期負載下的效能表現。它甚至不必是結構化的、自動化的或在 SoapUI 等測試軟體中建立的；簡單地反覆快速重新整理 Web 瀏覽器也是一種負載測試。

效能測試型別

以下是效能測試的型別：

• 基準測試 - 檢查系統在預期或正常負載下的效能，並建立一個基線，其他型別的測試可以以此為參考進行比較。

• 負載測試 - 包括增加負載並檢視系統在更高負載下的行為。在負載測試期間，使用者可以監控響應時間、吞吐量、伺服器狀態等等。負載測試的目標不是破壞目標環境。

• 浸泡測試 - 測試的目標是確保在較長時間內不會出現任何意外行為。

• 可擴充套件性測試 - 可擴充套件性測試與負載測試非常相似，但是它不是增加請求數量，而是增加發送的請求的大小或複雜性。例如，傳送大型請求、大型附件或巢狀很深的請求。

Web 服務的關鍵方面

Web 服務效能的獨特特性有兩個方面脫穎而出。

第一個方面

在伺服器端，正在進行 XML/JSON 處理，包括 XML/JSON 解析和序列化。經常首先失敗的是有效負載的處理。失敗的原因可能是多方面的；它可能存在於平臺、應用程式伺服器的弱點中，也可能是由於 WSDL 不必要地複雜而導致的實現問題。它也可能意味著程式碼正在向響應緩慢的資料庫發出請求。

測試方面 - 解析 XML/JSON 有效負載的複雜性意味著需要額外關注可擴充套件性測試。這也意味著應該仔細檢查 WSDL。如果請求和響應很複雜或很大，或者如果它們包含大型附件，則應重點關注複雜性，並檢視它在負載下的行為。

第二個方面

另一個經常遇到的因素是安全。HTTPS 後面的安全站點效能明顯較低，在 Web 服務測試中，我們可以在 HTTP 安全層上新增一層 WSSecurity，從而進一步降低效能。

測試方面 - 安全問題意味著需要重點進行安全請求的測試。如果整個 Web 服務都是安全的，則意味著負載測試更為重要，尤其是在使用 WS-Security 和令牌處理時。

SoapUI - 負載測試

負載測試是效能測試的一種特定形式，用於評估系統在特定負載下的行為。在 SoapUI 中，我們通常將術語“負載測試”用於所有型別的非功能測試，但 SoapUI 支援 Web 服務的所有型別的效能評估，例如負載、壓力和耐力。

注意事項

• 負載測試在 SoapUI 中非常獨特；它是一個功能測試用例，允許快速建立和修改效能測試。

• 主要的區別在於，SoapUI 中的效能測試通常是從現有的功能測試建立的。這允許快速建立高階效能測試。

• 可以在不同的負載場景下驗證 Web 服務效能。維護功能驗證以確保它們在負載下不會中斷，同時執行多個負載測試以檢視它們如何相互影響等等。

負載測試的建立

步驟 1 - 右鍵單擊功能測試用例，然後選擇“新建負載測試”。

步驟 2 - 在對話方塊嚮導中輸入負載測試的名稱，然後單擊“確定”。

負載測試將開啟，並建立負載測試，如下面的螢幕截圖所示。

負載測試的執行

建立新的負載測試時，它預配置為使用簡單的負載策略執行 60 秒（右上角）並使用 5 個執行緒。

根據需要修改這些值並執行。注意 - 使用者應瞭解負載測試配置和概念。

使用者將在中間看到統計表，從收集資料開始，60 秒後應完成負載測試。

新增斷言

步驟 1 - 在負載測試編輯器中，選擇編輯器底部的“負載測試斷言”選項卡。

步驟 2 - 單擊“負載測試斷言”選單欄中的“新增斷言”按鈕以新增斷言。

步驟 3 - 將開啟“新增斷言”對話方塊。選擇“步驟最大值”。選擇“最大值”設定響應允許花費的最大時間（以毫秒為單位），如果時間超過我們設定的時間，則測試將失敗。單擊“確定”。

步驟 4 - 將開啟“測試步驟最大值斷言”視窗。如以下螢幕截圖所示，我們允許最大響應時間為 1 秒，即 1000 毫秒。我們暫時不修改任何內容。單擊“確定”。

現在將成功新增“步驟最大值”斷言。

步驟 5 - 現在再次執行測試。如果響應花費的時間過長，您應該會看到“err”列中的數字迅速增加。

SoapUI - RESTful Web 服務

Web 服務是一組用於在應用程式或系統之間交換資料的開放協議和標準。用各種程式語言編寫並在各種平臺上執行的軟體應用程式可以使用 Web 服務透過計算機網路（如網際網路）交換資料，其方式類似於單個計算機上的程序間通訊。這種互操作性（例如，Java 和 Python 之間或 Windows 和 Linux 應用程式之間）是由於使用了開放標準。

基於 REST 架構的 Web 服務稱為 RESTful Web 服務。這些 Web 服務使用 HTTP 方法來實現 REST 架構的概念。RESTful Web 服務通常定義一個 URI（統一資源識別符號），它是一個提供資源表示（如 JSON）和一組 HTTP 方法的服務。

SoapUI 的所有 REST 測試功能都基於稱為 REST 服務的邏輯表示。我們不應該將此處的術語“服務”與服務實現混淆，因為它不是服務實現，而是對正在呼叫的 RESTful 服務的對映。我們可以在 SoapUI 專案中新增任意數量的 REST 服務。每個都代表一個特定的 RESTful 服務。它們如下：

• REST - 專案設定

• REST - WADL

• REST - 請求

• REST - 響應

• REST - HTTP 方法

SoapUI - JDBC 連線

SoapUI 允許使用名為 JDBC 請求的測試步驟來管理資料庫操作。

步驟 1 - 右鍵單擊測試步驟，然後選擇“新增步驟”→“JDBC 請求”。

步驟 2 - 輸入步驟名稱，然後單擊“確定”。

JDBC 步驟已新增。雙擊步驟，將開啟 JDBC 嚮導。

要建立 JDBC 連線，使用者需要提供有效的驅動程式和連線字串。這些引數用於識別資料庫型別並建立連線以使用資料庫。

對於 MySQL，資料庫驅動程式可以是com.mysql.jdbc.Driver。類似地，對於其他資料庫，也存在一個預定義的驅動程式，可以在資料庫的文件部分找到。

步驟 3 − 連線字串應採用以下格式 −

Jdbc:mysql://[host]:[port]/[database]?[property][=value] 

這裡，property 是使用者名稱和密碼以及連線到資料庫所需的其它引數。

例如，

jdbc:mysql://:8089/xxx_DB?user=root&password=root 

步驟 4 − 點選測試連線。連線成功後，將顯示 SUCCESS，否則提供失敗的詳細資訊。

SoapUI - JDBC 屬性

JDBC 有自己的新增屬性部分，可以作為 SQL 查詢中的變數使用。

讓我們看看它是如何工作的 −

假設，需要在 JDBC 步驟中執行的 SQL 查詢是 Select * from Currency where CurrencyCode = ‘xxx’。

在這種情況下，CurrencyCode 可以根據請求輸入進行更改。如果使用者提供硬編碼的值，JDBC 步驟將不會對請求中給定的那些貨幣執行。

為了克服這種情況，JDBC 支援新增屬性，其中可以定義一個屬性 Code，並且它將使用屬性傳遞步驟不斷變化。

SQL 查詢將根據屬性 Code 的當前值執行，並且 SQL 查詢將引數化 CurrencyCode =:Code。

點選新增屬性 + 並將名稱設定為 Code，並提供值或保持空白以使用屬性傳遞步驟提供它。

SoapUI - JDBC 斷言

JDBC 請求也可以利用大多數與 SOAP 請求 TestSteps 的斷言。在 SoapUI 中，大多數這些斷言獨立於 TestSteps。因此，諸如 Contains 和 XPath Match 之類的斷言可以與 JDBC Request TestStep 一起使用。

透過點選 JDBC Request TestStep 頂部選單中的新增斷言圖示，使用者可以找出 TestStep 支援哪些斷言。

除了通用斷言之外，還有兩個 JDBC Request TestStep 特定的斷言 −

JDBC 超時 − 此斷言可用於驗證當前 SQL 查詢是否在指定的 Query Timeout 屬性值內執行。

JDBC 狀態 − 為了檢查 SQL 語句是否成功執行，我們可以使用 JDBC 狀態斷言。

要設定查詢超時，請在螢幕左側提供相應的屬性 Query Timeout 值。請記住，它接受以毫秒 (ms) 為單位的值。