CN104156313B - 一种Web服务测试用例自动生成方法 - Google Patents

Abstract

一种Web服务测试用例自动生成方法，基于文档解析及约束求解自动生成测试用例，包括Web服务文档解析、Web服务约束条件提取和Web服务测试用例自动化生成三部分，自动化生成SOAP消息表示的测试用例，即为Web服务的测试用例。本发明在Web服务测试用例的自动生成过程中，通过提取WSDL、BPEL文档中的约束条件，并运用约束求解方法，根据这些约束条件自动化生成测试用例，从而减少测试用例的冗余度，提高覆盖率，提高Web服务测试的效率。

Description

一种Web服务测试用例自动生成方法

技术领域

本发明属于软件工程分析测试技术领域，使用文档解析及约束求解方法，用于自动化生成Web服务测试用例，为一种新的Web服务测试用例自动生成方法。

背景技术

网络技术的高速发展使得面向服务的体系结构(SOA)得到了学术界以及工业界的广泛认可。SOA是构造分布式计算应用程序的方法，它将应用程序功能作为服务发送给最终用户或者其他服务，从而实现分布式应用的低成本快速开发。Web服务通过使用开放的XML标准描述、发布、发现、协调和配置应用程序，建立一个可互操作的分布式应用程序平台，使得不同开发语言、部署平台等系统之间能够进行交互、组合，形成一个功能丰富的服务流程，以满足用户的需求。

为了保证Web服务的正确性和可靠性，需要测试人员设计测试用例对Web服务进行测试，从而保障软件质量。Web服务提供商通常对外只提供了服务接口的描述性文档，如Web服务器描述语言(WSDL)文档、业务流程执行语言(BPEL)文档等，测试人员无法获取各个Web服务的源代码，因此只能结合描述文档对Web服务进行黑盒测试。当前对Web服务进行测试的方法主要有：扩展WSDL文档，通过增加WSDL中变量的属性信息以增加运行时约束信息，但由于此种方法只对变量属性信息以及接口操作进行分析，并基于此产生相应的测试用例，在对Web服务组合进行测试时，未能结合程序执行流程中的种种约束条件，造成测试用例的冗余度较高，且覆盖率低；利用语义网挖掘Web服务中的语义信息，从而指导生成测试用例，但由于语义网尚未普及，在实际应用中收效甚微。

当前存在的Web服务测试工具有SoapUI、Selenium等。SoapUI基于对WSDL解析，并结合用户输入，生成测试用例，需要人工干预；Selenium使用用户操作行为的录制回放生成测试用例，缺乏灵活性。另外，这些测试工具无法保证测试的充分性，且生成的测试用例冗余度较高、测试效率低。

WSDL、BPEL等文档中通常包含大量Web服务中的约束条件，而这些约束条件当前主要用于服务匹配等方面，没有被充分应用于Web服务测试中。

发明内容

本发明要解决的问题是：1)如何对Web服务提供的文档进行解析；2)如何处理BPEL中定义的多种活动类型，并自动生成包含变量及业务执行流程等信息的约束条件；

3)如何利用Z3-str求解器自动生成测试用例。

本发明的技术方案为：一种Web服务测试用例自动生成方法，基于文档解析及约束求解自动生成测试用例，包括Web服务文档解析、Web服务约束条件提取和Web服务测试用例自动化生成三部分：

1)Web服务文档解析过程，包括对WSDL文档和BPEL文档的解析，在对WSDL文档进行解析时，得到DOM树，遍历DOM树，得到WSDL文档中定义的所有变量的属性信息；在对BPEL文档进行解析时，得到DOM树，遍历DOM树的节点，分别得到BPEL文档中的变量的取值和属性信息以及活动节点的取值和属性信息；

2)根据BPEL文档中定义的命名空间对应关系，取得BPEL文档中的变量在对应的WSDL文档中的变量的属性信息，由WSDL文档的变量属性信息解析得到变量约束条件，所述变量约束条件包括变量的类型和取值范围；

3)根据解析BPEL文档得到业务执行流程信息，提取出业务执行流程中服务调用、变量赋值的关系，对业务执行流程进行化简，得到只包含活动类型、服务调用和变量赋值关系的业务执行流程中间文件，同时，根据业务执行流程开始和结束活动以及业务执行流程中调用其他服务时调用的变量名，即可得到该Web服务的输入、输出变量名；

4)利用静态单赋值形式对BPEL文档中的变量进行重命名，使得对每个变量的赋值操作最多进行一次；

