使用分享｜使用MeterSphere愉快地做一个带有登录场景的接口测试

以下文章来源于CSDN博客分享，作者Limonsama。

产品介绍

MeterSphere是一站式开源持续测试平台，涵盖测试跟踪、接口测试、性能测试、团队协作等功能，兼容JMeter等开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量软件的交付。

快速安装

1. 硬件要求：

2. 一键安装：

命令如下：

[root@docker ~]# mkdir -p /opt/install/metersphere && cd /opt/install /metersphere[root@metersphere ~]# curl -sSL https://github.com/metersphere/metersphere/releases/latest/download/quick_start.sh | sh

注：安装脚本默认使用/opt/metersphere目录作为安装目录，MeterSphere的配置文件、数据及日志等均存放在该安装目录。

安装程序的大致流程如下：前往GitHub下载安装脚本 → 执行安装脚本（下载容器编排文件） → 安装Docker，安装Docker-Compose（如果已安装则跳过） → 拉取产品各模块镜像 → 启动容器。

3. 登录并使用：

安装成功后，通过浏览器（推荐Chrome）访问如下页面登录 MeterSphere：

注：若出现访问不了的情况，请关闭系统防火墙，参考命令如下：systemctl stop firewalld & systemctl disable firewalld。

4. 系统配置：

登录系统后，选择系统设置——系统——系统参数设置——基本配置。

将当前站点URL配置为您所部署的服务器地址加端口，如下图：

至此，MeterSphere环境准备完毕，还是挺简单的吧，下面就开始进入主题。

背景

在实际项目中，我们软件产品或业务系统中的大部分接口都是需要预先登录用户，接口才会根据登录用户的信息返回对应的信息。

比如某管理平台中查询菜单的接口，会根据当前用户的权限来展示不同的菜单，可能管理员登录时可以看到10个菜单，而普通用户登录只能看到2个菜单。这时查询菜单列表的接口就需要有用户登录的信息，才可以正常返回。碰到这样的场景，我们在做接口测试时，应该如何操作呢？

思路与目标

登录其实就相当于我们在写功能测试用例时的“前提条件”，我们的业务接口需要一个前提条件就是“登录”，那我们是不是可以在业务接口前先配置上登录接口，并将这两个接口置于同一个会话环境中就行了？

那我们就来使用MeterSphere的场景自动化功能，完成一次需要登录的接口测试。

操作步骤

本文档所使用的MeterSphere平台为v1.7.3版本。

1. 接口信息准备

接口信息可以获取该软件的接口文档，也可以自行去Chrome浏览器中使用F12查看，以下为示例接口：

1-1. 登录接口：

请求地址：POST /login

请求参数：

返回代码：302。

返回信息：无，但是会重定向至首页地址。

1-2. 获取菜单列表接口

请求地址：POST /PF1210/getMenuAsync

请求参数：

正常返回参数：

异常返回参数：

2. 创建测试项目

打开MeterSphere，首先创建一个项目，依次进入系统设置——项目管理，新建一个测试项目，如下图：

3. 录入接口定义并调试

创建好项目后，依次进入”接口测试“——”接口定义“，在左侧模块树中，建一个模块，暂且就叫“测试模块”，也可以根据实际模块进行创建划分。

发表一下我对“接口定义”的理解：一个系统中有很多的模块，每个模块都有很多的业务接口，接口定义就是让我们将接口的基础信息（地址、请求参数等）和平台中关联信息（属于哪个模块、责任人是谁、描述信息等）维护在一个列表里，我们可以用这一个个的接口去编写它对应的测试用例（CASE），后续也可以根据业务组合这些接口或者用例完成场景的测试。

3-1. 创建第一个接口（登录）

选择创建接口：

根据上面的接口信息完成录入，如下图：

如上图输入好信息后，点击保存。

注意：username和password的值，我这里使用了${}做一个占位符（相当于做了两个变量，也叫参数化），为了应对后续接口测试中，可能会有不同的用户去登录，到时可以使用其他方式（全局变量、场景变量、CSV Data等）传入到这里，而不是直接在接口定义中写死。

