【腾讯TMQ】基于模型的自动化测试工具——GraphWalker

GraphWalker是一款用于基于模型的测试工具,它支持FSM和EFSM模型,能自动生成测试用例。通过模型的顶点和边定义,结合守卫和操作,GraphWalker能够构建测试模型并生成执行路径。工具提供了多种工作模式,包括作为Java库、离线模式和在线服务,以及RESTful和WebSocket服务。此外,它还提供了丰富的命令行选项和API接口,便于进行自动化测试和模型管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、概述

GraphWalker就是一个基于测试模型的用例生成工具。它主要应用于FSM, EFSM模型。可以用来它可以直接读取FSM, EFSM图形模型、json模型、生成测试用例。

二、背景知识

要了解GraphWalker首先要了解MBT是什么。

MBT中文名称为基于模型的测试, 基于模型的测试属于软件测试领域的一种测试方法。MBT步骤如下:首先由被测系统(SUT, system under test )的一些(通常是功能)方面描述,构建出被测系统的模型。再根据模型或模型中的一部分部分生成测试用例。进而进行软件测试。

2.1 模型(Model)

模型的目的就是用来为构造测试用例而进行的被测系统描述。

在构造模型的这个阶段就可以已经发现许多问题。

模型的关键:

高度抽象

模型还包括被测系统的预期输出。

两个主要方面:

设计模型

测试模型

MBT中模型通常有下列几种:

前置后置条件模型: Pre and post condition models (State based, OCL)

基于转换的模型: Transition based models (FSM, EFSM)

随机模型:Stochastic models (Markov chains)

数据流模型: Data-flowmodels(Lustre)

模型验证:

语法

行为

FSM举例:

一个测试模型可以由箭头和节点组成如下图所示。

一个箭头,代表了一次测试动作;

一个节点,代表一次测试验证。

2.2 测试需求选择

Test requirements selection

目的:

指导测试用例生成器( test generation)如何生成用例。

测试需求选择包含3方面:
  1. 模型中的目标(结束条件)

  2. 覆盖准则(路径生成准则)

状态覆盖

转换覆盖

  1. 行走算法

随机行走

覆盖引导

2.3 测试用例生成

Test generation

按模型及测试需求选择来生成测试用例。GraphWalker就是完成这部分工作的一个开源的java工具。

2.4 测试具体化

Test concretization

从测试套件到可执行级别,可以自己实现插件完成这部分功能。将测试用例转化成可执行脚本。

2.5 执行测试

Test execution

执行测试,并比较预期结果。

三、GraphWalker能做什么

GraphWalker就是一个基于测试模型的用例生成工具,完成上图中Test generation的工作。给出一个测试模型及测试需求选择,GraphWalker能生成相应测试路径。由这个测试路径,可以用来执行你的测试脚本。它主要应用于FSM, EFSM模型。可以用来它可以直接读取FSM, EFSM图形模型、json模型、生成测试用例。

四、通过GraphWalker建模

模型的目的是表达被测系统的预期行为。为此,我们使用有向图,其中顶点(或节点)表示一些期望的状态,并且边(弧,箭头,过渡)表示为了实现期望的状态需要做的任何动作。

例如,让我们来看一个需要验证的网站,然后才能访问网站内容。使用有向图设计测试可能如下所示:

4.1 顶点(Vertex)

顶点表示我们想要检查的预期状态。在任何实现代码/测试中,你可以通过断言或者数据校验改结果。

一个顶点称为节点,通常表示为一个框。

GraphWalker不在乎顶点的颜色或形状。

4.2 边(Edge)

表示从一个顶点到另一个顶点的方法。这是为了达到下一个状态需要做的任何动作。它可以选择一些菜单选项,单击按钮等测试动作。

GraphWalker只接受单向有向边(箭头)。
GraphWalker不关心边有什么颜色或宽度。

4.3 建模规则

Start顶点

start顶点不是必需的。

如果使用,则必须有1个(且只有1个)顶点名称为:start.

从start顶点出发只能有1个边。

start顶点不会包括在任何生成的测试路径中,它只表示一个开始位。

顶点或边的名字(name)

名称是第一个单词,位于标签中边或顶点的第一行。

标签(Lable)

标签是点或边上的所有文字描述。

守卫(Guards)仅用于Edge

守卫guard是一种只与边相关的机制。他们的角色与if语句相同,并且使边有资格或者没有资格被访问。

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

[loggedIn == true]

上面意味着如果属性loggedIn等于true,则边是可访问的。

操作(Action)仅用于Edge

动作是仅与边相关联的机制。这是我们要在模型中执行的JavaScript代码。它放在正斜杠之后。Action可以有多个,每个语句必须以分号结尾。

/loggedIn=false; rememberMe=true;

action是动作代码,它的执行结果将作为数据传递给守卫。

示例:

此示例说明Action和Guard如何工作。

让我们从Start顶点开始:

e_Init/validLogin=false;rememberMe=false;

边缘的名称是e_Init,后跟一个正斜杠,表示从该点开始直到行尾的文本是[action]代码。该操作初始化2个属性:validLogin和rememberMe。

当我们走过上边缘时,我们到达v_ClientNotRunning顶点。这个顶点有2个边沿,都有Guards。由于validLogin和rememberMe在这一点上被初始化为false,因此只有一个边可以用于步行:边e_StartClient具有顶点v_LoginPrompted作为目的地。

假如,我们已经遍历边e_ToggleRememberMe和e_ValidPremiumCredentials,并再次到达顶点v_ClientNotRunning࿰

### 商城项目的自动化测试实践 #### 测试框架的选择 对于商城项目而言,选择合适的自动化测试工具至关重要。例如,在移动端iOS平台上的逻辑自动化测试实践中提到,通过腾讯TMQ进行iOS端的自动化测试能够有效提升效率[^1]。 #### 用户交互流程模拟 在设计商城项目的自动化测试方案时,应站在最终用户的视角来考虑整个购物流程。这包括但不限于商品浏览、加入购物车、结算支付等功能模块。每个功能模块都可以被拆分为多个独立的小型测试用例来进行验证。例如: - 商品详情页加载速度及显示准确性; - 加入购物车按钮响应情况及其后的库存更新机制; - 支付网关接口调用的成功率以及异常处理能力等。 这些具体的业务场景不仅限于界面上的操作,还涉及到后台服务之间的通信协议和数据库状态变更等方面的内容[^2]。 #### 关键路径优先级划分 并非所有的操作都需要完全依赖UI级别的自动化脚本来完成。对于那些不直接影响用户体验但又十分重要的环节(比如订单创建过程中的某些参数校验),可以直接利用API请求的方式来简化测试步骤并提高执行效率。这样既能保证核心交易链路的安全稳定运行,又能减少不必要的资源消耗。 ```python import requests def create_order(api_url, payload): response = requests.post(url=api_url, json=payload) if response.status_code == 200: return True else: raise Exception(f"Failed to create order with status code {response.status_code}") ``` 此代码片段展示了如何通过POST方法向指定URL发送JSON格式的数据体以创建新订单实例,并根据返回的状态码判断是否成功。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值