5)利用模型检查方法，根据BPEL文档中不同的活动类型，将业务执行流程改写为使用语句if、assignment、assertions以及逻辑运算符表示，并使用规范化算法将改写后的业务执行流程中间文件规范化表示为条件范式；所述规范化算法如下：

P、P1、P2均为输入到算法中进行处理的程序片段

G、c均为if语句中条件判断语句，这里G＝true

procedure NORMALISE(P,G)

if P是一个赋值语句或判断语句then

return if(G)P；

else if P＝(if(c)P1；)then

return NORMALISE(P1,c&&G)；

else if P＝(if(c)P1；else P2)then

return NORMALISE(P1,c&&G)；NORMALISE(P2,(！c)&&G)；

else if P＝(P1；P2)then

return NORMALISE(P1,G)；NORMALISE(P2,G)；

end if

end procedure

6)根据步骤2)-5)中提取的变量约束条件、条件范式以及Z3-str求解器对所输入文档的语法要求，生成符合Z3-str求解器输入文档格式要求的约束条件；

7)将步骤6)中生成的约束条件代入Z3-str求解器，得到可行解空间及变量取值，Z3-str求解器的输入文件是步骤6)得到的约束条件，输出内容为满足约束条件的可行解空间；如果对变量的所有取值，都不能满足约束条件，则输入“UNSAT”，表示约束条件无解；对于可行解空间，结合Web服务文档解析得到的Web服务输入、输出变量名，即可获得Web服务输入、输出变量的取值，即为测试用例中输入、输出变量的取值；根据输入和输出变量名及其取值，结合SOAP协议的定义，自动化生成SOAP消息表示的测试用例，即为Web服务的测试用例。

其中，Web服务文档解析对应步骤1)，Web服务约束条件提取对应步骤2)-6)，Web服务测试用例自动化生对应步骤7)。

本发明通过采用以上技术方案，具有以下优点：

1.客观：测试用例的自动生成主要依赖于从Web服务提供的文档中所提取的约束条件，而不是测试人员根据经验主观得出的测试用例，使得生成的测试用例内容更加丰富、客观；

2.覆盖率高：通过解析BPEL文档，可以得到Web服务所有执行流程，据此生成的测试用例能够完全覆盖执行流程，具有覆盖率高的特点；

3.冗余度低：从Web服务提供的文档中提取约束条件后，将约束条件代入约束求解器，得到相应的解空间。根据输入参数及其解空间自动生成的测试用例有较强的针对性，冗余度较低；

4.高效：通过快速分析Web服务中提供的文档，自动化生成高覆盖率、低冗余度的测试用例，可以让测试人员快速对Web服务进行测试，提高测试效率。

附图说明

图1为本发明的结构流程图。

图2为本发明方法中BPEL文档中if语句规范化转换示例。

图3为本发明的规范化算法。

图4为本发明的文档格式转换关系图。

图5为本发明Web服务测试用例示例。

具体实施方式

本发明提供一种基于文档解析及约束求解的Web服务测试用例自动生成方法，用于将Web服务提供的文档中包含的约束条件用于测试用例的自动化生成中，从而降低测试用例的冗余度，提高覆盖率。

本发明的整体框架图如图1所示，包括Web服务文档解析、Web服务约束条件提取和Web服务测试用例自动化生成三部分：Web服务相关文档解析用于将Web服务提供的文档转变为DOM树，从而获取变量的属性信息及Web服务业务执行流程；Web服务约束条件提取将业务执行流程转化为条件范式，并根据Z3-str的语法要求生成包含有变量及业务执行流程等信息的Web服务约束表达文件；Web服务测试用例自动化生成部分，根据输入的约束条件得到可行的执行路径及变量取值，再根据输入变量的取值范围及取值对应的求解结果，结合SOAP协议的定义，自动化生成SOAP消息，即为Web服务中的测试用例。

(1)Web服务文档解析

如图1中文档解析部分所示，首先需要分别对Web服务提供商提供的WSDL文档和BPEL文档进行解析。

