採用 SOA 最佳實踐，借鑑經驗教訓

轉自：http://www.ibm.com/developerworks/cn/webservices/ws-SOAbestpractices/index.html

考慮到更高的解決方案協調性和敏捷性，改用面向服務的體系架構 (SOA) 會給企業帶來眾多益處。進行平滑過渡需要特別關注質量，並認識到與 SOA 內的測試相關的獨特挑戰。通常，沒有計劃對測試能力進行必要調整，或調整不夠明顯。組織需要了解與改進服務架構相關的獨特目標和挑戰，並瞭解應當如何執行測試。本文將討論利用 SOA、推薦的最佳實踐和經驗教訓，來解決質量保證難題。

簡介

就和之前的其他專案一樣，人們有興趣處理包含面向服務的體系架構 (SOA) 的專案。然而，考慮到專案表現出的一些獨特的測試挑戰，可能要優化測試實踐，以更好地滿足特定於專案的 QA 要求。第一步是確保開發和測試團隊熟悉專案中將引發獨特挑戰的各方各面。這些方面可能包括：

1. 簡單、易於使用、隱藏了複雜性的介面
2. 開放性，以備將來重用
3. 使用各種配套系統進行實現的技術複雜性

圖 1. 異構連線和複雜性

4. 必要的跨業務協調
5. 可與底層應用程式邏輯區分開的、服務流內部的邏輯性
6. 與配套應用程式安全性不同的服務安全性需求

圖 2. 多處的邏輯和安全性

7. 作為獨立管理的 IT 元件的服務

這些因素獨立或結合起來，都可能導致產生與測試相關的挑戰。本文討論了一些普遍遭遇到的挑戰，以及可用於緩解這些痛苦的最佳實踐。

SOA 測試的獨特挑戰

在 SOA 環境中，測試團隊超越了傳統的以應用程式為中心的功能和效能測試。SOA 需要整合地測試介面和服務，這些介面和服務有助於組合利用不同的系統、平臺以及相關安全標準。

要測試這些應用程式時，就提出了獨特挑戰。

服務可能不具有使用者介面

傳統上，應用程式擁有 GUI 或相關的使用者介面，可用於手動或自動執行功能測試。在 SOA 中，環境服務可能沒有介面。測試員處理不同技術（例如 SOAP 和 Web 服務）下的訊息和網路協議。深度暴露的服務會封裝底層流程，因而要確保充分的測試範圍，這是一種挑戰。

處理 Web 服務時，我們能使用基於標準的測試工具（如 SOAPUI）來應對挑戰。這些工具能夠為服務生成基於 Web Service Description Language (WSDL) 檔案的測試客戶機，然後客戶機幫助測試員理解 Web 服務的運作和呼叫服務。

資料收集

單一 SOA 環境能利用來自不同內部人員和外部涉眾的不同技術和不同資料格式。這需要 QA 團隊驗證所有技術和資料格式的整合。這種工作中非常關鍵的一個部分是在部署並執行所有測試方案之前收集正確的資料。如果事前收集了測試資料，這就確保了 QA 生命週期不會因為在特定測試周期中資料可能不可用而受到干擾。

這需要更廣泛的設計階段和 SOA 治理，以及 QA 團隊與相關方面的協同參與。SOA 治理這一中央團隊主持整體 SOA 工作，即管理並監控此工作，測試團隊應當識別其測試資料需求，並與相關涉眾合作，以便在服務開發程式中獲取資料。SOA 治理流程應當確保 QA 團隊的需求得到滿足。這些實踐確保了當整合測試所需服務就緒時，QA 團隊將充分獲得必要資料。

更高層次的整合需要更好的規劃和戰略，以解決可用性問題

在更傳統的方法中，測試員可期待應用程式或業務功能通過單個專案、在通過 Web 介面向大眾開放的單一應用程式伺服器上得到交付。藉助 SOA，應用程式邏輯可位於中間層，利用任意數量的技術而運作，駐留在部門甚至公司之外。這使得端到端測試即使在測試環境中都依賴於第三方。如果某重要的特定第三方系統不可用，如果 QA 團隊沒有做好準備，那麼就可能干擾 QA 週期。QA 團隊必須準備好應對所有狀況。

圖 3. 依賴於第三方的業務流程流

對於執行測試周期而遭遇這種干擾的 QA 團隊而言，所有涉眾都前瞻性地通知其停機時間，併為之作出計劃，這十分關鍵。如 SOAPUI 和 Rational Application Developer (RAD) 等工具可用於建立 mock 佔位符服務來幫助適應特定服務的停機時間和不可用性。

Mock 服務允許 QA 團隊在降低對涉眾的依賴性的同時執行端到端測試。QA 團隊能建立與實際服務作用相似的佔位符服務。這些服務是使用實際 WSDL 和受支援的原始服務模式而生成的。Mock 服務擁有一組響應。這些響應用於響應對 Mock 服務的請求。響應可以是隨機的、迴圈的或基於特定規則/策略的。

