前言
我是从今年5月份第一次接触流马这个平台。第一次听到这个名字的时候,就觉得挺有趣的,猜测其名字应该是取自诸葛亮的“木牛流马”,后来和作者证实了一下,确实如此。当初诸葛亮发明木牛流马是为了提高运输效率,而流马测试平台是为了提高测试效率,可以说这个名字取得“恰到好处”。
本文一万两千字左右,我写了好多天,可能是我耗时最久的一篇文章。其实写文章不是最难的,难的是边学习、边摸索、边踩坑、边解决问题、边写文章记录、边总结。所以写得还算是比较用心的,整体来说也比较详细。读起来可能会有点长,大家可以先关注收藏、后期有时间、空下来了再照着文章内容仔细研究。内容大致分为以下四个部分:
【简介篇】
- 项目概述:技术栈、工作原理
- 项目功能简介:功能特点
【部署篇】
- 部署规划
- 依赖环境部署(JDK、MySQ、NGINX、Git、NodeJS、Python3)
- 代码打包:克隆项目、前端代码打包、后端代码打包
- 项目部署:前端部署、后端部署、执行引擎部署
【使用篇】
- 接口测试:创建接口(添加引用公共参数、添加引用自定义参数)、测试用例(参数关联)、业务流程测试实践
- web自动化测试:元素管理(添加元素)、测试用例(添加元素)、设计测试场景
- 测试计划、测试集合与测试用例相互之间的关系
【总结篇】
- 使用总结:常见的使用注意事项,如变量引用、函数引用、关联参数引用等
- 优化建议:结合真实使用过程,从用户角度出发,提出的7条优化建议
- 优缺点总结:优点、缺点、评分(从不同角度评测打分)
【简介篇】
以下项目概述及功能介绍内容来自官网及GitHub项目介绍
一、项目概述
流马是一款低代码自动化测试平台,旨在采用最简单的架构统一支持API/WebUI/AppUI的自动化测试。平台采用低代码设计模式,将传统测试脚本以配置化实现,从而让代码能力稍弱的用户快速上手自动化测试。同时平台也支持通过简单的代码编写实现自定义组件,使用户可以灵活实现自己的需求。
项目分为平台端和引擎端,采用分布式执行设计,可以将测试执行的节点(即引擎)注册在任意环境的任意一台机器上,从而突破资源及网络限制。同时,通过将引擎启动在本地PC上,方便用户快速调试测试用例,实时查看执行过程,带来传统脚本编写一致的便捷。
官网:http://www.liumatest.cn/
代码地址:https://github.com/Chras-fu/Liuma-platform
部署文档:https://docs.qq.com/doc/p/c989fa8bf467eca1a1e0fa59b32ceab017407168
使用手册:https://docs.qq.com/doc/p/1e36932d41b40df896c1627a004068df9a28fc3f
平台技术栈:前端VUE+ElementUI,后台Java+SpringBoot,测试引擎Python。
二、功能介绍
1.API测试
- 支持单接口测试和链路测试。
- 支持接口统一管理,支持swagger导入。
- 支持一键生成字段校验的接口健壮性用例。
- 支持全局变量、关联、断言、内置函数、自定义函数。
- 支持前后置脚本、失败继续、超时时间、等待/条件/循环等逻辑控制器。
- 支持环境与用例解耦,多种方式匹配域名,让一套用例可以在多个环境上执行。
2.WebUI测试
- 支持关键字驱动,零代码编写用例。
- 支持UI元素统一管理,Excel模板批量导入。
- 支持自定义关键字,封装公共的操作步骤,提升用例可读性。
- 支持本地引擎执行,实时查看执行过程。
- 支持与API用例在同一用例集合顺序执行。
3.AppUI测试(1.1版本上线)
- 支持WebUI同等用例编写和执行能力
- 支持安卓和苹果系统
- 支持持真机管理、投屏和在线操作
- 支持控件元素在线获取,一键保存元素
- 支持实时查看执行过程
【部署篇】
一、部署说明
1.部署说明
官方部署文档地址:https://docs.qq.com/doc/p/c989fa8bf467eca1a1e0fa59b32ceab017407168,共提供了两种部署方式,一种是容器部署,一种是常规部署。容器部署的好处是简单、快捷,常规部署方式的好处是相对于容器来说、出现问题容易排查,缺点是步骤较为繁琐。两种方式各有优劣,根据自己的喜好*选择即可。本文采用的是常规部署方式。
2.部署规划
机器/系统 |
部署环境 |
说明 |
192.168.1.123,CentOS7 |
JDK8 MySQL8 Nginx |
CentOS7内网服务器:
|
192.168.1.131,Windows10 |
Git JDK8 Maven IDEA编辑器 NodeJS |
个人Windows10办公电脑:
|
192.168.1.188,Windows7 |
Python3 Selenium Chrome ChromeDriver |
同一内网下的其他Windows主机:
|
关于执行引擎机,也可以继续使用个人办公电脑作为执行引擎机,考虑到个人电脑经常会关机重启,就需要来回启动执行引擎,比较麻烦,所以我就选了一台本地Windows主机。当然也可以部署在Linux系统上,不过对于UI自动化测试而言,没有可视化的界面展示,调试起来相对麻烦一些。
二、依赖环境部署
1.安装Java1.8
CentOS服务器和个人Windows电脑分别需要安装JDK。CentOS下,推荐脚本部署方式:
安装脚本下载:https://share.weiyun.com/6JMLvSyK
JDK包下载地址:https://share.weiyun.com/mKDxXd1x
2.安装mysql
1)安装mysql
CentOS下安装,本次通过docker进行快速安装,如服务器或其他内网机器已安装mysql,直连即可,可以忽略此步。注意要使用8.0+版本的mysql,我用的是5.7.33版本,启动时候就会报错不支持。
2)登录mysql
进入mysql容器
连接mysql
2)创建数据库
进入mysql命令行执行:
3.安装nginx
CentOS下安装,推荐脚本部署方式
nginx安装脚本下载地址:https://share.weiyun.com/HLuVRTO2
nginx安装包下载地址:https://share.weiyun.com/uhffdijl
将其下载下来,上传到服务器,执行以下命令安装:
4.安装git
Windows下安装,用于拉取项目代码,下载后双击、按照提示一步步安装。
5.安装node.js
Windows下安装,用于安装前端依赖、打包编译。
下载地址:https://share.weiyun.com/2PpWyXkz,下载下来后双击安装即可。
更换淘宝镜像源
1.临时更换
2.永久更换
3.通过cnpm使用
6.安装python3
CentOS或Windows下安装均可,执行机选用哪个系统就安装在哪个系统下。如果是Linux系统,可以参考之前的文章《Linux下一键安装Python3&更改镜像源&虚拟环境管理技巧》,如果是Windows系统,则在Windows系统下安装python3.
三、代码打包
1.克隆项目代码
平台代码目录:
- LiuMa-backend:后台代码
- LiuMa-frontent:前端代码
2.打包前端代码
进入前端文件目录,安装相关依赖并执行构建
出现"Build complete."提示代表构建成功:
构建成功后,目录下会生成dist文件目录,可以将其打包成.zip格式并上传至服务器,然后再解压
3.打包后端代码
1)安装依赖包
用IDEA打开liuma-platform/LiuMa-backend,使用maven安装依赖
2)修改配置
① 数据库配置
文件位置:liuma-platform/LiuMa-backend/src/main/resources/application.properties,配置如下所示:
- username:数据库用户名;
- password:数据库密码;
- url:连接数据库的URL地址;
注意事项:
- 项目部署的服务器与数据库处于同一主机时可使用127.0.0.1,如不在同一主机下,需改为该主机的IP地址;
- 3307为前面docker部署mysql时映射的端口号,按照你自己的数据库端口号配置即可;
② 邮件配置
文件位置:liuma-platform/LiuMa-backend/src/main/resources/application.properties,配置如下所示:
③ 七牛云配置
文件位置:liuma-platform/LiuMa-backend/src/main/resources/application.properties,配置如下所示:
3)maven打包
提示“BUILD SUCCESS”即表示打包成功,目录下会多出一个LiuMa-1.0.3.jar的jar包(我目前拉的最新代码,打包出来的是1.0.3,还有个LiuMa-1.0.0.jar包是两个月前打包的)
四、项目部署
1.平台部署
1)上传打包后的前端文件
将前端打包后的文件夹dist上传到:nginx安装目录/usr/local/nginx/html/下
2)上传打包后的后端文件
可以在/home目录下新建一个文件夹liuma,用于存放前面打包的jar包文件:LiuMa-1.0.3.jar,执行命令,后台启动服务:
启动后,可以查看logs.log日志文件,看看是否启动成功,以及是否成功连接到数据库,连接成功后自动创建相关数据表:
3)配置Nginx
① 新建nginx_liuma.conf
在nginx的/usr/local/nginx/conf目录下新建nginx_liuma.conf,nginx用于配置server的代理转发,详细配置如下:
② 测试配置
测试过程中可能会出现失败提示"nginx: [emerg] open() "/usr/local/nginx/html/wwwlogs/access.log" failed (2: No such file or directory)",原因是html目录下没有wwwlogs/access.log这个文件路径,直接新建一个wwwlogs目录和access.log文件即可。
③ 指定配置文件启动nginx
4)验证部署情况
访问前端:http://192.168.1.122:8888/,管理员账号:LMadmin,密码:Liuma@123456
登录后的页面如下所示:
5)问题排查
因为流马是前后端分离项目,所以前端能访问并不代表后端也是正常的。如果登录遇到502,则是后台服务器没启起来,多半是数据库的问题,可以通过以下方式排查:
- 数据库版本,建议用8.x版本,5.7版本不支持
- 查看后端配置文件application.properties中数据库配置是否正确
- 可以通过前面提到的logs.log日志查看,也可以查看数据库是否自动创建相关数据表
- 检查数据库端口及Nginx反向代理的端口在防火墙中是否放开
另外,如果前端页面访问不了,很可能是防火墙没开放权限,需要在防火墙中放开上述配置文件中配置的8888端口:
如果是前后端服务是部署在云服务器,需要在安全组中放开8888端口。
2.测试引擎部署
测试引擎可以理解为接口测试和UI自动化测试的运行环境。测试引擎可以选择部署在Linux系统,也可以选择使用个人Windows电脑,最好处于同一局域网下。当然如果服务端是部署在云服务上,有公网IP地址,Windows是个人办公电脑也可以,只要引擎电脑能要连上部署后端服务的那台服务器就行。以下是引擎部署过程:
1)上传代码
前面已经通过“git clone https://github.com/Chras-fu/Liuma-engine.git”克隆好了引擎代码,直接上传到对应的服务器即可,比如我选用的是Windows作为引擎,那么直接拷贝到Windows即可。
2)安装依赖
前面依赖环境部署已经安装好了Python3,创建并激活了虚拟环境,下面直接进入项目所在目录liuma-engine,安装依赖即可。
3)下载Chrome驱动
对照引擎机的Chrome浏览器版本,下载对应驱动,存放在/browser目录下
4)添加引擎
① 注册引擎
流马平台环境中心-引擎管理-注册引擎,输入引擎名称,名称任意,自己能识别即可,如:engine-192.168.1.188,确认后,会弹出一个提示框,复制里面的引擎code和引擎秘钥,后面会用到。
② 配置引擎服务器
编辑liuma-engine/config目录下的配置文件config.ini,进行配置,几个重要配置如下:
- url:后台服务所在的URL;
- engine-code:前面注册引擎成功后,提示框中的引擎code;
- engine-secret:前面注册引擎成功后,提示框中的引擎秘钥;
- options:如果引擎机是Linux系统,则改为headless,即无头模式,如果是Windows则保持默认的normal;
- path:如果引擎机是Linux系统,则改为chromedriver,如果是Windows则保持默认的chromedriver.exe;
- token:后面注册成功后会自动生成,可以不用管;
5)启动引擎
6)验证引擎是否添加成功
引擎启动成功后,即可在流马平台环境中心-引擎管理中查看引擎在线情况。一台服务器可以启动多个引擎,一般默认有四个系统引擎,启动后互不影响。
【使用篇】
一、接口测试
1.前置准备
在开始创建接口测试之前,我们需要先做一些最基础的准备工作,例如:注册一个项目,添加或注册一个账号,将新注册的账号添加到项目中。先看一下官方文档对项目、角色、用户的关系介绍:
注册账号
登录页面注册新账号
注册完成后,登录管理员账号,在【系统管理-用户管理】中能看到注册的用户:
创建项目
创建项目时,可以选择新注册的账号作为管理员,后续此账号登录时即可看到此项目。
2.创建接口
这个平台的最大功能是自动化测试,而我们本次的目的就是体验这个平台的自动化相关的功能好不好用,所以重点会从接口自动化测试及UI自动化测试着手。至于其他相关功能,官方使用手册的内容已经写得非常详细,这里就不做过多介绍。
接口测试需要先创建接口,在创建接口前需要先创建各个接口的执行环境,也就是域名或URL:
新增环境
① 新增域名标识
在新增环境前,需要先新增域名标识,否则在新增环境的时候无“域名标识”内容可供选择
右上角配置中心-域名标识-新增标识,填入标识名称和标识描述,确认。
② 新增环境
添加好域名标识,就可以新增环境了,添加环境的目的主要是为了后面运行测试用例的时候是基于哪套环境,比如同一个项目,可能会有开发环境、测试环境、预发环境等等:
环境中心-环境管理-新增环境,输入环境名称、环境描述,确认。
③ 新增域名
在刚新增的环境下新增域名,匹配类型选择“域名标识”,匹配标识选择第一步新建的域名标识的名称,域名填写接口请求的URL地址。同Metersphere的环境管理类似,此处新建环境后,后面发起的接口测试请求,就是基于这个环境的URL发起。
新增并填写接口信息
① 创建模块
既然是接口测试,就需要先创建接口,在新增接口前需要先创建各个模块,用于分类管理各个模块下的接口
② 新增接口
新增接口可以选择手动新增和导入两种方式,导入的方式支持文件导入、postman、swagger导入,此处我选择的是手动新增,以登录接口为例:
基础信息部分就是接口地址、描述、名称等信息,各个字段简洁明了,不再赘述;请求参数部分主要涉及到请求头、接口的请求体等。为了满足不同用户的登录需求,我的接口请求参数是采用引用变量的形式来传参。提到变量就不得不提到下面的公共参数。
新增、引用公共参数
① 流马与Metersphere的公共参数的设计上的区别
新增公共参数的目的主要是为了后面在接口中引用,类似于全局变量。Metersphere和流马都是基于项目进行管理其下的环境、变量,最顶层是项目。Metersphere的公共参数是放在环境中进行管理,它是一个环境下挂多个变量的概念,而流马中环境则是和变量进行分开,一个项目可以新增多个环境,一个项目可以新增多个公共参数,环境和公共参数之间互不干扰。
公共组件-公共参数-自定义参数-新增自定义参数,填入参数名称、类型、参数值等。注意:同一项目下变量名称不可重复。例如,新增一个登录用户名的公共参数:
② 流马公共参数引用
Metersphere对于公共参数的引用与Jmeter一致,都是采用${name}的形式,而在流马中,则是通过{{$username}}形式进行引用,与postman类似,但比postman多了个$符,postman是{{username}}。请求头和请求体中都可以通过此种方式引用公共参数,但是要注意参数的类型,请求头中一般都是string类型的参数。
内置函数
与Jmeter类似,流马中内置了函数助手,提供很多函数可供选择
比如我的某个接口传参中需要一些指定长度的随机数字,那么则可以使用random_number函数,引用方式见下图标:
添加、引用自定义函数
某些情况下,内置函数可能无法满足生成参数的需求,这是则可以创建一些自定义函数。按照官网文档的介绍,平台支持Python Faker库的方法(毕竟执行引擎就是Python),那么我们就可以创建一个Python方法来自定义生成一些参数。不过有一点需要注意,函数的返回值要使用sys_return(value)来返回。
① 创建自定义函数
例如我想生成随机手机号,则可以通过如下方式常见:公共组件-函数管理-新增函数,内容如下:
可以看出,语法其实就是Python语法,只不过最后的返回值使用了sys_return代替。
② 引用自定义函数
添加完自定义函数,就可以在接口传参中引用,方式为:{{@function()}}
其实上述三个参数:姓名、手机号、身份证号我都是通过自定义函数来生成的。最后发起请求时,通过日志可以看到生成的参数值:
特别注意
有个很重要的细节需要注意,也是我在使用过程中遇到的一些小坑:
接口传参中引用string类型的公共参数时需要加引号
定义参数时,如果是string类型变量:
- 参数值没加引号、在传参时不会自动带上引号
- 也不能在定义变量时给参数值加上引号
- 只能在接口引用变量时,外层带上双引号
举个例子可能会直白一点:
假如我们登录接口需要传入密码参数,而我们提前在公共参数中定义了这个变量password,值为e10adc3949ba59abbe56e057f20f883e,是一个string类型,如下图所示:
假如值没加双引号的话,传参的时候不会自动带上引号(通过执行打印结果可以看出),哪怕定义时选择的是string类型,被测接口的服务端也会认为它不是一个string类型
如果我们在公共参数中手动给它加上双引号,此时执行引擎Python那边就会报错JSONDecodeError:
解决办法是在定义公共参数时不加引号,在接口中引用参数时,加上引号
此时就会识别成合法的string类型值:
3.测试用例
创建用例并添加接口
添加模块,新增用例页面:
一条用例是由一个or多个接口组合而成,从而形成不同场景的业务流。前面接口管理中新建接口后,就可以在用例中选择添加该接口,一次可选择单个或多个。
添加断言
断言的类型有多种,比如某个添加用户的接口,添加成功后返回值是{"a":"200","d":"30200"},其中a是固定的,即接口响应码,d的值用户ID,是不固定的,那么这里就可以通过jsonpath提取器先提取d节点的值,用“整数”来进行断言:
导入配置信息
如果某些接口用到了自定义的函数(内置函数不需要导入)、公共参数、公共header等,则需要在用例中一一将它们选择导入,否则接口中引用不会生效。很多时候,用例执行不同都是因为没有导入这些元素导致:
关联参数
通常,一条用例可能会包含多个接口,而接口参数之间可能会相互关联,比如B接口的入参用到A接口的出参,就需要先提取A接口的出参,再在B接口中进行引用。
① 提取返回值
与Jmeter和Metersphere一样,提取返回值支持正则表达式和jsonpath提取两种方式,与与Jmeter和Metersphere不同的是,流马提取返回值时,表达式不需要加$符号:
② 引用返回值
与前面引用公共参数不同,引用返回值的{{}}内不需要加$符号,直接填写变量名即可:
特别注意
接口管理与用例管理中的接口信息不同步
若用例中添加了接口A,则:
- 编辑接口A详情后,编辑后的内容不会同步到接口管理的接口A中;
- 在接口管理中编辑接口A,也不会同步到用例中的接口A;
比如我们创建了一条用例,其中添加了接口A,并在用例中给接口A添加了一个请求头参数,此时,到接口管理中查看接口A则不会同步这个请求头参数;而在接口管理中添加的请求头参数也不会同步到用例中,相当于用例管理和接口管理做了隔离。此时就需要两边各修改一次接口A,或是在接口管理中修改后再重新添加到用例中。
说实话我觉得这个设计很不好用,因为在现实使用中,会有很多测试用例用到同一个接口。举个例子,如果我只在测试用例A中添加或更改了某个接口的请求头,那么其他测试用例B、C、D中则需要一一更改。
起初我以为是bug,后来特地问了作者,就是这么设计的,也不是不能改,只是处理起来会很麻烦,而且很多其他平台也都是这么设计的,后期会慢慢优化。
4.业务流程测试实践
此处以在测试中常见的某个业务流程场景为例,来串联前面提到的公共参数、自定义函数、关联参数等等,流程如下:用户登录->添加一个商品->获取商品详情->删除商品,从添加到删除,这样既形成了一个小的业务流程的闭环,也避免我们后期到数据库中手动删除数据,这也是现在接口流程测试中一种较为常见的做法。
完善用例信息
一个完善的业务流程的测试用例,通常需要做以下工作:
- 填写基础信息;
- 导入配置信息:自定义函数、公共参数、共用header;
- 添加接口并调整好接口顺序;
- 为每个接口添加合适的断言;
- 配置接口之间的关联取值;
执行用例
分别看下各个接口的执行结果,并做一些简单的解读,看其是否符合最初的流程设计:
① 登录接口
账号登录成功,并获取到返回值,返回账号的user id及token信息。
② 新增商品
新增商品成功,返回d节点为商品的ID。
接口断言返回值的d节点为整数,断言成功。关联参数会提取d节点的值,作为后面接口的入参。
③ 获取商品详情
上一个接口提取的商品ID,已经传入请求体,并获取到了商品详情。
接口断言返回值的d节点的aa节点与商品ID变量数字相等,断言成功。
④ 删除商品
此处接口传参使用的也是新增商品返回的商品ID作为入参,删除成功d节点返回值为1
接口断言返回值的d节点数字恒等于1,断言成功
二、web自动化测试
web自动化测试我研究得确实不多,我想它的设计理念应该是和接口测试类似的,比如:
- 封装了selenium webdriver的一些方法,如浏览器窗口最大化、最小化等作为内置方法;
- 元素管理可以类比成接口管理,里面是一个个的页面元素;
- 用例可以类比成接口用例,接口用例由一个个接口组合而成,而UI用例由一个个元素及元素操作组合而成。
1.元素管理
添加元素
以百度首页为例,添加百度首页的一些元素,如:搜索框、百度一下按钮。定位方式支持selenium的八大元素定位方式
表达式直接填写元素属性值,比如ID定位,搜索框的ID属性值是kw
如果选择name定位,表达式就填wd
元素列表
元素列表管理所有元素,建议不同页面可以通过不同模块来进行管理,这也符合UI自动化PO设计模式中一个很重要的设计原则:同一个页面,只管理本页面下的页面元素对象。
2.测试用例
新增操作
新增操作基本上涵盖了UI自动化测试中所有可能用到的操作,比如:浏览器最大化、断言、IF...ELSE、切换frame等
添加元素
这里有个小点需要特别注意,按照我原本编写测试脚本的固化思维是:先声明元素对象>>再附加元素动作,比如点击、双击、滑动、长按等,所以也想当然地先来添加元素,结果摸索了半天没找到入口。但其实是先选择操作的动作,如输入、单击>>再选择要操作的事先录入好的元素:
当然在操作设置页面、勾选元素后面的按钮后,也可以新建页面元素对象:
3.测试场景实践
设计测试场景
此处以百度搜索作为一个小小的测试场景,来串联前面提到的元素定位、添加元素等,场景流程如下:
打开浏览器>>打开百度首页>>最大化浏览器窗口>>输入框输入“流马”>>提交搜索>>断言页面标题包含“流马”>>等待三秒>>关闭浏览器
测试效果
三、测试计划
测试计划作用是确定测试执行的全部用例,以测试集合为维度管理。此外测试计划支持定时任务和周期执行。同时测试计划按照版本管理,也支持集成到研发流水线。
1.测试集合
编辑集合
测试集合可以看作是多个测试用例的集合,每条用例相互独立、互不影响。填写集合相关信息,注意版本要在配置中心提前新建好。
添加测试用例
添加用例,可以选择到之前创建的各个测试用例,API用例和UI用例可以同时选择,按照顺序混合执行。
创建完的集合,可以手动执行,也可以创建测试计划定期或周期性执行
测试计划
手动执行测试集合,生成测试报告
2.测试计划
编辑计划
填写名称、选择版本、执行引擎、设置执行时间
执行频率有多种方式可供选择,类似于Jenkins或是Linux crontab的定时任务:
新增集合
测试计划需要选择测试集合,前面新建的集合在这里会选择到,一个测试计划可以包含多个测试集合
【总结篇】
一、使用总结
1.常见注意事项
- 引用公共参数:{{$name}},带上$符
- jsonpath提取前一个接口返回值,表达式不同于Jmeter,没有最外层的 $.
- 引用前一个接口提取的参数:{{name}},没有$符
- 引用内置函数:{{@function_name()}},注意有@符,括号内为函数的参数
- 自定义参数:可以使用Python语法,但返回值要使用sys_return(value)来返回
- 接口header和用例断言中都可以引用公共参数和提取的变量,但是提取的变量值传参时如果类型不同、需要提前转换类型
- 用例中,如果用到了一些自定义的公共参数或自定义函数,需要将其一一勾选导入,用例才能生效
- UI用例,先选择要执行的动作,才能选择到要执行的元素
- 对于流马而言,最大的是项目,一个项目可以包含多个测试计划,一个测试计划可以包含多个测试集合,一个测试集合可以包含多条测试用例,一条测试用例可以包含多个接口或UI元素对象
2.优化建议
在使用中我也遇到了一些麻烦,有的是自己摸索解决的,有的是靠用户手册解决,有的则是在用户交流群中咨询解决的,我想肯定有人和我遇到同样的问题或是使用感受。以下是我总结出的一些优化建议,仅代表个人:
① 接口复用
目前用例管理中支持用例复用,也就是复制的功能,但接口管理不支持,如果当前有一些接口,内容都比较相似、仅仅修改接口地址和个别参数就可以使用,那么增加这个功能就显得很有必要。
② 关联参数增加自动转换功能
这个也是我在使用过程中遇到的问题,比如我从A接口提取了返回值user_id需要传到下一个B接口的请求头中,提取的user_id值是一个int类型,而传到B接口的请求头中需要string类型:
① 如果通过{{user_id}}引用提取的变量值的话,B接口请求时就会报类型错误;
② 如果通过'{{user_id}}'引用提取的变量值的话,B接口请求时就会报错502;
目前作者给的解决方案是在前置脚本里处理,或是写个自定义转换的函数
如果能在编辑用例---添加请求头的时候直接选择类型就好了,类似于编辑接口管理下这样:
③ 标题超链接跳转
目前标题只有一级“首页”支持跳转,二级、三级不支持超链接,如果当前页面处于一个很深的层级,那么标题跳转显然会比浏览器的后退、前进更加*灵活。
④ 固定侧边栏
目前刷新页面后,侧边栏会自动收缩,建议可以参考Metersphere以及微信聊天窗口等类似的做法,加一个固定按钮,可以固定/取消固定侧边栏。
⑤ 设置默认执行引擎
目前每次执行都需要选择一次执行引擎,次数多了操作起来就会比较麻烦。建议可以设置默认执行引擎或修改执行引擎列表顺序。
⑥ 自动填充模块分类
点击模块名称会查询当前模块下的接口,而此时处于某个模块下、进入新增接口页面时,仍需选择一次所属模块,建议可以增加自动填充模块分类功能。
⑦ 弹框关闭二次确认
假如我正在编辑某个弹框,且编辑了很多内容,此时如果一不小心鼠标点到了其他空白处,弹框就是自动消失,原本编辑的字段也需要再重新编辑。如果点击其他空白处,可以弹出一个二次确认弹框,会避免很多误操作。
二、优缺点总结
以上这些都是我亲自使用过程中的总结体会。所谓“实践是检验真理的唯一标准”,一个工具/平台好不好用,不是靠听别人说的,而是要自己试了才知道。
1.优点
① 设计巧妙
正如前面项目概述提到的“项目分为平台端和引擎端,采用分布式执行设计,可以将测试执行的节点(即引擎)注册在任意环境的任意一台机器上,从而突破资源及网络限制。同时,通过将引擎启动在本地PC上,方便用户快速调试测试用例,实时查看执行过程,带来传统脚本编写一致的便捷。”
也就是说执行引擎和前后台服务是独立开来的,执行引擎既可以部署在Linux,也可以部署在Windows,也可以使用个人办公电脑,从而快速调试。
另外一个巧妙的地方我觉得没有那么多套路,基本上上手一遍就能摸索出规律,例如前面提到的:一条用例包含多个接口,相应的就能想到计划包含集合、集合包含用例、用例包含接口或元素对象。
② 功能强大
支持接口测试、WEB测试、APP测试,支持定时任务、周期性执行、并发执行
③ 使用灵活
平台技术栈:前端VUE+ElementUI,后台Java+SpringBoot,测试引擎Python,支持Python自定义函数,相对了解Python编码的测试工程师来说较为友好,使用起来会更灵活。
2.缺点
① 部分细节功能不完善
部分细节功能不完善、或者说不好用。比如前面提到的优化建议,以及一些注意事项,都是我在使用过程中遇到并总结的。
② 上手成本略高
流马的定位是低代码测试平台,旨在帮助不懂代码的测试工程师也可以*地开展多种类型的自动化测试。我自认为稍微懂一点点代码,也见识过一些开源平台,但在使用过程中,确实也摸索了几天。注意,这里的上手指的是开展公司的实际测试业务,而不是请求一个百度接口或是打开一个百度页面这种demo这么简单,要能把公司的业务迁移到平台并成功运行起来,这意味着肯定要花费一定的时间学习和摸索、以及解决使用过程中遇到的问题。
③ 用户手册不够详细
用户手册的内容相较于Metersphere确实不够详细,很多都是一个简短的描述,没有具体用法示例,这也就造成了遇到一些问题时可参考的内容较少。不过这也能理解,毕竟MS背后是商业化的公司,有充足的人力可以维护和更新文档,而流马据我所知只有作者一人维护。
3.总结评分
由于篇幅、个人时间以及能力限制,只罗列了上述有限的功能和使用细节,更多精彩功能还需大家亲自部署体验。按照惯例,简单对流马做个评分总结,评分过程中可能稍带有主观色彩,毕竟我也是用户,但会尽量本着客观公众的原则。评测还是基于之前预告篇中的维度。
特别声明:由于每个人的关注点不一样,所以评判标准可能也会有所偏差。
测评维度 |
详细说明 |
评分(星级越高,得分越高) |
环境搭建 |
1.依赖环境:较多,支持容器化部署,传统部署相对较繁琐些 2.搭建难度(难度越大、星级越低):对新手来说难度会较大,因为涉及的工具和服务比较多 |
☆☆☆ |
用例管理 |
1.是否支持导入用例:支持多种平台及格式导入 2.用例执行顺序编排:支持,可以拖动 |
☆☆☆☆☆ |
接口测试 |
1.单接口测试:支持,不过没看到导入CSV入口,参数化和数据驱动支持情况不详 2.接口流程测试:支持,多种参数提取方式,支持测试集合、测试计划,可以定期或周期性执行 3.自动生成测试报告:支持,简洁 |
☆☆☆☆☆ |
UI自动化测试 |
1.APP:支持 2.Web:支持 |
☆☆☆☆☆ |
性能测试 |
不支持 |
无 |
扩展功能 |
1.是否支持二开:支持 2.是否支持定时任务:支持 3.是否支持接入CICD:支持 4.是否支持测试结果度量:支持 5.用户权限配置:支持,不同用户不同权限 6.测试管理:不支持,平台定位不是如此 7.缺陷跟踪:不支持,平台定位不是如此 |
☆☆☆☆☆ |
其他 |
1.文档支持(部署教程、操作手册):不够详细 2.代码更新维护频率:长期维护 3.社区活跃度:中等 4.易用性:上手成本略高 5.稳定性:目前暂未发现bug |
☆☆☆☆ |
最后总结:流马功能强大,支持多种类型的自动化测试,可以满足各种自动化测试需求;平台定位低代码、易使用,能够帮助没有代码基础的测试工程师也能快速开展自动化测试,不过平台使用过程需要一定的学习和摸索成本,部分细节功能还需优化完善。作为个人开发者开发的流马平台,能做到现在这样的效果,确实非常厉害,值得点赞和学习!任何一个开源项目,既需要接受用户的批评、质疑、意见建议,也需要用户的包容、鼓励和支持,有了一定的用户基础,大家群策群力,项目才会越来越好,带来更多价值!
更多干货,欢迎关注《测试开发实战》!