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