背景

前面一篇聊了一下 JMeter 的简单使用，这篇聊一下 JMeter 的参数化。

在开始之前先来一个单元测试的例子，感受一下参数化。

上面是一个用 xUnit 写的单元测试，这个单元测试就是一个参数化的例子：

模拟了不同的输入，调用同一个方法，得到了不同的输出。

对某一个场景，要验证不同的输入得到不同的输出是非常有用的。

在 JMeter 里面就可以通过参数化来实现这个效果。

JMeter 的参数化有很多种方法，本文主要是介绍基于 CSV Data Set Config 的参数化。

在这篇文章里面，会通过一个简单的场景来了解 JMeter 参数化的使用，以及自定义 jar 包的使用。

场景

这里用一个大家最熟悉的登录场景做为例子。

登录最重要的就是用户名和密码这两个内容，这里会有两种结果，登录成功和登录失败。

在这个场景下，假设我们的接口定义是这样的

POST http://localhost:8532/run?sign=sssss&appkey=aaaaa
Content-Type: application/json{"userName":"catcherwong","password":"xxxxx"
}

• sign 的值是签名，用来验证参数是否被修改，这里是不校验的，所以随便生成一个随机数就可以了。

• appKey 是定义的另一个参数，这里也不做校验的，也是随机定义即可。

这个接口，会有两种返回

登录失败的， code 会是 1， msg就是错误信息。

{"code":1,"msg":"用户名或密码错误"}

登录成功的， code 会是 0。

{"code":0,"msg":"ok","data":{"token":"626b97f78d794f4da927bc09ae6be245"}}

针对这个场景，简单起见，只考虑 code 的值来判断登录是否成功。

准备数据

场景有了，接口也有了，再下一步就是准备要用的数据了。

这里是用 CSV 文件来做为数据源，所以我们把接口要用到的参数放进去。

准备了20条数据，第一列是用户名，第二列是密码，第三列是appkey，第四列是结果，表明用前面三列数据去调用登录接口，应该成功还是失败。

然后在线程组里面添加一个 CSV 的配置原件。

在里面最主要的配置是 文件路径和变量名。

文件路径没什么好说的，就是 csv 文件所在的具体路径。

可以看到上面的 csv 文件，我们是没有定义头部的，放的直接是数据，所以每一列数据代表什么需要有一个标识。

这里的变量名可以认为就是给准备的每一列数据起个别名，便于后面的使用，示例这里是有4个的，每一个都是用英文逗号隔开。

配置HTTP请求

其中 name, pwd 和 appKey 这三个变量是前面已经定义好了的，所以这里可以直接用 ${xx} 的方式去使用。

sign 这个参数是没有定义的，所以要加一个 BeanShell PreProcessor 来处理一下。

到这里，请求已经配置好了，下面就是要判断登录是不是成功的了。

断言

断言这里是要判断返回的 JSON 结构里面的 code 值是不是和 csv 文件里面定义的一样。

所以这里选择的还是 JSON Assertion 。

要把期望值调整成变量名，这样它才会根据不同的入参判断不同的结果，上图的例子是  ${login_res}

添加结果树，调整线程组的循环次数为20，再运行这个线程组，就可以看到对应的结果了。

可以看到的是，20条数据都跑了一次，所有的用例都是可以过的。

但是这里有一个问题，密码是明文传输的！！！

这个是大忌，绝对不允许的，正常都会加密或哈希之后再传输。所以这里要做一个优化。

也就引入了，自定义 jar 包的使用。

自定义jar包调整

首先我们需要写一些 JAVA 代码来编译成一个 jar 包。

这里老黄是直接写好了，直接用就可以了。

调整一下 BeanShell PreProcessor ，如下图所示：

首先是先引入自定义 jar 包，其次是从 vars 里面拿到明文密码，然后是调用 jar 包里面的 getPwd 的方法对密码进行处理，最后再把处理好之后的密码放到一个新变量 ePwd 里面。

由于之前的 sign 参数是写死的123，这里也改成调用 jar 包里面的 getSign 方法来生成。

由于密码参数换了一个变量，所以要调整一下 HTTP 请求。

最后再次运行，可以看到 密码不再是明文了，sign值也不再是固定的了。

自定义的 jar 包，记得要在测试计划里面添加一下！

写在最后

参数化是一个很有用的功能，可以让我们的参数动起来。