SOA 非功能測試最佳實踐

引言

SOA 是一種 IT 體系結構風格，支援將您的業務轉換為一組相互連結的服務或可重複業務任務，可在需要時通過網路訪問這些服務和任務。這個網路可以是區域網、Internet，或者一組不同位置提供的分散各處且採用多種技術，但以類似於安裝在本地桌面的方式互動的服務。可以對這些服務進行結合，以完成特定的業務任務，從而讓您的業務快速適應不斷變化的客觀條件和需求。也就是說，SOA 遵循查詢、繫結並執行的關鍵原則工作，非常適合用於滿足請求/響應型別的業務需求。

圖 1. SOA 實現生命週期

當由能夠解決難點或實現特定手動任務的自動化的策略業務目標和需求對 SOA 實現進行引導時，就可以實現業務轉換。這樣能夠帶來諸多好處，包括：

• IT 與業務的一致性。
• 最大限度地重用 IT 資產（不採用拆除和替換方法）。
• 手動和重複性任務的自動化。
• 遵循行業標準和法律法規。
• 填補組織的 IT 豎井 (Silo) 間的空白。
• 持續更改能夠方便地對映為新服務的業務流程。

不過，只有在將功能需求和非功能需求包含到應用程式中並無縫整合到生產環境中，才能夠實現 SOA 承諾的好處。因此，理想的實現和測試在關鍵時刻是必不可少的。

NFR 測試的主要挑戰出現在 SOA 應用程式在實驗室環境中開發或作為軟體供應商的新產品投資組合的一部分開發時，在這些情況下，大多數時候生產環境都不可用。其他的挑戰包括：

