海軍服務化描述語言的靜態缺陷檢測方法*

李 源,李 吟,姚海洋

(江蘇自動化研究所,江蘇連云港 222061)

海軍服務化描述語言的靜態缺陷檢測方法*

李 源,李 吟,姚海洋

(江蘇自動化研究所,江蘇連云港 222061)

在海軍面向服務架構的待測系統中,提供多類型的海軍服務化描述語言(WSDL、SOAP、UDDI和BPEL),而作為服務對外提供的描述文件,服務化描述語言和服務都需要作為測試對象進行測試和驗證。對此,提出海軍服務化描述語言的靜態缺陷檢測框架,首先根據待測系統服務描述文檔進行結構化和領域知識的分析驗證,檢查設計文檔中是否存在不符合語法規范和領域約束的錯誤。隨后基于面向缺陷模式的業務流程組合測試實現在流程設計階段發現流程中潛在的隱蔽錯誤。案例表明,該方法能夠有效地檢測出人工注入的多類型靜態缺陷錯誤,并具有相應的原型工具支撐,最終幫助用戶高效執行靜態缺陷的檢測,達到提高軟件質量的目的。

海軍服務化描述語言;靜態缺陷檢測;領域約束;業務流程組合缺陷

自20世紀80年代末開始,我國國防建設開始跨入大規模信息化建設時期,軍事電子信息系統組成模式經歷了多次變化,信息系統的規模、作戰范圍、基礎設施、體系架構、互操作能力及組網能力發生了巨大的變化。隨著裝備技術體系和國家戰略的發展、調整，信息化條件下全軍聯合作戰將是一體化海陸空潛電綜合防御和島嶼聯合進攻的核心作戰樣式，其中網絡中心戰(NCW)是信息化聯合作戰的必然趨勢, 全軍正處于平臺中心站向網絡中心戰轉型的重要時期,網絡中心行動(NCO)及軍事信息柵格(MIG)的構建迫在眉睫。

面向服務的體系架構(Service Oriented Architecture,SOA)是一種構建大型信息系統的結構模型。它將應用程序的不同功能單元通過服務之間定義好的接口契約聯系起來,通過業務流程編排進行服務組合,通過服務總線進行服務的管理和遠程調用,進而實現特定的任務。面向服務體系架構能夠實現作戰能力及信息的高度共享和靈活重組,是網絡中心戰以及“十二五”、“十三五”信息化建設的核心技術支撐,是取得“制信息權”的重要保障。海軍是海、陸、空、天、潛、電兵種齊全的特殊兵種,海戰場一體化聯合作戰正引領全軍綜合電子信息系統全面向服務化技術體制轉型。由于SOA是新一代的軟件架構思想,同面向對象、模型驅動設計方式的出現一樣,它的系統復雜性、外部服務的源代碼不可得等特殊性給軟件開發、軟件測試帶來了新的挑戰。

隨著Web服務標準的成熟和應用的普及,海軍服務實體以此為原型基礎,采用基于WSDL、SOAP、UDDI和BPEL系統標準協議的海軍服務化描述語言作為服務對外提供的描述文件,引入一種新的服務應用的開發、部署和集成的模式,完成面向服務體系架構的構建。為了保證服務實體的質量,必須對其進行詳盡的測試[1-2]。雖然目前服務實體的測試用例自動生成的研究已經取得了一些進展,但是該類研究以服務作為測試和驗證的對象,缺乏對服務描述語言標準協議及系統規范的符合性進行驗證,且沒有考慮海軍業務背景下元素間的約束關系,不能有效地保證服務對外提供信息的正確性,難以保障測試的充分性[3]。

本文以服務實體的靜態檢測技術為背景需求,基于海軍服務化描述語言系列標準協議以及服務實體和組合流程中可能存在的缺陷入手,集中對服務化描述語言的元素結構、取值的正確性進行研究,提出面向缺陷模式的BPEL靜態缺陷檢測方法。同時,基于領域知識約束關系描述語言用于驗證元數據的應用領域、數據類型、數據精度等屬性是否滿足海軍的任務背景下的數據元素的描述和表示要求,并開發相應的自動化測試工具,支撐上述測試理論,為服務實體的靜態測試提供了有力手段,具有十分重要的理論意義和實用價值。

