1 概述
面向服務架構(Service Oriented Architecture, SOA)是一種分布式的計算架構模式，具有天然的松耦合特性，使服務的可替換性、可復用性成為可能。而且，通過對服務的編排，企業可以輕松地開發企業級業務流程，實現更加復雜的業務功能。因此，SOA被越來越多的大型企業所采用。如何對大型企業中的SOA進行測試成為研究熱點，為此，本文提出一種基于業務數據的大型企業SOA測試方法。
2 SOA 測試分析
2.1 SOA 測試的困難性
與傳統軟件系統相比，SOA的松耦合特性會為測試工作帶來一系列的困難，主要體現在以下3 個方面：
(1)對于服務的使用方來說，服務的內部實現機制是不可見的。因此，服務的演化發展過程也超出了服務使用方可控的范圍。傳統的白盒測試只可能由服務提供方來實施，而服務的使用方只有在服務運行態下才能獲知服務質量。
(2)SOA 的另一個重要特性是服務的動態綁定。動態綁定會導致被測系統在運行時發生變化，從而導致已有的測試結果失效，增加了回歸測試的工作量。
(3)在通過服務編排實現的業務流程中，集成后的流程測試是SOA 測試的最大難題。即便單個服務已經通過了測試，串聯之后的業務流程仍有可能出現問題。另一方面，流程測試的充分性也很難做到。
2.2 SOA 測試的研究現狀
文獻[2-3]將SOA 的服務測試技術的研究分為3 個階段：
(1)第1 階段：關注企業內部的測試。主要測試服務的基本功能，如功能正確性、SOAP 消息和WSDL 描述等。
(2)第2 階段：關注面向服務的特征，主要測試服務的發布、查找和綁定3 種行為的能力，以及服務間的異步通信問題和服務質量問題。
(3)第3 階段：關注服務的動態特性和集成的總體測試，如服務組合測試和版本測試。
從國內外的研究與應用情況來看，目前關于SOA 測試的研究內容和研究成果可分為3 類：
(1)對服務協議、服務狀態的測試，例如文獻[2]對Web服務測試的理論和方法進行了綜述。
(2)采用自動化生成的測試用例來對SOA 系統進行測試，例如，文獻[4]提出了基于測試用例生成器和仿真客戶端來測試SOA 系統，文獻[5]提出了生成基于XML 語言的測試用例文檔的方法。
(3)自動化測試工具的研究，例如文獻[6]提出使用自動化測試引擎對服務進行測試，文獻[7]對Web 服務注錯測試工具進行了研究。
從上述論述可以看出，目前SOA 測試的理論研究、應用和測試工具多停留在對服務協議本身或單個服務測試的層面上，對集成后的業務流程測試則考慮較少。自動化測試工具多采用某種規則生成測試用例，使用真實數據作為測試用例輸入的較少。
3 基于業務數據的大型企業SOA 測試方法
3.1 基本思想
大型企業中的SOA 系統更應該注重集成測試和業務流程測試。筆者認為，基于歷史真實業務數據的測試方法是在大型企業SOA 系統中行之有效的測試方法，理由如下：
(1)業務的本質就是數據。大多數業務操作，實際上就是對業務數據的修改，因此，基于歷史真實業務數據的測試就成為測試服務功能正確性的直接入口。
(2)業務流程的分支本質上是由數據不同造成的，因此，保證足夠的真實數據測試樣本，就能最大限度地接近全覆蓋測試。
(3)真實數據可能出現的問題要遠遠多于測試人員主觀想象的范圍。因此，有必要使用真實數據進行測試。
(4)在大型企業中，需要做縱向的數據一致性(即一定時間區間內的數據總和)校驗。使用歷史真實的數據進行測試，可以利用歷史報表對數據進行比對。
(5)大型企業的信息化建設起步相對較早，一般都已經建設了信息系統，因此，具有一定的業務數據儲備量，可以支持基于數據的測試。
3.2 案例分析
在基于數據的測試方法中，最重要的工作是準備測試數據和測試用例，為了能較清晰地闡述基于業務數據的測試步驟，本文采用案例分析的方式加以描述。
案例說明：某大型企業A 選擇了SOA 作為其信息化建設架構，企業系統架構如圖1 所示。
圖1 企業A 的SOA 系統架構
綜合統計系統是企業A 的報表處理及數據分析系統，所有關鍵的業務數據都會準實時地同步到綜合統計系統中，以便為企業管理者提供決策支持服務。企業A 開發了一個大宗訂單處理流程，如圖2 所示。
圖2 企業A 的大宗訂單處理流程
該流程是一個進存銷類企業中常見的業務流程，涉及到合同管理系統、庫存管理系統、采購管理系統、財務系統等。該業務流程的起點是合同錄入，后續環節根據起點環節輸入的數據自動流轉，非常適合使用基于歷史真實數據的測試方法進行測試。本案例中的一個測試用例如表1 所示。
表1 服務流程測試用例
操作步驟如下：
(1)明確業務場景。場景是對用戶行為的描述，大多數業務可以由若干個場景來描述。基于場景組織測試用例，可以提高測試用例的覆蓋程度，也是常規測試中的必要步驟。
在理想情況下，應該根據被測試對象(單個服務或是業務流程)的業務特征枚舉出所有的場景。但在復雜的業務流程中，業務場景的數量有時會出現組合爆炸的情況。此時，應按照出現概率對業務場景進行排序，選出主要的業務場景進行優先處理。
(2)準備測試數據。針對上一個步驟分析出的主要業務場景列表，可以從歷史真實數據中為每種場景找出數據樣本。數據樣本從舊系統的數據庫中根據條件查詢可得。需要注意的是，由于企業中的新舊系統交替，歷史數據的數據結構以及質量可能不完全滿足新系統輸入的需要，需要一些SQL語句對數據的結構進行轉換，并進行去空格、去亂碼等數據清洗工作。樣本的選擇還應該具有普遍的統計性。如果歷史庫中有2006 年、2007 年、2008 年這3 年的數據，則應該從每一年的數據中選擇一些。避免集中在某個時間段中選取樣本，以提高缺陷暴露的可能性。
對于不屬于主要業務場景的小概率業務場景，可采用時間覆蓋的方式，即從歷史數據庫中選擇一段連續時間內的數據作為輸入樣本(例如可選擇連續3 個月的數據)，以提高測試的覆蓋度。
另外，在流程集成測試和壓力測試的過程中，還需要做縱向數據一致性校驗。在本案例中，可以選擇某一個歷史統計月份的所有訂單數據作為輸入，將綜合統計系統生成的訂單月報表和訂單財務報表與歷史已有報表進行比對。
(3)編制輸入/輸出表。本步驟的主要工作是根據每組測試數據樣本，編制輸入/輸出對比表，以便能夠校驗測試用例的輸出結果是否正確。在通過服務編排實現的業務流程中，需要對每個服務執行后的數據結果進行檢查。
編制輸入/輸出表的工作可以交給客戶，或者在客戶監督下完成。具體操作是：針對每組業務輸入數據，按照業務邏輯進行轉換，得出其應該輸出的結果。在實際測試過程中可以借助Excel 宏等編程工具，來減少數據計算中的工作量。
(4)編寫自動化腳本。自動化腳本主要有3 個功能：1)根據輸入數據列表，模擬客戶端發起服務請求；2)自動獲取服務輸出以及測試用例中的輸入/輸出列表，并自動對比測試結果；3)如果發現不一致，自動報告問題。
(5)運行測試用例。上述步驟都準備完成之后，就可以使用自動化測試腳本完成測試了。如果系統的狀態發生了改變，使用自動化測試腳本進行回歸測試即可。
3.3 測試方法評價
基于歷史真實業務數據的測試方法具有如下優點：(1)易操作。在復雜業務環境的測試過程中，由于業務數據的內在關聯性，編制模擬測試數據往往具有很高的難度。本測試方法的步驟具有較強的可操作性，適合于在大型企業的SOA 系統實施項目中應用。
(2)測試覆蓋度高。使用模擬數據的測試方法中，由于測試人員對于業務過程的主觀認識的局限性，制造的數據往往千篇一律，很難覆蓋到所有方面；而使用真實業務數據的測試則使測試過程最大限度地接近系統真實運行環境，測試覆蓋度高。
(3)缺陷暴露率高。在使用模擬數據的測試方法中，由于模擬數據本身的業務性差，因此測試人員很難得知服務處理業務數據的過程是否正確。而在使用真實數據的測試方法中，由于輸入/輸出對比表中的輸出都是已有而合理的，因此可以反向暴露出更多的服務處理邏輯缺陷。
但本文測試方法的局限性也較為明顯，例如：
(1)需要對歷史的真實業務數據進行提取和處理，對測試人員的業務能力要求較高。
(2)沒有解決SOA 測試中缺陷定位的難題。
(3)不適用于需要人工參與的業務流程測試，例如審批類型的業務流程。為了對人機交互類型的服務實現自動測試，還需要額外開發模擬人工處理的功能。
4 結束語
本文在分析現有SOA 測試方法的基礎上，提出一種面向業務數據的大型企業SOA 測試方法，在企業級SOA 系統開發中具有較高的可操作性。由于本文方法需要歷史真實數據的支撐，因此更適用于大型企業的信息系統升級改造過程。下一步將對自動化測試工具、自動化數據比對工具、測試缺陷自動定位等問題進行研究。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：基于業務數據的大型企業SOA測試方法
相關文章
