中国指挥与控制学会会刊 
自20世纪80年代末开始,我国国防建设开始跨入大规模信息化建设时期,军事电子信息系统组成模式经历了多次变化,信息系统的规模、作战范围、基础设施、体系架构、互操作能力及组网能力发生了巨大的变化。随着装备技术体系和国家战略的发展、调整,信息化条件下全军联合作战将是一体化海陆空潜电综合防御和岛屿联合进攻的核心作战样式,其中网络中心战(NCW)是信息化联合作战的必然趋势, 全军正处于平台中心站向网络中心战转型的重要时期,网络中心行动(NCO)及军事信息栅格(MIG)的构建迫在眉睫。
面向服务的体系架构(Service Oriented Architecture,SOA)是一种构建大型信息系统的结构模型。它将应用程序的不同功能单元通过服务之间定义好的接口契约联系起来,通过业务流程编排进行服务组合,通过服务总线进行服务的管理和远程调用,进而实现特定的任务。面向服务体系架构能够实现作战能力及信息的高度共享和灵活重组,是网络中心战以及“十二五”、“十三五”信息化建设的核心技术支撑,是取得“制信息权”的重要保障。海军是海、陆、空、天、潜、电兵种齐全的特殊兵种,海战场一体化联合作战正引领全军综合电子信息系统全面向服务化技术体制转型。由于SOA是新一代的软件架构思想,同面向对象、模型驱动设计方式的出现一样,它的系统复杂性、外部服务的源代码不可得等特殊性给软件开发、软件测试带来了新的挑战。
随着Web服务标准的成熟和应用的普及,海军服务实体以此为原型基础,采用基于WSDL、SOAP、UDDI和BPEL系统标准协议的海军服务化描述语言作为服务对外提供的描述文件,引入一种新的服务应用的开发、部署和集成的模式,完成面向服务体系架构的构建。为了保证服务实体的质量,必须对其进行详尽的测试[1-2]。虽然目前服务实体的测试用例自动生成的研究已经取得了一些进展,但是该类研究以服务作为测试和验证的对象,缺乏对服务描述语言标准协议及系统规范的符合性进行验证,且没有考虑海军业务背景下元素间的约束关系,不能有效地保证服务对外提供信息的正确性,难以保障测试的充分性[3]。
本文以服务实体的静态检测技术为背景需求,基于海军服务化描述语言系列标准协议以及服务实体和组合流程中可能存在的缺陷入手,集中对服务化描述语言的元素结构、取值的正确性进行研究,提出面向缺陷模式的BPEL静态缺陷检测方法。同时,基于领域知识约束关系描述语言用于验证元数据的应用领域、数据类型、数据精度等属性是否满足海军的任务背景下的数据元素的描述和表示要求,并开发相应的自动化测试工具,支撑上述测试理论,为服务实体的静态测试提供了有力手段,具有十分重要的理论意义和实用价值。
1 研究背景和相关工作
1.1 Web服务描述语言(WSDL)
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 所示的缺陷规范类别。
根据上图归纳规范,设计出51种缺陷模式,具体如表1 所示。
表1 静态分析结果统计 |
| 静态缺陷 检测文档 | 发现规 范类别 | 发现错误类型 | |
|---|---|---|---|
| 海军服务化描述语言(WSDL)静态检测 | 符合XML 格式 | 无根元素,namespace不正确,属性必须加引号,无关闭标签,对大小写敏感,正确的嵌套(6类,15个) | |
| 符合WSDL 规范 | 必须包含WSDL namespace声明,targetNamespace要设置正确,找不到messge名称,缺少有效的属性数据,如服务地址等,对于有唯一性要求的元素,不能出现重复,WSDL的restriction限制要合理,schema中minOccurs、maxOccurs设置要合理,Message中不能同时设置元素和类型,Binding中的style和use设置必须正确,交叉链接信息要正确(10类,24个) | ||
| 海军信息传输语言文档(SOAP)静态检测 | 符合SOAP 规范 | 缺少Envelope元素,缺少body元素,未使用SOAP encoding命名空间,未使用SOAP Envelope命名空间(4类,18个), | |
| 海军服务化注册中心(UDDI)静态检测 | 符合UDDI 规范 | 无根元素,对大小写敏感,无关闭标签,属性必须加引号,元素名称不能有空格,正确的嵌套(6类,12个) | |
| 海军业务流程编排文档(BPEL)静态检测 | 符合XML 格式 | 检查一个正确的BPEL文件,无根元素,无关闭标签,关闭标签不匹配,对大小写敏感,正确的嵌套,属性必须加引号,注释错误(7类,26个) | |
| 符合BPEL 规范 | 服务体中不能有多个顶层的活动,对assign进行验证,assign的name错误,对branches进行验证,condition expressionLanguage错误,invoke的输入变量,invoke中的接口portType须正确,invoke中的操作须有效,invoke中的name改变,invoke中partnerLink不匹配,flow活动的link同步须正确设置,No PartnerLinks,import导入wsdl操作要正确,变量必须包含正确的声明信息,variable name不配套,无效的BPEL模式文件URL,suppressJoinFailure值有错,对于唯一元素,不可以多增加(18类,25个) | ||
2.2 业务流程组合缺陷模式检测
由于BPEL本身的特性,如BPEL规范定义了许多称为活动(activity)的元素来执行不同的任务,可以分为基本活动(BasicActivitieS)和结构化活动(strueturedActivitieS)两大类,依次构建出复杂的可执行流程,可执行流程是一个完整的可运行的流程,包括了外部视图和复杂的内部逻辑。因此除了根据BPEL规范进行结构化检测之外,还需要考虑其独特的故障类型。为了便于查找相应的故障,提高流程的可靠性和正确性,首先需要对具有一定模式的被检测故障进行定义,然后采用状态机进行统一建模,以便根据状态机理论进行故障检测。
如果BPEL文件流程中存在上述缺陷,会严重影响服务组合的可靠性,引起业务流程运行异常,甚至产生中断。同时,此类缺陷往往不易发现,且很难对此设计单独的动态测试用例,因此需要根据现有的缺陷模式,在软件动态执行前进行静态的缺陷检测。
3 缺陷检测框架
根据以上缺陷模式,可基于模式匹配方法完成静态缺陷检测流程。本文根据服务系列协议的特点,将该流程分为两个部分,如图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代表其它的可能状态;
• T:Q×Conditions→Q是转移函数,T表示下一个状态,即给定一个状态,根据输入输出参数条件,EFSM可以转移到另一个或几个状态;状态间的迁移条件Conditions∈C;
• 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 所示。
运用工具SOATest的静态缺陷检测模块可以进行海军服务化描述语言的静态缺陷检测,本系统可以根据服务实体描述文件标准协议展开结构性检测,并依据海军领域规则进行领域知识验证,基于缺陷模式完成业务流程编排的缺陷检测,并以此定位缺陷代码行数及缺陷类型,指导测试人员进行相应的修改,系统执行界面如图6 -8所示。
5.2 应用实例分析
本文选取某型号海军综合电子信息系统作为待测对象,采用人工注入故障的方式来验证静态缺陷检测技术及系统原型工具的有效性,根据支持的故障类型,分别为WSDL文档注入16类故障,SOAP文档注入4类故障、UDDI文档注入6类故障,BPEL文档注入25类故障,共120个。此外,为了验证BPEL业务流程组合部分缺陷模式,在实验过程中还用了故注入的方式注入如下故障:3个未初始化变量缺陷、1个数据竞争缺陷、1个link非法使用缺陷、1个分支活动相同缺陷。之后根据获取的静态错误结果进行统计分析,获取如下表2 所示的静态分析结果。
表2 静态缺陷检测结果 |
| 静态缺陷文档 | 覆盖故 障类型 | 注入 故障数 | 发现 错误数 | 发现错误描述 |
|---|---|---|---|---|
| WSDL(XML规范) | 6 | 15 | 15 | 无根元素等 |
| WSDL规范 | 10 | 24 | 24 | 缺少服务地址等 |
| SOAP规范 | 4 | 18 | 18 | 缺少Envelop元素等 |
| UDDI规范 | 6 | 12 | 12 | 不正确的嵌套等 |
| BPEL(XML规范) | 7 | 26 | 26 | 无关闭标签等 |
| BPEL规范 | 18 | 25 | 25 | 含有多个顶层活动等 |
| BPEL流程编排 | 4 | 6 | 6 | 未初始化变量等 |
通过上述表格可以发现,注入文档中的静态缺陷故障均被查出,证明了本文提出的静态缺陷检测方法及系统原型工具的有效性。
6 结束语
在海军面向服务待测系统中,存在多类提供的海军服务化描述语言(WSDL、SOAP、UDDI和BPEL),而作为服务对外提供的描述文件,服务化描述语言和服务都需要作为测试对象进行测试和验证。本文提出了海军服务化描述语言的静态缺陷检测框架,首先,检查服务描述文档中是否有不符合语法规范的错误,是否存在标签信息缺失等静态缺陷。之后对BPEL文档在服务组合实际运行前对流程进行检测,尽可能在流程设计阶段发现流程中可能存在的缺陷,减少系统部署后的维护费用,提供流程可靠性。
在后期的工作中,我们将针对服务的特点,向静态缺陷模式库添加更多经验缺陷及更复杂的业务流程缺陷,并进一步提高缺陷检测的精度。