基于编排场景web服务相符性测试.pptVIP

这是前面的编排中交易成功的场景，可以看到4个角色之间共有十个交互 包括货源充足的响应交互以及bankID合法的响应交互(3,8) * 我们针对测试已实现的Web服务与编排的一致性问题，尝试设计了研究框架 本次报告主要介绍其中的场景精化和测试数据生成模块 首先介绍场景的形式化定义 I是变量类型声明的集合，每个类型有自己的类型名，具体的定义在引用的外部XML Schema Definition File中，xsd用于描述xml文档的结构 V：每个变量的类型声明须在I集合中 A是交互序列a1,a2,...,an，交互可以分为请求或应答。含义：某角色的某变量，通过某操作，传递给另一角色的某变量 对于每一个交互，guard是交互的前置条件，满足guard才可完成交互 * 这是PO类型的xml schema定义，描述了订单数据的文档结构 红色标注的地方xml-schema指示器，minmax可以定义文档中元素出现的次数，choice表示可以选择不同的子类型 由于指示器的存在，满足同一xml-schema定义的文档可能呈现不同形式，也就是说在同一场景，交互序列已经确定，由于交互变量数据的不同，也会对交互产生影响，影响测试（因为编排可以是数据驱动的） 为了解决这个问题，我们可以对类型进行划分，使划分后的子类型结构确定，一种类型可以划分成多种确定的子类型。 通过对数据类型的划分，同时也实现对场景的划分。划分后的场景与原场景只有类型信息不同，新场景引用的新的xml-schema定义 划分后可以分别测试 * 对与minOccur maxOccur 指示器，元素出现次数不固定的情况，我们划分为多种子情况，分别固定元素出现次数 对于choice指示器，元素可以选择不同的孩子，我们根据选择的分支划分多种情况，每种情况取确定的子元素，去掉其他分支 需要说明的是，经过我们规则进行划分，对于满足子类型定义的xml文档，依然满足原始XML Schema定义 * 我们可以看到，PO元素的子元素goods原先出现次数不确定。划分后的子类型出现次数分别为确定的1次和2次。 这样划分场景带来的问题是，如果指示器数量很多，或场景中交互数量很多，这些因素组合起来所划分的场景数量会非常巨大，所以我们引入组合数学的方法 又叫基于组合覆盖的软件测试(简称组合测试，Combinatorial Testing或Interaction Testing) 相对于直接将因素的取值直接相乘所得到的巨大数目，组合方法仅考虑任意两个或者几个因素之间的组合排列情况，可以大大减少组合情况数 当在某个组合测试中，强度为二则意味着只考虑变量之间的两两组合。 * 输入的每一个元素都是变量水平对 输出是对变量水平的组合 约束：蕴含表达式 Cascade本身的变量可以取值：integer string double 在本文用于精简子类型情况，我们把划分的情况作为变量V以及水平L 在已经实现的模型转化工具，我们把类型定义建模为类型树模型 * 两种指示器对树结构的约束：max min约束了节点出现次数，choice体现了孩子节点的分支选择 m和n分别是父子节点 * 左边的图即为PO的类型树，右边是节点和边上标注的信息 E1边上标注的信息，表示coupon元素出现次数 E4边上标注的信息，表示选择cashback元素和它出现的次数 在我们实现的算法中，通过对树中边的遍历，我们可以将所有根据划分规则产生的子类型情况，转化为cascade工具的输入 对两种指示器，分别作不同的处理 * 以前面给出的编排中的成功购买场景为例 变量类型含有不确定因素的有：前面提到的订单类型（purchaseOrder），银行信息类型（bankInfor ），银行卡号信息类型（bankIDInfo ） 我们将多棵树的影响因素放到一起，共同利用组合方法进行精化 在成功交易的场景中，bankID须与bankInfo有对应关系，我们可以再cascade中写出约束进一步确保精化 Totally, there may be 2*2*3*2*3*3=216 sub-type即216种子场景 Here we assume strength=2 结果是10种子场景 我们可以根据每一行的组合情况，生成新的子类型树，以第一行为例 * 下面介绍测试数据生成模块 * 综合考虑两种约束，生成最终的测试数据 1每个交互的前置卫士条件Guard 2XML Schema定义对xml文档中数据的约束对 ，XML 元素的限定被称为 facet 。 * 对于值的约束，表示形式是角色的某个变量，一个操作符，后面跟一个表达式或另一个变量 只要交互存在消息的传递，卫士Guard就含有对类型信息的约束，生成交互传递的变量类型都要符合XML-Schema定义 前