圖 4. 業務流程流對第三方的依賴 —— Mock 服務

如果原始服務出於任意原因而不可用，就可使用 Mock 服務。這有助於確保 QA 週期不受特定服務故障的負面影響。一旦定義了服務介面，測試員就能繼續建立服務，以獲取端到端解決方案，而不需等待實際服務得到開發。

Mock 服務還有助於隔離缺陷，同時除錯問題、研究問題根源。由於 Mock 服務受到良好控制，它們有助於建立更加可控的環境，特別是在診斷缺陷之時。以這種方式，測試員就能推動不同的端到端方案，而且較少受到第三方位置的可能問題的影響。我們推薦為專案中每個 Web 服務都生成一個 Mock 服務。

安全挑戰

由於 SOA 環境的特質是利用了獨立服務，所以維護安全性就更具挑戰性。安全解決方案必須應對安全性的所有典型方面 —— 即驗證、授權、準確識別、訊息完整性、認可、機密性/私密性和審計支援。這要求仔細地確立可靠的關係，特別要使用 WS-Security 標準。為了能夠測試安全措施，關鍵是要了解所使用的標準、協議和約定，並具備相關技能。

同樣，Web 服務是基於 Web 的，因而需要像關注任意 Web 解決方案一樣關注它。仍然可應用例如 Rational AppScan [5] 等工具來測試其漏洞。

針對安全漏洞，必須採用常規的負面測試用例。列表將包含測試，以確保：

1. 拒絕重放，即不應該接受稍後重新傳送的複製訊息
2. 不可能發生中間人攻擊
3. 訊息是機密的，不能未預先通知就進行改變
4. 只有合法使用者能訪問服務（包括拒絕欺詐陰謀）

必須確保出色的異常管理

當不同服務通過一個公共層相互作用時，必須測試異常狀況，並確保程式碼使用了基於規範的標準，以處理邊緣/負面流程條件。業務流程流幫助模擬影響底層服務的業務事件的進展。如果任一個服務不響應或在某種意義上響應失敗，則流程應當足夠健壯以處理這種狀況，並提供故障通知。在測試流程時，這些邊緣條件必須得到識別和測試。

重用挑戰

重用是 SOA 的主要益處之一。在開始採用 SOA 之時，單個服務會被數個或少數應用程式所使用；但很快，一些服務將被許多應用程式使用。如果這些服務沒有計劃在如此負載下執行，沒有經過相關測試，那麼一些使用它們的應用程式可能要遭受不可接受的響應時間。而且在最壞的情況下，服務沒有經過徹底測試而且不能工作，那麼對於整個組織而言，這種故障的影響可能是災難性的，因為同時會有多個應用程式受到影響。

學習曲線

一些技術和標準（例如 SOAP、Web 服務、XML、BPEL 和 WS-Policy）不斷髮展。採用這些技術的過程會很緩慢，因而當企業執行現代化任務時，需要考慮相關學習曲線。QA 團隊成員需要深刻理解這些技術與好處，這些技術和好處使他們能夠有效地測試 SOA 解決方案。

最佳實踐

實現 SOA 願景，執行技術培訓

如簡介所述，對 SOA 普遍特徵的認知和對 SOA 的期望是很重要的，這有助於 QA 工作集中化。因此，應當針對 SOA 環境的整體範圍對 IT 團隊進行培訓，包括業務涉及哪些領域、提供服務要涉及哪些系統、哪些系統計劃成為新服務使用者。他們應當瞭解與計劃相關的標準、原則和治理。

與 SOA 計劃培訓一樣，團隊應當也樂於採用測試所必需的 Web 服務技術。這通常包括 XML（結構、名稱空間和模式）和 WSDL。

因此，這些領域的培訓方案是 SOA 計劃中持續進行的一部分。

維護自動化服務整合測試套件

人們希望核心戰略服務能易於使用，並且長期重用。它們簡單的介面之下隱藏了複雜整合的底層後端系統。因此，一定也包含了更高的服務質量風險。任意服務實現堆疊層中的變更都可能導致服務功能的迴歸。在這種情況下，應當及早捕獲迴歸、快速隔離迴歸，以便在釋出下一版系統更新之前，確定並實現必要的調整。

為管理每個戰略服務的質量，建議要在維護服務的同時維護一個自動化測試套件（檢視 [2] 瞭解建立這種包含複合服務的套件的具體指南）。此套件必須根據需要執行，而幾乎（或完全）不需要安裝時間。此套件應當適用於服務堆疊每層中的主要元件。

相關的治理實踐只能保證，如果已證明自動化整合測試套件存在並且受到維護，那麼服務可用。

採用服務測試框架

要自動化並維護服務整合測試套件，必須開發和重用一些普遍功能。包括：