1 研究背景和相關工作

作為面向服務架構SOA(Service-Oriented Architecture)的一種實現技術,Web服務通過標準的Web協議提供服務,建立了一個可互操作的分布式應用程序平臺,實現了基于開放標準、松散耦合和跨平臺的特性。作為服務對外提供的文件,例如WSDL、SOAP、UDDI和BPEL,均為標準的、規范的XML格式描述的,包含了與服務交互的全部細節,包括消息格式(詳細描述操作)、傳輸協議和服務端點位置,為信息的自動化處理提供了基礎[4-5]。

1.1 Web服務描述語言(WSDL)

WSDL(Web Service Description Language)是描述Web服務的標準XML格式文檔,它能夠準確描述Web服務的功能和與Web服務進行通信的具體接口,并且用一種與具體語言無關的抽象方式定義了相應的Web服務的具體操作、相關信息和Web服務的具體服務地址(物理地址)[6-7],其具體的概念模型如圖1所示。

圖1 服務實體描述語言

1.2 簡單對象訪問協議(SOAP)

SOAP(Simple Object Access Protocol)是一種輕量級協議,是一種基于XML的用于在分布式環境中進行信息交互的協議。它可以在任何傳輸協議下使用,如HTTP、TCP、SMTP等,也可以允許任何編程模型,而不依賴RPC[8]。

1.3 統一描述、發現和集成協議(UDDI)

UDDI(Universal Description Discovery and Integration)是一個跨平臺的開放性架構,用于描述、發現和集成相關的服務,它是基于Internet的電子商務技術標準,規定了一些訪問協議的標準和一組基于服務的分布式服務實體信息注冊中心的實現標準規范[8]。

1.4 業務流程編排語言(BPEL)

BPEL(Business Process Execution Language)是一種可擴展標記語言的業務流程組合語言,使用變量來保存和傳遞流程的狀態信息,是一種高級的、抽象的、可執行的建模語言。它不僅實現服務實體之間交互的流程編制,也將流程自身暴露為服務實體。通過partnerLink、portType和operation確定組合流程需要調用的外部服務，其中partnerLink執行外部的服務提供者,portType指明該提供者所提供的一個端口,而operation則指定端口上的服務名。使用invoke活動調用外部服務,支持異步和同步兩種類型的服務調用[9]。

隨著面向服務架構和服務描述語言規范的逐步成熟,Web服務標準協議(WSDL、SOAP、UDDI)的應用也引起了更多的關注,同時BPEL業務流程規范也逐步變得復雜而龐大,這就不可避免地需要充分的測試來保障它的正確性和可靠性。白曉穎等人對Web服務測試存在的主要問題進行了討論,指出了集成的Web服務測試應該通過靜態驗證和動態虛擬執行的方法進行正確性驗證[10]。在動態測試方面存在大量的研究成果,Tsai、白曉穎等人提出了基于WSDL規約的方法進行黑盒測試[11-12],隨后西北工業大學馬春燕等人提出了基于形式化樹模型指導測試用例的生成[13]。北京大學姜瑛等人則結合合約變異技術完成基于WSDL文檔測試用例的約簡[14]。在靜態測試方面,宮云戰提出了一種面向故障的軟件測試方法,將測試的對象,從整個軟件轉向了故障模型[15]。楊朝紅進一步給出了面向故障的軟件測試需要的測試過程,需要從源代碼的輸入參數開始,經歷預編譯、詞法分析、語法分析與語義處理、抽象語法樹生成、控制流圖生成和缺陷可疑點掃描等,最后自動生成IP報表[16]。肖慶在面向故障的軟件測試技術中引入了有限狀態機,采用故障描述狀態機來描述故障模型,以一種常用和易于理解的抽象形式給出了故障的狀態和狀態間的轉換條件,并對缺陷模式進行歸納和分析,實現了基于源代碼的高效測試[17]。

