基于模型的自动化测试工具的实现_毕业设计论文(编辑修改稿)

基于模型的自动化测试工具的实现_毕业设计论文(编辑修改稿)内容摘要：

at Enterprise Linux），浏览器（IE、FireFox），网络协议（IPvIPv6），处理器平台（Intel、AMD）和数据库（MySQL、Sybase、Oracle），一共32223=72种硬件平台。 pairwise测试只需要设计如下10个测试，就覆盖了每一种影响因素和另外一种影响因素的所有组合。 编号操作系统浏览器网络协议处理器平台数据库1XPIEIPv4IntelMySQL2XPFireFoxIPv6AMDSybase3XPIEIPv6IntelOracle4OS XFireFoxIPv4AMDMySQL5OS XIEIPv4IntelSybase6OS XFireFoxIPv4IntelOracle7RHELIEIPv6AMDMySQL8RHELFireFoxIPv4IntelSybase9RHELFireFoxIPv4AMDOracle10OSXFireFoxIPv6AMDOracle表22 pairwise测试的配置即使被测软件没有配置选项，软件仍要处理一些输入。 例如，Word 2010应用程序至少允许用户对拖黑文字进行10种不同操作：设为上标、设为下标、加粗、加下划线、设为斜体、加删除线、加灰色背景、加阴影效果、加倒影效果、加荧光效果。 相关的字体处理函数需要根据用户的输入来相应修改文字效果，该函数需要在所有的可能情况下都正常工作，而一共有210=1024种可能。 前面的经验告诉我们，3way的测试用例就能够达到90%以上的错误发现率，具有较高的收益代价比。 图24 3way覆盖数组图24列出了对于具有10个变量、每个变量各有两种取值的3way覆盖数组。 覆盖数组并不唯一，这只是其中一种情况。 tway覆盖数组的特点是，任意t个参数的所有排列组合都将分别出现在覆盖数组的某一行中，比如上图中的ABC、DEG、HIJ，三个参数共有8种排列组合（000、00001100、101111）都被覆盖数组所覆盖。 覆盖数组的每一行对应一个测试用例，相比之前的1024个测试用例，组合测试只需要13个测试用例。 组合测试用例生成的本质是构造覆盖数组，最早的构造方法是利用正交数组，其定义和覆盖数组类似，唯一区别在于正交数组中所有t元组出现的次数相同，而覆盖数组不保证这一点。 在某些特殊的情况下，正交数组就是最优的覆盖数组，为此，如何构造正交数组问题吸引了大量的研究者研究。 Sloane在其网站上总结记录了超过200个正交数组[18]。 利用计算机也可以自动求解出部分类型的正交数组，由已知的大覆盖数组构造小覆盖数组的方法被称为坍塌[19]。 坍塌的缺陷在于，最终得到的覆盖数组往往并不是最优解，一般比最优解要大。 另一种构造方法刚好相反，是由已知的小覆盖数组递归构造出大覆盖数组。 构造最优覆盖数组的实际上是一个NP完全问题[20]，我们知道，NP完全问题是一系列可以互相转化的问题。 于是我们可以利用和借鉴其它NP完全问题的研究成果来构造覆盖数组，比如第一个被证明为NP完全问题的可满足性问题，整数规划问题，图论问题等等。 数学构造方法仅限于某些特定大小或者组合强度的覆盖数组的构造，不具有通用性。 NP完全问题则是困扰了人类多年的超级难题，目前还没有突破性解法，所以转化为其它问题也是大同小异。 但我们可以利用局部搜索方法，比如启发式搜索算法，在较短的时间内就可以搜索出近似最优解。 启发式搜索算法是利用一个已有的数组，通过合适的变换得到一个更优的覆盖矩阵，不断地变换直到得到一个较优的矩阵。 近年来流行的模拟自然界行为的智能优化算法中，目前已经应用到组合测试中的主要有模拟退火、禁忌搜索、遗传算法等等。 更为有效的方法是贪心算法，贪心算法的思想是从空矩阵开始，然后逐行或者逐列地扩展矩阵，直到所有的t元组都被覆盖。 按照扩展方式的不同，又可以分为一维扩展和二维扩展。 商业工具AETG最先提出一维扩展的方法[21]，依次增加一行，每次尽可能多地覆盖未覆盖的t元组。 微软开发的工具PICT采用类似AETG的方法生成测试用例[22]，不同之处在于，PICT每次产生的结果是相同的。 Lei等人提出的IPO（Inparameterorder）[23]方法属于二维扩展，该算法主要针对pairwise测试。 首先构造前两个参数的所有组合，形成一个小的矩阵，再分别为矩阵添加一列和必要多的行，覆盖完所有元组后结束。 我们将模仿PICT工具中pairwise算法的主要思想，使用一维扩展的贪心算法来生成覆盖数组。 同时给系统留好接口，利于以后换用新的pairwise生成算法，具体的算法设计将在第四章介绍。 . MBT预期输出生成三大关键技术就只剩下辅助性内容生成工具了，辅助性工具主要还是为了解决预期输出的生成问题。 前面我们构造了系统的模型，模型描述了系统的状态和状态之间的动作，这些动作都是由一个个函数和方法的调用序列组成的。 SUT提供的API往往不能和测试用例的要求完全契合，为了让测试用例能够顺利地在SUT上执行，需要测试人员在SUT之上再包装一层，即图21中的适配器层。 严格地说，我们编写的工具只负责生成基本的测试用例框架，或者称为抽象的测试用例。 测试用例中相当于使用了打桩的设计模式，桩的实际实现由最终的测试人员补充完成，桩的实现包括对SUT提供的API的封装组合和测试判断逻辑的编写。 我们把这些桩叫做token，token对应于适配器层中的某个函数和方法，两者可以直接一一对应，也可以先序列化为可扩展标记语言（XML，Extensible Markup Language）文件再利用XML解析器之类的工具生成测试用例。 这样MBT的整个测试工具都变得项目之间可移植了，如果某一测试条件和预期结果不同则在token中抛出异常，抛出的异常随后被测试工具捕获，最终判定该测试用例不通过。 图25展示了一个测试工具自动生成的测试用例，用户需要实现token_1和token_2的具体逻辑，然后测试用例就能够被真正执行了。 token_1和token_2执行过程中如果发现错误会触发异常，程序打印出错误提示，同时导致测试用例的总错误个数加一。 反之，一切正常并给出通过提示。 图25 测试用例示例另外我们也可以利用pairwise来完成部分情况下预期输出的生成。 对于相同输出结果的某些参数取值组合，把输出结果也当作pairwise算法输入参数的一项，输出结果列和其它输入参数的区别在于其取值唯一。 PICT工具还支持混合组合强度的测试用例生成，以及输入各种约束，比如指定某些参数的组合形式必须出现或者不出现，所以具有较强的预期输出生成能力。 不过如果预期输出涉及复杂的判断逻辑，还是使用委托给token来处理的方法较好。 第三章 系统架构3.. 功能概述及流程课题要求完成的基于模型的自动化测试工具的功能包括：支持输入FSM模型、支持添加token、支持pairwise组合测试、支持生成测试用例框架、支持序列化FSM模型到文件和反序列化读入。 其中考虑到token的可复用性，用户可以直接在工具上定义token顺序执行序列组成的函数过程，更复杂的函数过程则通过添加新的token实现。 用户使用该工具生成测试用例的流程如下：图31 生成测试用例流程用户可以直接绘制FSM模型，或者在以前保存的模型基础上修改模型，工具支持FSM模型的序列化与反序列化。 绘制FSM模型时首先需要定义一些FSM的状态转换动作中用到的token和这些token组成的若干函数过程，随后在模型绘制面板中画出FSM模型相应的有向图。 FSM模型的有向图包括代表不同状态的圆形节点，以及代表状态间转换动作的弧线。 一个token或函数过程可以在相同的或者不同的状态转换动作中被反复使用，只要求这些token或函数过程方法头中所定义的参数被正确地赋予某个常量或者变量。 变量可以有多个允许的取值，用户在pairwise相关面板输入各个变量的可能取值，接下来工具将分析FSM模型寻找所以可执行路径，同时结合路径长度限制和pairwise技术来生成测试用例。 最后用户还可以在生成的测试用例中再人工选择部分测试用例出来，保存为最终需要被执行的测试用例。 . 系统架构工具设计的主要目的是为了自动生成测试用例，而模型是驱动MBT各测试过程的根本，所以系统架构中最核心的部分是FSM的数据模型，数据模型描述了FSM中各个状态和转换动作的详细属性。 比如状态名称，转换动作名称，用户所定义token的名称和所需输入输出参数，函数过程的名称和其中包含的token执行序列等等。 图32 系统总体架构用户不是生硬地使用形式化语言来描述FSM数据模型，工具提供了可视化界面，实现了鼠标选取不同绘图元素再拖拽调整的绘图方式。 此外，为了持久化保存绘制好的FSM模型，系统包含了序列化模块，用于模型的序列化与反序列化。 测试用例的生成过程是基于两大模块来完成的，FSM模型遍历模块负责生成各种可执行路径，pairwise测试模块负责生成参数变量取值的不同组合。 最后把参数变量取值代入可执行路径中，即得到测试用例。 第四章 系统各功能实现4.前一章中我们介绍了系统的整体架构，下面将逐一介绍系统各模块的具体实现，整个系统都使用C语言编写完成。 . FSM数据模型实现我们知道FSM数据模型是影响系统的关键，图41列出了系统实际实现过程中FSM数据模型相关各类之间的关系。 对于一些简单的set和get方法图中并没有标出，其它辅助性的方法也予于省略。 图41 FSM数据模型的类图类FSM中记录着系统FSM数据模型的所有信息，它里面有两个链表分别记录FSM的状态实例和转换动作实例，同时有两个Dictionary分别记录状态和转换动作的名称与实例之间的映射关系。 状态由类State描述，该类的属性有状态标识id、状态类型type和状态后置动作链表nextActions。 我们定义了三种状态类型：Entry、Free和Exit，Entry和Exit分别代表初始状态和终止状态，Free代表其他自由状态。 状态动作由类Action描述，该类的属性有动作标识id、出发状态名称from、目的状态名称to以及动作的方法实现链表stubs。 在寻找可执行的测试路径过程中，程序从初始状态开始深度遍历FSM有向图，直到到达某个终止状态或路径长度达到限制才结束。 类Tour的每个实例代表一条被发现的可执行路径，因为用户并不参与Tour的命名，所以该类中设置了一个全局静态的标识计数器域idCounter，每新创建一个新实例时计数器自动加一，必要的时候可以通过ResetIdCounter方法重置计数器。 除了以上代表FSM实体组成部分的类，FSM数据模型还必须描述SUT相关部分的信息。 抽象类ActionImpl描述了测试中调用的SUT接口，准确地说是测试适配器层中的接口，它的两个抽象方法GenDefa。