背景

在测试的时候,经常会有模拟用户登录,拿到用户 token 后再去请求接口的场景。

这个模拟用户登录就会分为两种,一种是单用户,另一种是多用户

日常自动化测试的时候可能一个用户对应 n 个用例就可以满足大多数场景;

如果是在压力测试的场景下面,可能就会略显单调,也无法满足一些真实业务场景。

对于单用户的情况下,和我们常规的多接口有依赖的测试其实没什么太大的差别。

所以这里主要讲的是多用户产生多个 token 的情况。

下面来看一个具体的例子来了解一下。

场景接口

在这里的话,只有两个接口,一个是登录拿 token,一个是有 token 才能请求的。

下面是各接口定义

登录接口

请求:


POST http://localhost:8532/MultiToken/Login

Content-Type: application/json


{

"UserName":"catcherwong-1",

"Password":"123"

}

响应:

{"code":0,"msg":"ok","data":"catcherwong-1-token"}
业务接口

请求:

  1. GET http://localhost:8532//MultiToken/do?account=xxx

  2. Content-Type: application/json

  3. token: catcherwong-1-token

响应:

{"code":0,"msg":"ok","data":"catcherwong-1-token"}

登录接口处理

登录接口属于预请求,所以我们一般会选择把它放在 setUp 线程组里面。

我们需要准备一个 csv 文件,里面用来存放需要登录的用户名和密码。

接下来就是把这个 csv 配置好,定义了两个变量 account 和 pwd

 然后是把登录的 HTTP 请求配置好:

 由于后面要用到 token,所以要先把 token 提取出来,这里用的是 JSON Extractor。

到这里就要开始注意了!!!!

由于我们会有多个用户进行登录,但是这一个提取操作每次都会把 token 赋值到 access_token 这个变量上面,是覆盖的操作。

换句话就是说,每登录一个用户,这个 access_token 的值就会是最后一个登录的用户的 token,。

换个思路,每次它会覆盖,那么把这些 token 存到一个地方,然后业务接口去这个地方取就可以了。

如果没有用户登录这一步,给的直接是 token,那么我们也是直接把这个 token 放到 csv 文件里面,然后让 jmeter 去循环使用里面的 token。

那么要做的东西其实就很确定了,就是在提取到 token 后,把这个 token 写到一个 csv 文件里面。

要想做到这一步,需要在登录接口后面加一个后置的处理。

 


String p1 = System.getProperty("user.dir");

String p2 = System.getProperty("file.separator");

String p3 = "user_token.csv";

String path = p1 + p2 + p3;


FileWriter fileWriter = new FileWriter(new File(path), true);

BufferedWriter writer = new BufferedWriter(fileWriter);

writer.append(vars.get("accout")+","+vars.get("access_token")+"\n");

writer.close();

fileWriter.close();

这段代码的意思是,把用户名和提取到的 access_token 写进到 csv 文件里面,这个文件在的位置是 jmeter 的目录。

这里是对文件路径做了处理,可以适配所有操作系统的。不会出现说指定了一个 windows 系统的路径,然后放到 linux 系统下面就跑不了了。

还有最重要的一个是,要修改 setUp 线程组的属性,把循环次数改成 3 。因为前面的 csv 文件里面有 3 个用户,这样它才会触发三次登录。

业务接口处理

业务接口要放到正常的线程组里面,独立于 setUp 线程组。

前面提到,登录后会有一个 csv 文件,所以这里第一个要做的是把 csv 配置好。

 

上面的截图用的是 ${__P(user.dir,)}${__P(file.separator,)}user_token.csv 这个文件路径,这个在本地环境的 Jmeter 是可以通过的,不过在一些云服务上面是不行的,如阿里云 PTS 。

这里可以忽略前面的路径,直接填写 user_token.csv 即可,填这两个,得到的文件路径是一样的,一个是绝对路径一个是相对路径。

然后就是配置 HTTP 请求了

 

PS:不要忘记把请求头也配置了,这里就不截图了。

这里试跑两次,可以发现业务请求的接口,它的 token 请求头每次都是不一样的,在交替变化,这个是符合预期的。

但是会发现生成 csv 文件里面的数据会重复,没有自动清理掉上一次产生的数据。如果上一次产生的 token 过期了,那么用了这些过期的 token === 凉凉。

 所以这里还有必要加一步 tearDown 线程组,每次跑完脚本把这个文件删除掉。


String p1 = System.getProperty("user.dir");

String p2 = System.getProperty("file.separator");

String p3 = "user_token.csv";

String path = p1 + p2 + p3;


log.info("准备删除文件:" + path);


File file = new File(path);

if (!file.exists()) {

log.info("删除文件失败:" + path + "不存在!");

} else {

file.delete();

}

这个时候跑脚本就基本没什么问题了。

 

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部