從上述研究現狀來看,目前關于獨立Web服務的動態測試研究比較完善,而針對服務的靜態驗證,雖然存在一些基于源代碼的靜態缺陷檢測技術,但是考慮到Web服務對外僅提供服務描述的標準系列協議,現有的靜態缺陷檢測技術存在明顯的不足，無法適用于Web服務的描述文件的靜態測試中。本文結合上述Web服務系列協議規范,針對服務描述文件與業務流程組合文件的特點,分別采用XML Schema規范和海軍領域約束模型驗證海軍服務化系列協議(WSDL、SOAP、UDDI、BPEL)的正確性及基于缺陷模式匹配的業務流程組合(BPEL)的靜態檢測。

2 缺陷描述

軟件測試的主要目的在于發現軟件存在的錯誤(BUG),靜態測試方法的優劣取決于針對測試對象是否有較好的缺陷模式,缺陷模式和具體的檢測語言相關,不同的檢測語言應設計不同的缺陷模式庫。本文參考文獻[18]中提到的對傳統的程序語言設計相應的缺陷檢測系統,軟件缺陷模式庫中存儲的缺陷屬性需要包含缺陷標識、缺陷類型、缺陷嚴重程度、缺陷優先級、缺陷來源及缺陷原因等。根據海軍服務化系列描述的特點與區別,設計該協議對應的缺陷模式。結合海軍服務描述協議的特點,首先需要根據標準協議規范進行協議的結構性測試,檢測描述文件是否能夠符合協議的規范。除此之外,考慮到BPEL的特殊語法,使其具有其獨特的故障類型,如消息類型不匹配、死路徑、數據競爭、死鎖、link非法使用等,因此需要單獨歸納典型的BPEL的語義缺陷。

2.1 服務文件靜態缺陷模式檢測

待檢測的服務實體對外提供的描述文件(WSDL、SOAP、UDDI、BPEL)均為滿足W3C系統規范的XML文檔。W3C規范給出了相關的靜態分析要求,包含XML格式的結構化規范以及符合每種描述語言特點的模式規范,采納這些語言規范,進行缺陷模式的總結,并進行鑒別和篩選,定義圖2所示的缺陷規范類別。

圖2 靜態缺陷檢測規范

根據上圖歸納規范,設計出51種缺陷模式,具體如表1所示。

表1 靜態分析結果統計

2.2 業務流程組合缺陷模式檢測

由于BPEL本身的特性,如BPEL規范定義了許多稱為活動(activity)的元素來執行不同的任務,可以分為基本活動(BasicActivitieS)和結構化活動(strueturedActivitieS)兩大類,依次構建出復雜的可執行流程,可執行流程是一個完整的可運行的流程,包括了外部視圖和復雜的內部邏輯。因此除了根據BPEL規范進行結構化檢測之外,還需要考慮其獨特的故障類型。為了便于查找相應的故障,提高流程的可靠性和正確性,首先需要對具有一定模式的被檢測故障進行定義,然后采用狀態機進行統一建模,以便根據狀態機理論進行故障檢測。

圖3是一個具體的BPEL流程的實際案例,復雜變量根據流程分支的不同產生不同的賦值情形,其中,假分支導致的賦值結果會引起變量未賦值的錯誤,產生變量未初始化的缺陷。由于此類缺陷存在隱蔽性,因此很難在設計階段發現。而這種在軟件運行時才能夠發生的故障,如死循環、路徑不可達等,會嚴重影響軟件的可靠性,因此需要對流程部署的文件進行詳盡的靜態缺陷檢測。本文基于文獻[18]列舉的典型缺陷模式,構建業務流程編排缺陷庫,具體為:未初始化變量、變量、遍歷子屬性定位失敗、死鎖、死循環、數據競爭、循環完成條件沖突、link非法使用、路徑不可達、分支活動相同等。