1. 能夠生成沒有應用程式 UI 的測試工具
2. 根據服務描述 (WSDL) 生成測試訊息
3. 輸入變數，使用資料表
4. 資料安裝和解除安裝指令碼
5. 測試報表輸出
6. 預期結果的定義
7. 針對堆疊的每個整合層執行測試（通常是通過一個單元測試環境）
8. 模擬外部服務 (mock)
9. 審查和驗證來自所使用的應用程式的服務訊息
10. 通過分離的執行緒傳送多條測試訊息

這些功能打包在一個整合測試框架 (ITF) 內。框架通常由商業工具或開源工具組成，結合了定製和調整，可滿足特定的環境要求。

ITF 不為各個服務重複實現這些功能，而應當作為單獨的可重用資產進行維護，包含了常用的程式、工具和指令碼。建議您從 Web 服務功能測試工具起步（參見 [3] 和 [4]），為框架打基礎。

圖 5. 整合測試框架 (ITF)

使用 Mock 服務，在與提供者整合之前為客戶進行測試

Mock 可在實際提供者不可用時允許進行測試。這有助於服務測試開發，還有助於在與完整服務整合之前分離客戶測試。

為支援不完善的專案時間安排，例如當服務仍然處於開發階段時，客戶需要進行其他測試，於是要提供 Mock 服務來代替實際服務。ITF 應當有能力生成 Mock 服務，以用於這樣的情況。

圖 6. Mock 服務

使用測試套件，在客戶整合之前充分測試服務

在服務開發過程中，應當開發一種版本持續進化的自動化服務整合測試套件。這可簡化必要的問題確定和除錯工作。如果沒實現這種開發，那麼就比較難以確定某問題是客戶的責任還是提供者的責任。

始終為效能測試作計劃

效能測試用於測定新服務的可伸縮性和響應能力，應當是計劃的一部分。也應當考慮為新客戶進行效能測試，因為不同的客戶有著不同的負載特性。

ITF 應當具備按比例增加並行請求數量的能力。

應當及早並持續地度量服務實現效能。不能等到最後，因為變更設計可能代價高昂。

為設定和驗證安全性保留足夠時間

在實現服務安全性之時，許多教訓應當謹記於心：

1. 當解決方案受到端到端的保護（例如利用令牌檔案）時，除錯服務握手可能很困難
2. 負面案例測試方案比正面案例更加流行（例如正在驗證和處理的訊息）
3. 利用使用端 UI，開發出的測試案例可驗證這些使用者依靠新解決方案能做些什麼，以及配套應用程式允許他們做些什麼。
4. ITF 需要能夠呼叫安全服務
5. 只有 WS-Security 規範的子集能夠由供應商和開源框架實現共同使用，從而為變通方案提供時間
6. 為外部合作伙伴或客戶進行測試時，應當計劃利用客戶端訊息和引數記錄，以便減少除錯工作

設計監測和記錄功能

為了快速識別和減少 SOA 實現中的問題，特別是涉及到複雜流程流時，推薦使用日誌記錄。日誌記錄應當可轉換為多種詳細程度，而且應當使跨系統的跟蹤資訊具有相關性，例如通過記錄準確時間戳或者報頭識別符號。

採用環境發煙測試

SOA 解決方案通常依靠許多整合元件，例如 Enterprise Service Bus (ESB) 和閘道器。有了這許多可動部件，在完全部署到各環境之前，對這些元件的測試應當一切正常。如果環境和整合元件沒有事先驗證，那麼要減少問題就更加困難和耗時。

採用測試驅動的開發的常用實踐

本文概述的實踐中，有一些可歸類到常用的測試驅動開發 (TDD) 實踐。TDD 建議及早開始測試並持續測試，例如測試每個系統版本。隨著系統的演化，需要不同形式的測試工具，包括要能模仿或去除在黃金時間尚未準備好的部分。

由於許多 SOA 專案中存在複雜性和協調需求，增量式或迭代式的開發實踐並不少見。推薦使用 TDD 原則，這是為了獲得針對最新變更的基於測試的即時反饋，以完成這些專案。

仔細策劃測試戰略

測試戰略概述了專案或版本細節，例如測試的責任和要執行的測試的型別。其計劃應當包括培訓、構建整合服務測試套件、獨立客戶測試、效能測試、安全性和依賴性管理（在一般情況下，相關元件不是在易於管理的步驟中釋出的）。

為改善一致性，建議在每個可能情況下，使用一些原則作為預設實踐。原則包括：

• 為每個新服務進行效能測試和測量
• 為每個新服務構建和執行整合測試套件
• 為系統更新的每個新子集執行整合測試套件
• 為新客戶提供早期 Mock 服務或測試實際服務版本

詳細測試計劃原則現在也整合到了 SOMA[1] 當前版本之中，SOMA 是一種 IBM 方法。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-660123/，如需轉載，請註明出處，否則將追究法律責任。