在WSDL解析阶段，使用开源工具WSDL4J将WSDL解析为DOM树，然后分别提取<types>,<message>,<portType>,<binding>,<service>等标签信息。为了提取WSDL中的变量约束信息，需要提取<message>标签信息以获取<message>中包含的<part>子标签信息，用于在BPEL中查找对应变量约束。在获取<types>标签信息时，根据<types>中<element>的子标签是否为<complexType>，自动将变量划分为简单变量类型和复杂变量类型。对于简单变量类型，可以直接获取变量的名字(name),类型(type)等属性值；对于复杂变量类型，由于工具WSDL4J中没有对复杂类型进行处理的函数，需要自己定义函数对复杂变量类型进行解析：<element>标签是<types>中定义的变量，如果<element>的子标签为<complexType>，说明该<element>标签为复杂变量类型，需要继续获取<complexType>的子标签，并递归解析该子标签中的变量，最终得到复杂变量类型中包含变量的详细定义。这里由于子标签可能还是复杂变量类型，因此需要迭代获取其子标签，最终得到该复杂变量类型中包含的所有简单变量的name，type等属性取值。

在BPEL的解析阶段，需要解析得到BPEL中定义的变量、活动等节点信息，为下一阶段提取变量取值及属性、活动顺序等约束条件做准备。例如对于<variable>节点，需要解析得到属性messageType的取值，才能找到该<variable>节点定义的变量名，查找过程在后面描述所述；对于提取的活动节点的属性信息，主要用于得到该活动节点中涉及的变量信息，以及获取活动顺序。

先将BPEL解析为DOM树，由BPEL Version2.0的定义可知，BPEL的根节点为<process>，<process>的子节点包括<extensions>,<import>,<partnerLinks>,<variables>,<messageExchanges>,<correlationSets>,<faultHandlers>,<eventHandlers>以及业务执行活动等标签。

BPEL中的<variables>标签仅用于变量的声明，需要根据<variable>命名空间找到对应的WSDL文档并获取该变量的详细信息。该步骤的具体过程为：从<variable>标签的消息类型(messageType)属性信息中获取该变量对应的命名空间，通过命名空间查找到WSDL中的<message>类型定义，然后根据<message>中的<part>子标签，可得到该<message>传递的变量名，然后根据WSDL文档解析即可获得该变量的详细信息。由此，可以得到BPEL中使用的变量的类型等约束条件。

另外，在BPEL的解析阶段，还需要提取业务执行流程，具体的过程为：找到根节点<process>的所有子节点，然后根据<process>的所有子节点名，即可查找到该BPEL中定义的业务执行流程子节点。

(2)约束条件提取

本阶段需要对业务执行流程进行简化，得到需要的流程信息。由BPEL Version2.0的定义可知活动类型包括<receive>,<reply>,<invoke>,<assign>,<sequence>,<if>,<while>,<repeatUntil>,<forEach>,<pick>,<flow>,<scope>,<throw>,<exit>,<wait>,<empty>,<compensate>,<compensateScope>,<rethrow>,<validate>,<extensionActivity>等，其中<throw>,<exit>,<wait>,<empty>,<compensate>,<compensateScope>,<rethrow>,<validate>,<extensionActivity>等活动主要用于抛出异常、结束业务执行流程、等待、数据验证等特殊情况，本发明不予考虑。

在对业务执行流程进行处理时，主要目标是提取业务执行流程以及活动中变量的赋值关系。根据业务执行流程、活动类型、变量的赋值关系以及从WSDL中提取的变量约束条件，自动化生成XML文档用以保存简化的BPEL。其中在处理赋值语句时，需要转化为静态单赋值形式(static single assignment form，SSA)，使得每个变量名在SSA中仅被赋值1次。重命名的过程如下所述：设v为BPEL文档中的变量，i为变量在BPEL文档中的位置，设α(v,i)为BPEL文档中i位置的v之前被赋值的次数。设e为BPEL文档，ρ(e)表示e中所有变量v被v_α(v,i)替换后对应的BPEL文档形式，则对于一个赋值表达式：x＝e，转变成SSA形式为：x_α(x,i)+1＝ρ(e)。对于数组操作，若表达式为：a[e₁]＝e₂，转变成SSA形式为：a_α(x,i)+1[ρ(e₁)]＝ρ(e₂)。

然后利用限界模型检查(Bounded Model Checking)中的方法，根据不同的活动类型对业务执行流程进行改写，使得业务执行流程可以使用if,assignment,assertions等语句以及逻辑运算符表示。对改写后的结果需要使用算法将其规范化，图3为规范化算法的实现。根据业务执行流程中的活动分类情况，结合限界模型检查理论，设定改写规则如下，用于描述如何对活动进行改写：

<receive>活动用于接收匹配的<message>信息，从而获取输入参数，该活动为基本活动，可直接使用赋值表达式将输入参数赋值给相应的变量；