如果BPEL文件流程中存在上述缺陷,會嚴重影響服務組合的可靠性,引起業務流程運行異常,甚至產生中斷。同時,此類缺陷往往不易發現,且很難對此設計單獨的動態測試用例,因此需要根據現有的缺陷模式,在軟件動態執行前進行靜態的缺陷檢測。

圖3 未初始化變量流程實例

3 缺陷檢測框架

根據以上缺陷模式,可基于模式匹配方法完成靜態缺陷檢測流程。本文根據服務系列協議的特點,將該流程分為兩個部分,如圖4所示。

圖4 缺陷檢測工作流

首先,根據XML語法及W3C定義的服務系統協議標準,基于結構化的特征,進行海軍服務化描述語言的結構檢測;其次,根據業務流程組合的缺陷行為缺陷,模擬缺陷的多類可能情況,基于面向缺陷的模式匹配,以捕獲BPEL流程中的缺陷行為。

3.1 服務文件靜態缺陷模式檢測流程

如圖4左邊流程所示,服務文件的靜態缺陷檢測分為如下幾個步驟:

1)XML文檔結構解析:將海軍服務化描述語言中的標簽元素映射為對象及其屬性,從而構造出面向對象的DOM樹;

2)核心建模:DOM樹完成了海軍服務化描述語言文件的XML標簽樹狀表示,針對服務描述文件進行靜態缺陷檢測,仍需建立基于缺陷庫的模式匹配模型,并以此進行檢測。同時,海軍服務化描述語言包含了海軍的領域信息,因此需要根據擴展的海軍領域模型進行領域知識的驗證;

3)缺陷模式匹配:基于缺陷模式庫選取DOM樹中節點進行一一遍歷;

4)測試執行:整個測試過程基于核心建模和模式匹配進行,通過模式匹配加載建立的缺陷模式模型,建立缺陷模式庫,然后依次根據模式庫中缺陷描述匹配DOM樹中的標簽元素,驗證其正確性、一致性和完整性,并上報存在的錯誤,直到DOM樹中標簽元素遍歷完全;

5)測試結果:當缺陷檢測執行完畢,上報服務描述文件存在錯誤的行號、對應錯誤類別、嚴重級別、相應的改進方案,整個測試過程結束。

3.2 業務流程組合缺陷模式檢測流程

如圖4右邊流程所示,當服務描述文件的基本靜態缺陷檢測完成后,仍需針對BPEL文件的特殊語法,展開業務流程的正確性檢測,分為如下幾個步驟:

1)預處理:分析業務流程編排文檔,通過DOM樹讀入XML文件后,將在存儲器中建立一個文件結構樹(Document Structural Tree),識別BPEL中的各種活動,及其活動間的嵌套和跳轉關系;

2)核心建模:對BPEL解析獲得的元素進行分析處理,首先,根據DOM樹產生的文件結構樹從而產生標簽關系圖,之后結合BPEL規范及標簽關系圖中的消息產生控制流程圖,最后使用擴展的有限狀態機模型構建缺陷模式庫;

3)測試執行:基于上一步驟構建的模型,通過模式匹配加載相應的缺陷模式描述文件,并依據有限狀態機模型創建狀態機實例,之后遍歷有限狀態機模型中的狀態,調用Web服務中的響應函數完成狀態的遷移,當狀態機進入故障狀態后,在故障模式庫中匹配該故障,并上報錯誤,否則繼續執行狀態機模型,直到系統狀態遍歷結束;

4)測試結果:當缺陷檢測執行完畢,上報服務描述文件存在錯誤的行號、對應錯誤類別、嚴重級別、相應的改進方案,整個測試過程結束。

4 缺陷檢測模型

4.1 服務描述文件靜態缺陷檢測機制

