基于MBT的自动化测试工具——GraphWalker介绍和实际使用

GraphWalker是一个开源的基于模型的自动化测试工具，它能够用来经过图形测试模型来自动生成测试用例。 
本文主要描述了使用yed画出FSM, EFSM模型图（常见的流程图），而后使用GraphWalker命令生成手工自动化用例，最终经过python将手工用例读取后自动执行并生成执行报告。

一： GraphWalker概述

         GraphWalker就是一个基于测试模型的用例生成工具。它主要应用于FSM, EFSM模型。能够用来它能够直接读取FSM, EFSM图形模型、json模型、生成测试用例。那什么是MBT呢？ MBT中文名称为基于模型的测试, 基于模型的测试属于软件测试领域的一种测试方法。MBT步骤以下：首先由被测系统（SUT， system under test ）的一些（一般是功能）方面描述，构建出被测系统的模型。再根据模型或模型中的一部分部分生成测试用例。进而进行软件测试。常见的MBT中模型一般有下列几种：

• 前置后置条件模型:　Pre and post condition models (State based, OCL)
•  基于转换的模型:　Transition based models (FSM, EFSM)
• 随机模型：Stochastic models (Markov chains)
• .数据流模型:　Data-flowmodels(Lustre)      

二：工具下载：

     一、画图工具YED

        工具下载官网地址：https://www.yworks.com/products/yed，用该工具画出来的图大体以下：

      二、 GraphWalker的jar包下载：

        https://graphwalker.github.io/   

 

三：学习笔记整理  （关键知识点）

      一、顶点：如上图所示，全部的顶点好比Start,V_ClientNotRuning.一个顶点称为节点，一般表示为一个框表示咱们想要检查的预期状态。在任何实现代码/测试中，能够经过断言或者数据校验改结果。常见有如下几种顶点：

• Start顶点：start顶点不是必需的。若是使用，则必须有1个（且只有1个）顶点名称为：start.从start顶点出发只能有1个边。start顶点不会包括在任何生成的测试路径中，它只表示一个开始位。

• BLOCKED顶点：  包含此关键字的顶点或边将在生成路径时排除。若是它是一个边，它将简单地从图中删除。若是它是一个顶点，顶点将被删除与其内外边缘。

• SHARED顶点： 意味着GraphWalker能够跳出当前模型，到任何其余模型到具备相同SHARED名称的顶点。 语法是： SHARED：SOME_NAME

• INIT顶点： 只有一个顶点能够有这个关键字。在模型中使用数据时，须要初始化数据。这就是这个关键字。容许在更多的顶点中使用INIT而不仅是一个。 语法是： INIT：loggedIn = false; rememberMe = true;

      二、边：如上图的e_Init。表示从一个顶点到另外一个顶点的方法。这是为了达到下一个状态须要作的任何动做。它能够选择一些菜单选项，单击按钮等测试动做。GraphWalker只接受单向有向边（箭头）。边

  的函数下有时候会有不一样的字符串，好比[rememberMe&vaildLogin]和/rememberMe=false； vaildLogin=true；  表示不一样的规则，基于表有以下规则：

• 守卫(Guards)：他们的角色与if语句相同，而且使边有资格或者没有资格被访问。

  守卫guard是一个用方括号括起来的JavaScript条件表达式只有一个。[rememberMe&vaildLogin]

• 操做(Action)：它放在正斜杠以后。Action能够有多个，每一个语句必须以分号结尾。

  /rememberMe=false; vaildLogin=true ；action是动做代码，它的执行结果将做为数据传递给守卫。

     三、路径生成器:生成器是决定如何遍历模型的算法。不一样的生成器将生成不一样的测试序列，而且它们将以不一样的方式遍历模型。多个发生器能够串联。常见有如下几种：

• random( some stop condition(s) )：以彻底随机的方式浏览模型。也称为“醉汉走路”或“随机步行”。该算法经过随机从顶点选择出边，而且在下一个顶点时重复此过程。
• quick_random( some stop condition(s) )：尝试运行经过模型的最短路径，但以快速的方式。
• a_star( a stop condition that names a vertex or an edge )：将生成到特定顶点或边的最短路径。

      四、结束条件：常见有如下几种：

• edge_coverage( an integer representing percentage of desired edge coverage )：边覆盖率达到某个值时，模型遍历结束。中止标准是一个百分比数字。当在执行期间达到所穿过的边的百分比时，中止测试。若是一个边被遍历超过一次，当计算百分比覆盖率时，它仍然计为1
• vertex_coverage( an integer representing percentage of desired vertex coverage )：顶点覆盖率达到某个值时，模型遍历结束。中止标准是一个百分比数字。当在执行期间达到所遍历的顶点的百分比时，中止测试。若是顶点遍历超过一次，当计算百分比覆盖率时，它仍然计为1。
• requirement_coverage( an integer representing percentage of desired requirement coverage )：需求覆盖率达到某个值时，模型遍历结束。中止标准是一个百分比数字。当在执行期间达到所需求的百分比时，测试中止。若是需求遍历超过一次，在计算百分比覆盖率时仍会计为1。
• dependency_edge_coverage( an integer representing dependency treshold )：高于依赖阈值的边都被覆盖时，模型遍历结束。每一个边能够设置一个依赖值dependency（0-100之间的百分比数字）。中止标准是一个百分比数字。当在执行期间，全部高于或等于依赖值边被遍历彻底时，中止测试。若是一个边被遍历超过一次，当计算百分比覆盖率时，它仍然计为1。
• reached_vertex( the name of the vertex to reach )：中止标准是指定的顶点。当在执行期间到达顶点时，测试中止。
• reached_edge( the name of the edge to reach )：中止标准是指定的边。当在执行期间到达这条边时，测试中止。

     五、GraphWalker提供3种工做方式:

