【使用篇】

一、接口测试

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.常见注意事项

1. 引用公共参数：{{$name}}，带上$符
2. jsonpath提取前一个接口返回值，表达式不同于Jmeter，没有最外层的 $.
3. 引用前一个接口提取的参数：{{name}}，没有$符
4. 引用内置函数：{{@function_name()}}，注意有@符，括号内为函数的参数
5. 自定义参数：可以使用Python语法，但返回值要使用sys_return(value)来返回
6. 接口header和用例断言中都可以引用公共参数和提取的变量，但是提取的变量值传参时如果类型不同、需要提前转换类型
7. 用例中，如果用到了一些自定义的公共参数或自定义函数，需要将其一一勾选导入，用例才能生效
8. UI用例，先选择要执行的动作，才能选择到要执行的元素
9. 对于流马而言，最大的是项目，一个项目可以包含多个测试计划，一个测试计划可以包含多个测试集合，一个测试集合可以包含多条测试用例，一条测试用例可以包含多个接口或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.总结评分

由于篇幅、个人时间以及能力限制，只罗列了上述有限的功能和使用细节，更多精彩功能还需大家亲自部署体验。按照惯例，简单对流马做个评分总结，评分过程中可能稍带有主观色彩，毕竟我也是用户，但会尽量本着客观公众的原则。评测还是基于之前预告篇中的维度。

特别声明：由于每个人的关注点不一样，所以评判标准可能也会有所偏差。

最后总结：流马功能强大，支持多种类型的自动化测试，可以满足各种自动化测试需求；平台定位低代码、易使用，能够帮助没有代码基础的测试工程师也能快速开展自动化测试，不过平台使用过程需要一定的学习和摸索成本，部分细节功能还需优化完善。作为个人开发者开发的流马平台，能做到现在这样的效果，确实非常厉害，值得点赞和学习！任何一个开源项目，既需要接受用户的批评、质疑、意见建议，也需要用户的包容、鼓励和支持，有了一定的用户基础，大家群策群力，项目才会越来越好，带来更多价值！