服務描述文件靜態缺陷檢測包含結構級檢測和海軍領域數據約束檢測兩方面。其中,結構級檢測主要是檢驗描述文件是否符合XML及WSDL/SOAP/UDDI/BPEL規范。本文提供如下3中缺陷檢測機制:

1)基于XML schema模式文件的通用檢測方法;

2) 擴展wsdl4j包的WSDL文件針對性檢測方法;

3)基于org.eclipse.bpel.validator包的BPEL文件針對性檢驗,改進BPEL designer。

同時,本文提供基于海軍領域語義描述的領域知識檢測。海軍服務化描述語言描述的服務實體的輸入/輸出參數、環境變量以及系統狀態參數等數據中含有大量的海軍領域知識信息。例如在描述數據資源的秘密等級及相關內容時,“密級”的取值范圍為“非密、秘密、機密和絕密”。當描述數據資源的物理特征時,如存儲類型、存儲環境等,“資源存儲類型”的取值范圍為“0代表結構化,1代表非結構化”,它們必須是取自特定集合中的元素,而非簡單的字符串定義。正確使用這些數據,不僅需要引用格式正確,更需要對數據庫予以正確的理解。因此,本文在缺陷庫中加入了海軍領域知識缺陷,滿足海軍領域數據約束檢測的需求。

檢測算法從服務描述文件形成的DOM樹的根節點開始,逐個遍歷各個子元素,并與缺陷庫進行比較,如果發現錯誤,則上報缺陷信息,如算法1所示。

算法1 靜態缺陷檢測算法

輸入:WSDL/SOAP/UDDI/BPEL標準協議文件,缺陷模式集合DefectData;

輸出:缺陷數據集DefectResult.

Begin

DefectResult=?;∥初始化DefectResult

DomTree(WSDL);∥以WSDL為例,生成DOMTree

For each node ‘m’ in DomTree∥遍歷Dom樹中每一個根節點

DefectData=Import(Defect-DB);∥導入缺陷模式數據庫

While(每一個缺陷模式i)

if(m. DefectStructureMatch(i)==TRUE)∥若根節點匹配庫中結構缺陷

CallDefect(m,i);∥上報結構缺陷,記錄m行數

DefectResult.ADD(m,i);∥將缺陷加入缺陷數據集

elseif(m.DefectDomainMatch(i)==TRUE)∥若根節點匹配庫中領域缺陷

CallDefect(m,i);∥上報領域缺陷,記錄m行數

DefectResult.ADD(m,i);∥將缺陷加入缺陷數據集

else

遍歷下一個缺陷模式

End while

End for

End

4.2 業務流程編排算法

與服務描述文件缺陷檢測不同,業務流程編排需要進行服務狀態變遷的檢測,因此需要單獨建立缺陷模型。本文采用擴展的有限狀態機描述BPEL存在的活動關聯,依據EFSM模型中的狀態轉換來描述BPEL文件中活動間的交互行為,以輔助缺陷模式庫的生成。EFSM缺陷狀態模型定義如下:

定義1 (EFSM的缺陷狀態模型):它是一個三元祖(Q,T,C),其中:

?Q是一個有窮集合,叫作狀態集,Q={start,error,end}∪other,其中start、error和end分別代表開始、錯誤和結束狀態,other代表其它的可能狀態;

? C是狀態的條件集,代表狀態間的偏移條件。

基于上述的EFSM模型,沿著狀態機的狀態變遷執行BPEL程序的分析,依據文獻[19]提出的缺陷狀態機計算方法,進行BPEL缺陷分析,缺陷檢測算法如下所示:

算法2 業務流程組合缺陷檢測算法

輸入:BPEL 控制流程圖BPEL-Graph;

輸出:缺陷數據集DefectResult.

Begin

For each node ‘n’ in BPEL-Graph∥遍歷控制流程圖中每一個節點

ExcutePreNode(n);∥執行節點n的前序實例

While(每一個n節點的狀態機實例i)

n.instance[i].Q=start;∥設置實例狀態為開始

ExcuteNode(n);∥執行當前節點實例