进入调试页面，准备调试：

保存后，点击右上角的“测试”按钮，进入接口调试界面：

配置一个运行环境：

点击运行环境的下拉框，选择环境配置：

运行环境：我们在实际项目中同一个应用程序可能有多个环境，譬如开发环境、测试环境、预发布环境、生产环境等等，这些环境只要代码一致，那接口的基础信息就是一样的，平台将接口地址中的HOST与PATH分开，也是为了可以在不同的环境中运行，而不需要去频繁的修改接口定义。

通用配置中的全局变量，就是一种入参的方式，对应接口定义中我们配置的两个变量。

HTTP配置就是环境的域名或者IP端口，数据库配置和TCP配置，本章不做介绍。

执行接口的调试：

这里返回的是302，说明这个接口在成功响应后，会有一个自动跳转的过程，那么我们有没有办法让它的响应内容是跳转后的内容呢？如下：

3-2. 创建第二个接口（获取菜单列表）

参照第一个接口，我们再根据接口信息录入第二个业务接口，如下图：

创建好后，我们一样来调试一下这个接口：

这时我们直接访问这个接口，它返回的是我没有登录，所以要想测试这个接口，是需要前提条件的，那就是登录。

4. 基于场景的接口测试

上述例子中其实就是一个简单的场景——“登录后，获取当前登录用户的菜单列表”，我们可以使用MeterSphere中的接口自动化来实现场景的测试。

如下图，创建一个场景：

配置场景，选择接口列表导入：

选择接口定义中，涉及到该场景的接口并复制：

复制后的界面如下图，可以看到接口已经加入到场景步骤里了：

勾选“共享cookie”，让这两个接口使用同一个cookie：

下面就可以调试一下这个场景啦：

可以看到正确的返回了菜单信息，而不是登录失败了！

5. 先做个小结

到这里，我们完成了一个简单的场景测试。但是！这还不够！为什么？我们前面在列举接口信息的时候发现，接口是有异常情况的。

5-1. 异常情况示例：登录密码不正确

当我们的登录密码不正确时，再执行这个接口测试，看下会是什么效果，首先将密码改成“哈哈”吧：

执行这个场景，结果如下：

问：明明我的接口都报异常了，为何测试结果还是成功呢？

答：在MeterSphere中，对于接口的执行结果只有一种判断，那就是响应代码，当响应代码为2xx，3xx时，MeterSphere就认为它是成功的。

问：我该怎么让测试结果根据返回值来判断失败成功呢？

答：那当然是断言了！

6. 增加断言

断言：

用于检查测试中得到的响应数据等是否符合预期，用以保证测试过程中的数据交互与预期一致。简单来说：就是输出的实际结果与预期结果做一个比较，实际结果由MeterSphere请求得来，而预期结果由我们自己给出（接口文档等）。

再来看看我们业务接口（获取菜单）的正常与异常返回值：

正常：

异常：

知道了正常和异常的返回信息之后，我们就可以根据现象去判断接口响应的正确性了，在使用断言之前，可以先创建一个接口的用例，如下：

点击右侧的case图标：

在弹出小窗体上，点击“+用例”，并输入用例名称 “ 校验菜单列表是否存在“系统管理” ”：

用例准备好后，就可以配置断言了，下面介绍常用的断言的方式。

6-1. JSONPath断言

接着编辑用例，点击如下图中的“+断言规则”：

随后鼠标滚轮往下划，如下编辑这个断言规则：

解释：断言规则断言的对象是接口执行后响应的内容。如本节开始演示的正常返回值的图所示，返回值正好是一串json。正常研发在开发程序时，JSON字符串需要转成json对象，然后调用譬如fastjson这种工具的方法才能获取到json对象中的字段。而MeterSphere这里提供了jsonpath小工具，可以通过写一小串表达式来实现解析json的效果。上图中的表达式【$.[?(@.id==“10”)].text】意为提取响应结果json中id为10的记录的text值，然后我们给他一个预期值，如果预期值与实际值相符，则断言成功。