• 做为第三方库，可被java测试程序直接调用。若是是使用java语言来编写自动化测试框架，能够考虑使用这种工做方式。
• 做为可执行程序，以offline模式，加载model，直接运行。接口测试经常使用此方法一次获取完整的手工测试用例。
• 做为可执行程序，以online模式，做为service，提供服务。改方法方便读取自动化测试用例，可是每获取一次须要调用一次service，有点麻烦。  

      六、学习参考文档：

• 官网：http://graphwalker.github.io/
• 中文翻译：https://cloud.tencent.com/developer/article/1004579 

 四：初体验

        以2.1的图为例，是官网的的demo图。下载地址：http://graphwalker.github.io/Model_design/，找到图片后双击便可下载：Login.graphml

       一、可执行程序，以offline模式生成自动化用例，路径生成器使用经常使用的quick_random，结束条件使用vertex_coverage100%覆盖，在jar包目录下执行命令java -jar graphwalker-cli-3.4.2.jar offline -m Login.graphml "quick_random(vertex_coverage(100))" ，以下会生成对应的自动化用例。

     也能够把这些用例保存在txt文件中：java -jar graphwalker-cli-3.4.2.jar offline -m Login.graphml "quick_random(vertex_coverage(100))" > login_test_case.txt

    二、可执行程序，以online模式生成自动化用例，使用相同的结束条件和路径生成器，

      第一步执行命令：java -jar graphwalker-cli-3.4.2.jar -d all online -s RESTFUL -m Login.graphml "quick_random(vertex_coverage(100))" ，结果以下：

  第二步：简单的在web浏览器访问:http://localhost:8887/graphwalker/getNext

 

    再访问一次：

 五：实际使用心得

     目前测试工做中，经常使用的就是状态机测试和模块间的数据流测试。这个工具就很是适合这两类图的测试。在生成手工用例后，怎么转变成自动化测试用例是考虑的主要问题。下面以实际工做中的一个状态机为例

     第一步 ： 把工做中的状态机图，使用yed转换成graph图。

     状态机以下：

  yed 画图以后：

   

  第二步：执行graphwalker命令生成测试用例，报错 java -jar graphwalker-cli-3.4.2.jar offline -m rtp_status.graphml "quick_random(edge_coverage(100))" > bpn_status_test_case.txt。

  执行报错：报错缘由：由于状态机内存在终点，致使算法执行不下去报错失败。那这就不适应有终点的状态机了？

 忽然想起一句名言： 我是环绕着一个圆圈而行的。越接近终点也就越接近起点——-（狄斯）。人丑多读书仍是有点用处的，灵机一动，那就干脆把全部终点再指定起点，起点又算是一笔新的数据，讲图改造后以下：

    虽然变丑了，可是再执行不会报错。目的达到了(每次执行的产生的用例是不彻底一致的)。用例以下图：

   

 

   第三步：思考怎么转变成自动化用例。

   思考问题：

• 生成的用例集，怎么区分每一条用例。

         从终点到顶点V_MakeData的边都没有标签，那python读取文件时，能够根据两个{}以前肯定是一条用例。

• python读取每个顶点和每个边，意味着什么？ 

         边意味着执行某个程序，顶点意味着检查表的数据状态。那在画图时，肯定好边和顶点的描述，作好string和代码对象的映射，读取到边，就启动程序，读取到顶点，就执行某个表的校验函数便可。

• 怎么设计总体架构？综上问题描述，大体思路整理以下：

第四步：代码实现：

一、主要业务流程：

       二、生成python自动化用例使用的方法，考虑到其实执行的步骤是明确的，惟一会变化的就是执行命令每次产生的用例不一致。那每次替换用例case就能够了。作成了文件替换动态生成自动化用例的模式。

       三、自动化用例剩下以下:

四、说明：

      在编写自动化生成用例前，已存在构建好的python自动化pyuint测试框架，我这边结合起来使用就很方便。这个技术结合pyunit框架作效果更好。

六：总结

      这个工具的学习来源于其余部门测试同事的分享，他们把这个工具应用于web平台的相似登录系统的测试，以为确实好用。虽然这个工具和理念很早就已经有了，貌似2016年左右就已经很流行了，但不影响去深刻的学习和研究。学习和研究工具的目的，最终都是把它应用到实际项目之中。相似这种状态机测试，若是这时在一个地方增长了一个状态。那我只须要改下图，再补充好对应顶点和边的部分代码，就能够获取全流程的状态机测试用例。

      这个工具仍是很强大的，特别是在数据流的各类处理上，有时间仍是建议去看下官网，毕竟介绍更详细。