if(n. instance[i].Q==error)∥狀態遷移

錯誤狀態

CallDefect(n.instance[i]);∥上報業務流程缺陷

elseif(n. instance[i].Q==end)∥狀態遷移到結束狀態

Destroy(n.instance[i]);∥銷毀實例信息

else

i=i+1;∥進入下一個狀態實例

End While

ExcuteAfterNode(n);∥執行節點n的后序實例

End for

End

5 缺陷檢測原型工具及應用驗證

5.1 缺陷檢測原型系統

結合之前的Web服務測試用例集生成的相關工作,本文研制了面向服務測試用例自動生成原型系統SOATest。本工具支持服務實體的功能測試和性能測試,具體功能包括測試用例的生成和管理、測試的執行,以及測試結果的收集和報表生成。工具支持服務描述文件的靜態缺陷檢測,測試系統的體系結構如圖5所示。

圖5 面向服務系統測試原型系統體系結構

運用工具SOATest的靜態缺陷檢測模塊可以進行海軍服務化描述語言的靜態缺陷檢測,本系統可以根據服務實體描述文件標準協議展開結構性檢測,并依據海軍領域規則進行領域知識驗證,基于缺陷模式完成業務流程編排的缺陷檢測,并以此定位缺陷代碼行數及缺陷類型,指導測試人員進行相應的修改,系統執行界面如圖6-8所示。

圖6 靜態缺陷規則選擇界面

圖7 靜態缺陷檢測結果界面

圖8 領域約束編輯界面

5.2 應用實例分析

本文選取某型號海軍綜合電子信息系統作為待測對象,采用人工注入故障的方式來驗證靜態缺陷檢測技術及系統原型工具的有效性,根據支持的故障類型,分別為WSDL文檔注入16類故障,SOAP文檔注入4類故障、UDDI文檔注入6類故障,BPEL文檔注入25類故障,共120個。此外,為了驗證BPEL業務流程組合部分缺陷模式,在實驗過程中還用了故注入的方式注入如下故障:3個未初始化變量缺陷、1個數據競爭缺陷、1個link非法使用缺陷、1個分支活動相同缺陷。之后根據獲取的靜態錯誤結果進行統計分析,獲取如下表2所示的靜態分析結果。

表2 靜態缺陷檢測結果

通過上述表格可以發現,注入文檔中的靜態缺陷故障均被查出,證明了本文提出的靜態缺陷檢測方法及系統原型工具的有效性。

6 結束語

在海軍面向服務待測系統中,存在多類提供的海軍服務化描述語言(WSDL、SOAP、UDDI和BPEL),而作為服務對外提供的描述文件,服務化描述語言和服務都需要作為測試對象進行測試和驗證。本文提出了海軍服務化描述語言的靜態缺陷檢測框架,首先,檢查服務描述文檔中是否有不符合語法規范的錯誤,是否存在標簽信息缺失等靜態缺陷。之后對BPEL文檔在服務組合實際運行前對流程進行檢測,盡可能在流程設計階段發現流程中可能存在的缺陷,減少系統部署后的維護費用,提供流程可靠性。

在后期的工作中,我們將針對服務的特點,向靜態缺陷模式庫添加更多經驗缺陷及更復雜的業務流程缺陷,并進一步提高缺陷檢測的精度。

[1] Hong Mei, Lu Zhang. A framework for Testing Web Services and its Supporting Tool[C]∥IEEE International Workshop on Service-Oriented System Engineering. Washington: IEEE Computer Society, 2005:199-206.

[2] R. Heckel, L. Mariani. Automatic Conformance Testing of Web Services [J].FASE2005, LNCS 3442, 2005: 34-48.

[3] 馬春燕,朱怡安，陸偉.Web服務自動化測試技術[J].計算機科學,2012,39(2):162-169.

[4] 許蕾,李言輝,陳林，等.一種面向用戶需求的Web服務測試方法[J].計算機學報,2014,37(3):512-521.