<reply>活动用于发送<message>信息，从而输出活动参数，该活动为基本活动，可直接使用赋值表达式将输出变量的值赋值给输出参数；

<invoke>活动用于调用<partnerLink>中定义的其它Web服务。由于测试人员只能根据portType获取对应的接口说明，无法获取将要调用的Web服务的源代码，因此无法获取被调用的Web服务中的约束条件，只能使用BPEL内置函数getVariableData()来获取调用Web服务后的参数值，并将得到的值赋值给相应的参数；

<assign>活动用于对BPEL活动调用的变量赋值。该活动通常包括多于1个的<copy>子标签，用于指明赋值操作的对象，在获取赋值对象后，即可得到<assign>活动的赋值表达式；

<sequence>活动定义了BPEL中一个顺序执行的活动集合。对于一个<sequence><A1/><A2/><A3/></sequence>活动，各个子活动之间是顺序执行的关系，因此其条件范式为：A1；A2；A3；

<if>活动定义了BPEL中一个选择执行的活动类型，本身即使用if语句。对于<if>活动示例，使用图3所示规范化算法将其规范化，图2展示了将<if>活动进行改写的过程：图2中左侧方框中的代码为BPEL文档中<if>活动的表达形式，该示例活动定义了三种活动情况(A1，A2，A3)；由BPEL文档的定义要求可知，活动A2，A3为活动A1的兄弟节点的子节点，将<if>活动改写为中间方框中的代码，改写规则为：通过递归的方式将多个活动最终表示为两个活动之间的选择，例如，为将A1,A2两个活动的<if>活动改写为中间表达形式使之能够代入图3所示规范化算法，需要将其改写为<if><c><A1></if><else><A2></else>的形式，其中c为if活动的条件判断语句，A1、A2均为输入到算法中进行处理的程序片段，如果<if>活动中包含多于两个的活动主体，需要将后两个活动(A2，A3)先表示为<if><c><A2></if><else><A3></else>的形式，并将其作为新的活动A2’与前一个活动A1表示为<if><c><A1></if><else><A2’></else>的形式，对于多个活动依此类推，有后向前递归直到第一个活动为止；对于中间方框中的代码，结合图3所示规范化算法，即可将其转化为右侧方框中的代码，即<if>活动的条件范式；

<while>活动定义了BPEL中一个循环操作。对于一个<while><condition/><activity/></while>活动，由于while(e){I}→if(e){I while(e){I}}成立，因此将<while>活动转变为：

需要判断循环执行的次数，假设其循环执行N次，则上述转变过程执行N次，并且最后一次循环被替换为assert(！condition)，用以确定循环条件结束。如果该assert语句不成立，说明循环次数N较小，使得对循环的转变失效，此时，需要增大N以确保循环执行转变的正确性。通过上述转变过程，可以将<while>活动转变为等价的<if>语句进行表示，然后使用规范化算法将其规范化；

<repeatUntil>活动也用于定义BPEL中一个循环操作，需要先执行活动体，再根据条件是否成立来决定是否执行下次活动。参照<while>活动中的情况，对于一个<repeatUntil><activity/><condition/></repeatUntil>活动，先将其等价转换为<while>活动：<activity/><while><condition/><activity/></while>，然后按照上述对<while>活动的处理方式进行规范化；

<pick>活动用于定义BPEL中一个选择操作，对于活动<pick><A1/><A2/><A3/></pick>，执行时只能选取其中一个活动，因此其对应的逻辑表达式为：对于其中的各个活动，使用规范化算法将其规范化；

<flow>活动用于定义BPEL中一个并发操作，对于活动<flow><A1/><A2/></flow>，可能的活动执行次序有：{A1；A2}，{A2；A1}，在程序执行时，每次只能有一种活动执行次序为真，因此前述<flow>活动对应的逻辑表达式为：其中活动次序情况即为<flow>活动中包含活动的全排列情况，对于逻辑表达式中的各个活动，使用规范化算法将其规范化；

<scope>活动用于在BPEL中定义一个嵌套的业务执行流程，该活动包含自己的<partnerLinks>,<variables>,<activity>等信息，因此可以将其作为一个独立的BPEL进行解析，并使用上述方法获取其中的约束条件及活动的规范化表示；

<forEach>活动用于在BPEL中定义一个循环活动，该循环活动的执行次数可以根据其子标签<startCounterValue>,<finalCounterValue>计算得出，假设两者差为N-1，则循环执行N次；子标签还可能是<completionCondition>，对应循环终止条件。对于一个<forEach>活动，每次循环执行活动为{<NOT completionCondition>AND<scope>}，循环之间顺序连接，执行N次，因此其对应的规范化表示为：{<NOT completionCondition>AND<scope>}{<NOT completionCondition>AND<scope>}…共循环N次。