那我们在接口自动化中新建一个场景测试一下吧：

在场景中引入刚才创建的用例，点左侧的小+号，鼠标往下滑可以看到断言规则：

执行场景，看一下结果，如下图：

可以看到断言成功了，如果我们故意把断言结果写错（比如将“系统管理”改成“哈哈”），再来看一下结果：

这时就会断言失败，也就是接口不符合预期结果。

6-2. 正则表达式断言

参照上面的步骤给我们的登录接口也加一个用例，并且添加断言规则吧！这里不用重新演示一遍怎么加用例了吧，Orz…

好了言归正传：我们这次选择正则表达式断言，我们知道登录接口如果成功的话，会自动跳转到首页（返回值是一大串html文本），我们可以判断返回值中存在<title>标签，就认为登录成功。

匹配<title>标签的正则示例：<title>[\s\S]*?</title>

执行一下该用例，看下结果：

上图中可以看到断言成功了，我们可以关闭跟随重定向来模拟没有返回首页，看一下这个断言是否可以生效：

上图中可以看到，因为这个接口响应值为空，它找不到title了，所以断言失败！

6-3. 自定义脚本断言

咳咳，来来来，我们继续打磨咱们的登录接口！

刚才我们使用正则表达式判断了返回内容是否有title这个标签，但是没有校验title是否正确（万一与预期结果对不上呢，你说是吧），这个用正则应该也能实现，但是我就使用自定义脚本做一个演示吧。

添加一条断言规则，标题就叫“判断标题内容是否正确”，选择脚本：

随后点击编辑按钮，进入到如下图的一个代码编辑器：

图中①：研究了之后发现，第一行原来是一个代码生成小工具，填入一些参数，下面②中会帮你生成示例代码。第二行是脚本名称，只做展示。

图中②：代码窗口，没啥好说的。

图中③：也是一个代码生成器，点击即可生成一小句代码。

我们在脚本窗口②中输入以下代码：

//获取当前请求的响应内容（以字符串形式返回）String responseData = prev.getResponseDataAsString();//titleHtml是我的预期值String titleHtml = "<title>SyncPlant5</title>";
//判断响应的内容是否包含我的预期值if(!responseData.contains(titleHtml)){    msg = "哇，竟然断言失败了，返回的内容没有包含:"+ titleHtml;    //AssertionResult是Jmeter提供的断言对象  AssertionResult.setFailureMessage(msg);  AssertionResult.setFailure(true);}else{    //控制台打印一行内容，断言成功，可以在控制台看到哦    System.out.println("嘿嘿,响应的内容包含了: "+titleHtml);}

以上脚本为BeanShell语法，实际上就是java代码。初学者可能会好奇我是怎么知道 prev.getResponseDataAsString() 可以获取响应内容的吧，实际上MeterSphere底层执行接口测试的工作是交给JMeter做的，只要JMeter支持，它就支持。这时候你又要问了，jMeter有哪些封装好的对象或者方法给我们使用呢？

常用的内置对象有：ctx ( 上下文信息 )、vars ( JMeterVariables，操作JMeter变量，这个变量实际引用了JMeter线程中的局部变量容器)、AssertionResult（断言相关的对象）、 prev（获取前面的sample返回的信息）、log（打印日志，写入信息到jmeter.log文件）

最后我们执行测试用例：

再看一眼控制台，有打印了！

总结

MeterSphere用起来真愉快！今天就到这里，后续还有更多内容！敬请期待！

相关资料：

官方文档：https://metersphere.io/docs/index.html

官网：https://www.fit2cloud.com/metersphere/index.html

开源项目地址：https://github.com/metersphere/metersphere/

————————————————
版权声明：本文为CSDN博主「Limonsama」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：

https://blog.csdn.net/weixin_46356562/article/details/114985466