[5] Elia I A, Laranjeiro N, Vieira M. A Practical Approach towards Automatic Testing of Web Services Interoperability[J]. International Journal of Web Services Research, 2015.

[6] He H. What is Service-Oriented Architecture?[EB] http:∥webservices.xml.com/pub/a/ws/2003/09/30/soa.html.Sep.2003.

[7] Canfora G, Di Penta M. Testing services and service-centric systems:challenges and opportunities [J].IT Professional,2006, 8(2):10-17.

[8] W3C,Web Services Description Language(WSDL) Version 2.0[EB]∥W3C Recom-mendation,26 June 2007,http:∥www.w3.org/TR/2007/REC-wsdl20-primer-20070626.

[9] Li Zhong Jie,Sun Wei,Jiang Zhong-Bo,Zhang Xin.BPEL4WS unit testing:framework and implementation[C]∥Proceedings of the 2005 IEEE International Conference on Web Services(ICWS’05).Orlando,USA,2005:103-110.

[10]白曉穎,趙沖沖,戴桂蘭.Web服務測試研究[J].計算機科學,2006,33(2):252-255.

[11]W. T. Tsai, R. Paul, Y. Wang, C. Fan, D. Wang, Extending WSDL to Facilitate Web Services Testing[C]∥Proceeding of IEEE HASE, 2002: 171-172.

[12]Bai XY, Dong WL, Tsai WT, et al. WSDL-Based automatic test case generation for Web services testing[C]∥Proceedings of the 2005 IEEE International Workshop on Service-Oriented System Engineering(SOSE’05),Washington: IEEE Computer Society,2005:207-212.

[13]Ma CY, Du CL, Zhang T, et al, WSDL-Based automated test case generation for Web service[C]∥Proceeding of the Computer Science and Software Engineering. Washington: IEEE Computer Society,2008.731-737.

[14]姜瑛,辛國茂,單錦輝,等.一種Web服務的測試數據自動生成方法[J].計算機學報,2005,28(4):568-577.

[15]宮云戰.一種面向故障的軟件測試新方法[J].裝甲兵工程學院學報，2004，18(1)：21-25.

[16]楊朝紅,宮云戰,肖慶,等.基于模型的軟件測試[J].北京化工大學學報(自然科學版)，2007,34(21)：85-88.

[17]肖慶,楊朝紅,畢學軍.一種基于故障模式狀態機的測試方法[J].北京化工大學學報(自然科學版)，2007,34(21)：73-76.

[18]葉可可.BPEL-缺陷測試系統的設讓和實現[D].北京：北京郵電大學,2011.

[19]楊學紅. BPEL流程的故障模式及其靜態分析技術的研究[D].北京：北京郵電大學,2011.

Static Defect Detecting on Navy Service Description Language

LI Yuan, LI Yin, YAO Hai-Yang

(Jiangsu Automation Research Institute of CSIC, Lianyungang 222061, China)

In the naval service oriented system to be detected, there are multi types of Navy service description language (WSDL, SOAP, UDDI and BPEL). Provided as a foreign service description documents, service description language and service needed as the test object is tested and verified. In this paper, we present static defect detection framework for naval service description language. First of all, according to the measured system service description document structured and domain knowledge analysis and verification, check the design document whether there does not conform to the errors in grammar and domain constraints. Then the business process combination test based on the defect mode is realized in the process of the process design. The case shows that this method can effectively detect the error of the multiple types of artificial injection, and has the corresponding prototype tool support,eventually reach requirements to improve the quality of software.Key words:navy service description language; static defect detecting; domain constraint; business process composite defects

2010-08-10

“十二五”總裝預研課題(513150502)

李 源(1983-),男,遼寧本溪人,碩士,工程師,研究方向為指火控系統。 李 吟(1988-),男,碩士,工程師。 姚海洋(1985-),男,工程師。

1673-3819(2017)01-0122-08

TP206+.34；E917

A

10.3969/j.issn.1673-3819.2017.01.026

修回日期： 2010-08-22