通过上述过程处理后，得到的结果即为BPEL活动信息经过模型检查方法以及规范化算法处理后的条件范式，只包含逻辑运算符及if,assignment,assertions等语句。

根据变量取值及属性对应的约束条件以及BPEL活动信息对应的条件范式等约束条件信息，结合Z3-str求解器的语法要求，即可得到最终的约束条件表达文件。

(3)利用Z3-str求解器自动化生成测试用例

Z3是由微软研究院开发的一款SMT(Satisfiability Modulo Theories)求解器，可以用来对数值型、布尔型表达式进行约束求解，在Z34.1的基础上，美国普渡大学YunhuiZheng等人添加了对String型约束条件的处理能力，发布了Z3-str求解器。在Web服务中，需要同时对String型和非String型数据进行推理，因此选取Z3-str作为求解工具。

由WSDL中提取的变量约束条件以及上述经过规范化算法得到的条件范式，需要结合Z3-str的语法要求进行转换得到最终的表达形式，才能使用Z3-str对其进行约束求解。将第(2)步得到的最终的约束条件表达文件代入Z3-str求解器，得到执行路径是否可行以及对应的变量取值；在可行的执行路径中，根据输入变量取值、利用求解器得到解空间中包含预期的程序执行结果。

Z3-str的输入文件是对各个变量取值范围以及逻辑关系等约束条件的规范化表达语句，输出内容为满足约束条件的变量取值；如果对变量的所有取值，都不能满足约束条件，则输入“UNSAT”，表示约束条件无解。

Web服务使用简单对象访问协议(SOAP)进行传递XML格式消息，SOAP使用因特网应用层协议作为其传输协议，因此可以将测试用例的输入封装为SOAP消息。SOAP消息通常包括<Envelope>,<Header>,<Body>,<Fault>等标签，其中<Envelope>,<Body>等标签是必须的标签，分别用于将XML文档标识为一条SOAP消息和包含所有的调用和响应信息；<Header>,<Fault>为可选标签，分别用于包含头部信息和提供有关在处理此消息所发生错误的信息。

通过分析BPEL文档中输入变量对应的WSDL文档，获得其Schema的命名空间，即为SOAP消息中<Envelope>标签的属性值；而<Body>标签的结构由业务执行流程中获取输入变量的活动名及其对应的变量名和取值组成。活动名和对应输入变量名可由BPEL文档解析获得，取值可从Z3-str求解器的解空间中获取。

Web服务测试用例的预期输出也是一个SOAP消息，其<Body>标签的结构包括业务执行流程中获取输出变量的活动名及其对应的变量名和取值。活动名和对应输出变量名可由BPEL文档解析获得，取值即为Z3-str求解器的解空间中输出变量的值。

整个过程中文件转换图如图4所示，经过上述步骤，即可得到Web服务测试用例，一个测试用例示例如图5所示。

本发明在Web服务测试用例的自动生成过程中，通过提取WSDL、BPEL文档中的约束条件，并运用约束求解方法，根据这些约束条件自动化生成测试用例，从而减少测试用例的冗余度，提高覆盖率，提高Web服务测试的效率。

Claims (3)

1.一种Web服务测试用例自动生成方法，其特征是基于文档解析及约束求解自动生成测试用例，包括Web服务文档解析、Web服务约束条件提取和Web服务测试用例自动化生成三部分：

1)Web服务文档解析过程，包括对WSDL文档和BPEL文档的解析，在对WSDL文档进行解析时，得到DOM树，遍历DOM树的节点，得到WSDL文档中定义的所有变量的属性信息；在对BPEL文档进行解析时，得到DOM树，遍历DOM树的节点，分别得到BPEL文档中的变量的取值和属性信息以及活动节点的取值和属性信息；

2)根据BPEL文档中定义的命名空间对应关系，取得BPEL文档中的变量在对应的WSDL文档中的变量的属性信息，由WSDL文档的变量属性信息解析得到变量约束条件，所述变量约束条件包括变量的类型和取值范围；

3)根据解析BPEL文档得到业务执行流程信息，提取出业务执行流程中服务调用、变量赋值的关系，对业务执行流程进行化简，得到只包含活动类型、服务调用和变量赋值关系的业务执行流程中间文件，同时，根据业务执行流程开始和结束活动以及业务执行流程中调用其他服务时调用的变量名，即可得到该Web服务的输入、输出变量名；