• SOA 應用程式具有大量的內部和不可見元件。
• 要進行測試，需要建立存根，用於替代生產環境中的遺留應用程式。
• 互操作性期望非常高。
• SOA 應用程式在重型中介軟體堆疊或平臺上執行。
• 效能和負載承載能力非常依賴於中介軟體堆疊和遺留應用程式（在生產環境中）。
• 由於實現 SOA 的目的是為了填補企業級的空白，因此 NFR 的數量可能非常多。
• 早期技術 (SOA) 介面卡具有對測試自動化工具的有限訪問。
• 根據所解決的業務問題不同，用於應用程式部署的體系結構和元件可能會有所變化。
• NFR 比功能需求的變化頻率高。
• 在實驗室環境中進行測試需要在測試基礎設施方面進行大量的投資。

  最佳實踐

  雖然沒有測試軟體的最佳萬能方法，但可以參考下面根據我的經驗給出的列表。除了應對上面的一些挑戰外，這些建議還可能會帶來其他優勢：

  • 首先組建測試團隊，此團隊需要具有在計劃使用的目標作業系統和中介軟體元件上工作的足夠技能。
  • 仔細分析需求，並找出自相矛盾的需求。
  • 瞭解系統上下文關係圖，以確定對存根的需求。
  • 確保在專案開始時建立可測試性表格。確定能夠測試的 NFR、不能測試的 NFR，以及哪些測試能夠實現自動化。
  • 建立了可測試性表格後，確定能夠通過任何行業標準工具（如 IBM® Rational® Performance Tester）進行測試的需求，或者確定實現測試自動化是否需要自定義軟體程式或指令碼。
  • 儘早規劃測試基礎設施。可能會需要在各個平臺上測試應用程式，如 Microsoft® Windows®、Linux®、IBM AIX® 等。要在以後採購伺服器可能會比較困難。
  • 估算測試資料需求並確定建立足夠的有效測試資料量以進行容量和負載測試。
  • 對於您的 SOA 應用程式，請至少對錶 1 中所給出的非功能方面進行測試。
  
  表 1. 非功能特徵類別
  

  測試型別	測試定義
  可訪問性	驗證訪問應用程式功能的能力。
  稽核與控制	驗證檢查歷史工作流和稽核記錄的便利性。
  可用性	驗證應用程式是否能提供服務水平協議（Service Level Agreement，SLA）中規定的高正常執行時間。
  相容性	驗證應用程式是否適合之前已有（較舊）的環境。
  文件	驗證使用者指南是否提供了正確的說明。
  安裝	驗證應用程式是否能在所定義的中介軟體堆疊上工作。
  互操作性	驗證在更改環境中的重要元件後應用程式是否能正常工作。
  負載/容量	驗證給定時間應用程式是否能完成所需處理的事務數量。
  可維護性	驗證在應用程式投入生產環境中後進行維護的便利性。
  效能	驗證響應時間、吞吐量、併發性等等標準是否滿足需求。
  可靠性	驗證應用程式在與生產環境類似的負載壓力下是否能正常工作。
  可伸縮性	驗證應用程式是否能滿足業務不斷增長的需求。
  安全性	驗證應用程式是否具有足夠的安全措施，能夠防止資訊被盜。
  服務能力	驗證是否能夠在不對業務造成任何影響的情況下對應用程式進行除錯。
  可用性	從終端使用者的角度驗證應用程式是否可用。

  
  
  表 2. 可以促進 SOA 應用程式的 NFR 測試的工具綜合列表
  

  工具	功能
  IBM Rational AppScan	支援以集中方式進行 SOA 應用程式安全性評估，並提供了完全整合的解決方案集。Rational AppScan 能夠隨著企業體系結構伸縮，支援同時掃描多個應用程式。
  IBM Rational Functional Tester	為測試人員提供用於功能和非功能測試、迴歸測試、GUI 測試和資料驅動測試的自動化測試功能。工具的測試自動化功能也允許進行負載和壓力測試。
  IBM Rational Performance Tester	捕獲響應時間、頁面吞吐量和併發性。此效能測試建立、執行和分析工具供團隊用於在部署前驗證複雜 SOA 應用程式的可伸縮性和可靠性。
  IBM Rational Performance Tester Extension for SOA Quality	擴充套件 SOA 應用程式的效能和可伸縮性測試。這是負載和效能測試與問題分析工具，除了 Rational Performance Tester 的標準功能外，還能夠幫助尋找效能瓶頸。它支援進行 SOA 效率問題確定，併為支援部署的 Web 服務提供了廣泛的平臺監視支援部署，且支援伺服器資源資料的收集和視覺化。

  
  

  注意： IBM Rational RequisitePro、IBM Rational Test Manager 和 IBM Rational ClearQuest® 可分別用於進行需求管理、測試用例管理和缺陷管理。

  標識為測試建立存根和模擬器的需求

  正如前面提到的，SOA 測試中的一個挑戰是建立存根和模擬器。存根和模擬器替代生產環境中的遺留應用程式和其他外部應用程式（在生產中作為後端系統）。除了業務領域的知識外，還可以通過分析所開發的應用程式的系統上下文來建立存根和模擬器（請參見圖 2）。

  
  圖 2. SOA 應用程式的示例系統上下文關係圖
  
  
  

  在圖 2 中，需要模擬遺留生產系統（藍色）和外部系統（粉紅色）作為存根，以測試新應用程式（功能和非功能測試都需要）。

  測試團隊可以首先從瞭解這些系統的功能入手，然後尋找模擬這些系統進行測試的簡單方法。在大多數情況下，一個簡單的資料庫就可以幫助解決問題，但其中應該包括支援所要測試的業務事務的所有表格和示例資料。

  這些最佳實踐在實際工作中的應用

  IBM 名為 Global Business Solutions Center (GBSC) 的團隊開發並測試了名為組合業務服務（Composite Business Service，CBS）的 SOA 應用程式，此類應用程式在 IBM SOA Foundation 和中介軟體堆疊（如 IBM WebSphere® Process Server、IBM WebSphere Application Server、IBM WebSphere Business Services Fabric、IBM WebSphere MQ 和 IBM DB2® 產品）上執行。CBS 是相關的整合業務服務的集合，能提供特定的業務解決方案，並支援在 SOA 上構建的業務流程。

  通常，CBS 與客戶環境中的其他應用程式和/或服務整合，從而為客戶提供所需的業務解決方案。業務解決方案由編排在一起的業務服務組成。也就是說，CBS 不是獨立解決方案，而是能夠使用一個或多個 CBS 建立的解決方案。

  使用 CBS 建立的端到端解決方案的客戶目標是銀行、醫療、保險和零售等行業及政府部門。考慮到這些行業的本質和規模，您可以發現，SOA 的角色是支援大容量和任務關鍵型業務事務的處理，以及支援異類環境中的持續業務更改。

  這就是 NFR 為何在對客戶的業務進行轉換的過程中如此重要的原因。目前在 GBSC 中開發的 CBS 已經針對上面建議的大部分需求進行了測試，在某些情況下具有出眾的效能基準，如在單個批處理提交中能處理超過 2 百萬個事務的能力，以及所報告的各種任務關鍵型流程的卓越吞吐量和響應時間。

  測試人員使用 Rational Performance Tester、IBM Tivoli® Composite Application Manager 以及自主構建的實用工具程式等工具來建立測試資料和實現特定測試用例的自動化。我在這個列表中忽略了常規的測試和缺陷管理工具，如 Rational Test Manager 和 Rational ClearQuest 等，因為此類常規工具用於同時支援功能和非功能測試。

  圖 3 顯示，在示例應用程式中的業務事務 1 的併發使用者數量從 1,000 增加到 1,150 時，平均響應時間從 3 秒增加到了 3.2 秒。

  
  圖 3. 效能測試：業務事務 1
  
  
  

  圖 4 顯示，在示例應用程式中的業務事務 2 的併發使用者數量從 1,000 增加到 1,150 時，平均響應時間從 7.9 秒增加到了 10.7 秒。

  
  圖 4. 效能測試：業務事務 2
  
  
  

  回顧與 NFR 關聯的表格時，請注意參考資料極為關鍵。如果沒有這些數字，就沒有意義。例如，如果收集併發布效能相關的基準，至少應該提供以下參考資料：

  • 測試環境詳細資訊，如伺服器規範（硬體和軟體規範）
  • 客戶端詳細資訊或用於執行測試的桌面的規範
  • 用於進行測試的工具的詳細資訊（例如，使用了 Rational Performance Tester 生成圖 1 和圖 2 中的示例圖）。

  
  

  注意事項

  雖然測試 NFR 是成功採用 SOA 應用程式所必不可少的步驟，但請記住，如果沒有具體的量化要求（在可能的情況下），則可能會遇到麻煩。在實驗室環境中進行測試和開發時，如果併發性和容量/負載需求之類的非功能標準未量化，而測試團隊進入了基準確定階段，則更容易出現這種情況。此時，完成專案所需的時間和工作量都會大幅度增加。

  不過，如果建立了採用計劃並與所有專案涉眾進行了共享，則可以緩解這個風險。接下來讓我們瞭解一下如何為專案制定取樣計劃，您需要在其中確定 SOA 應用程式能夠處理的最大事務量。

  首先，將所有可以在測試環境中處理的事務排列和組合新增到表格中。請參見表 3 中的示例。

  
  表 3. 確定可以進行事務處理的不垃圾廣告式
  

  檔案中的事務請求數量	上載的單個批次中的檔案數量
  100	10000	20000	30000	40000	50000
  1000	1000	2000	3000	4000	5000
  10000	100	200	300	400	500
  100000	10	20	30	40	50
  1000000	1	2	3	4	5

  
  

  隨後，進行了應用程式開發之後，處理少量的檔案，並根據得到的資料進行推斷。可以上載 100 個批次，每個檔案中包含 100 個請求，根據其處理此數目所需的時間，可以評估處理表 3 中所示的檔案排列和組合所需的時間。

  根據可用時間和資源以及確信度，您可以決定基準確定工作的開始和結束時機。檢查根據表 3 建立的取樣計劃（請參見表 4）。

  
  表 4. 取樣計劃，第 1 部分：測試所推斷出來的目標值在示例中以粗體顯示
  

  檔案中的事務請求數量	上載的單個批次中的檔案數量
  100	10000	20000	30000	40000	50000
  1000	1000	2000	3000	4000	5000
  10000	100	200	300	400	500
  100000	10	20	30	40	50
  1000000	1	2	3	4	5

  
  

  儘管這些目標值可能會在確定基準的過程中失效，但可以幫助規劃這個級別本身的測試方法。例如，如果採用 100*40000 個檔案的測試用例失敗，那麼如何進行相關工作呢？可行且實際的做法是，僅僅以預先規劃的方式進行處理；例如，如果 100*40000 失敗，則嘗試 100*37500，然後 100*35000，以此類推。請參見表 5 中給出的更多示例。

  
  表 5. 取樣計劃，第 2 部分：針對最初目標值的測試失敗的情況下的測試方法
  

  檔案中的事務請求數量	上載的單個批次中的檔案數量
  	嘗試-1	嘗試-2	嘗試-3	嘗試-4	嘗試-5
  100	40000	37500	35000	32500	30000
  1000	3000	2750	2500	2250	2000
  10000	300	275	250	225	200
  100000	20	18	16	14	12
  1000000	2	1	-	-	-

  
  

  在實現較高階別的非功能能力方面的限制

  在採用 SOA 的過程中，完全有可能發掘出現有 IT 系統的全部潛力。但中介軟體堆疊中使用的各個元件可能會造成一些限制，而在執行生產環境中的 SOA 應用程式和遺留應用程式時需要中介軟體堆疊。為了便於理解，讓我們以使用規則引擎為例，該引擎在給定時間只能處理 X 個事務。如果此規則引擎掛鉤到 SOA 應用程式，就會造成約束，使效能級別不高於 X。

  總結

  希望通過本文能夠給您組織的 SOA 採用之旅帶來一定的幫助。雖然這些最佳實踐的應用取決於您當前的 SOA 成熟度級別和改進機會，但上面列表中給出的挑戰、非功能特徵、工具、實際實現示例能夠幫助您確定如何著手進行此工作。而且，NFR 的成功實現最終將在 IT 和業務流程之間形成一個關聯關係，而這就是我們的主要目標。

  
  

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