4)利用静态单赋值形式对BPEL文档中的变量进行重命名，使得对每个变量的赋值操作最多进行一次；

5)利用模型检查方法，根据BPEL文档中不同的活动类型，将业务执行流程改写为使用语句if、assignment、assertions以及逻辑运算符表示，并使用规范化算法将改写后的业务执行流程中间文件规范化表示为条件范式；所述规范化算法如下：

P、P1、P2均为输入到算法中进行处理的程序片段

G、c均为if语句中条件判断语句，这里G＝true

procedure NORMALISE(P,G)

if P是一个赋值语句或判断语句then

6)根据步骤2)-5)中提取的变量约束条件、条件范式以及Z3-str求解器对所输入文档的语法要求，生成符合Z3-str求解器输入文档格式要求的约束条件；

7)将步骤6)中生成的约束条件代入Z3-str求解器，得到可行解空间及变量取值，Z3-str求解器的输入文件是步骤6)得到的约束条件，输出内容为满足约束条件的可行解空间；如果对变量的所有取值，都不能满足约束条件，则输入“UNSAT”，表示约束条件无解；对于可行解空间，结合Web服务文档解析得到的Web服务输入、输出变量名，即可获得Web服务输入、输出变量的取值，即为测试用例中输入、输出变量的取值；根据输入和输出变量名及其取值，结合SOAP协议的定义，自动化生成SOAP消息表示的测试用例，即为Web服务的测试用例。

2.根据权利要求1所述的一种Web服务测试用例自动生成方法，其特征是步骤4)中，重命名的过程如下所述：设v为BPEL文档中变量，i为变量在BPEL文档中的位置，设α(v,i)为BPEL文档中i位置的v之前被赋值的次数，设e为BPEL文档，ρ(e)表示e中所有变量v被v_α(v,i)替换后对应的BPEL文档形式，则对于一个赋值表达式：x＝e，转变成SSA形式为：x_α(x,i)+1＝ρ(e)，对于数组操作，若表达式为：a[e₁]＝e₂，转变成SSA形式为：a_α(x,i)+1[ρ(e₁)]＝ρ(e₂)。

3.根据权利要求1所述的一种Web服务测试用例自动生成方法，其特征是步骤5)中，根据BPEL文档中不同的活动类型，对业务执行流程的改写规则为：

<receive>活动：直接使用赋值表达式将输入参数赋值给相应的变量；

<reply>活动：直接使用赋值表达式将输出变量的值赋值给输出参数；

<invoke>活动用于调用BPEL子节点<partnerLinks>中定义的其它Web服务，使用BPEL内置函数getVariableData()来获取调用Web服务后的参数值，并将得到的值赋值给相应的参数；

<assign>活动用于对BPEL活动调用的变量赋值，在获取赋值对象后，即可得到<assign>活动的赋值表达式；

<sequence>活动定义了BPEL中一个顺序执行的活动集合，活动集合的各个子活动之间是顺序执行的关系，直接使用规范化算法得到条件范式；

<if>活动：改写为两个活动之间的选择，然后使用规范化算法得到条件范式；

<while>活动：对于<while>活动，while(e){I}→if(e){I while(e){I}}成立，将<while>活动转变为等价的<if>语句进行表示，再行进规范化；

<repeatUntil>活动：对于一个<repeatUntil>活动，先将其等价转换为<while>活动，然后按照上述对<while>活动的处理方式进行规范化；

<pick>活动：<pick>活动通过逻辑表达式实现，对于<pick>活动中待选择的各个活动，使用规范化算法进行规范化；

<flow>活动：<flow>活动通过逻辑表达式实现，对于逻辑表达式中的各个活动，使用规范化算法将其规范化；

<scope>活动：将<scope>活动作为一个独立的BPEL进行解析，再根据解析后的活动进行规范化；

<forEach>活动：对于一个<forEach>活动，每次循环执行活动为{<NOTcompletionCondition>AND<scope>}，循环之间顺序连接，执行N次，<forEach>活动对应的规范化表示为：{<NOT completionCondition>AND<scope>}{<NOTcompletionCondition>AND<scope>}…共循环N次；

通过上述改写处理后，得到的结果即为BPEL活动信息经过模型检查方法以及规范化算法处理后的条件范式，只包含逻辑运算符及if、assignment和assertions语句。