l_q_l的专栏

在JSR223中推荐使用vars.get(“key”)的方式使用变量，而非${key}的方式。

JMeter是基于Java的应用，以线程的方式来模拟用户。每个线程占有的内存一般是8KB，所以并发用户较高时，使用单台计算机容易出现Java内存溢出错误。因而，在高并发时，通常需要借助多台机器同时发压，以产生足够的负载。

JSR223全称为Java Specification Request 223。其中JSR（Java Specification Request）是Java规范提案中的缩写，而JSR223是其中的一个提案，旨在将脚本语言集成到Java平台之上。所以，相比于BeanShell解释器，它支持更多的脚本语言：groovy、beanshell(java)、javascript、jexl和jexl2等。JSR223 PreProcessor：在执行取样器之前运行JSR223脚本代码的前置处理器。

今天录制脚本，发现点击后系统没反应，以为是项目组的特殊设置，当时并未深究，便直接用浏览器抓包，自己手写脚本。谁知写完执行时，却出现了奇怪的错误：明明是一个登录请求，下面却催生出两个子请求来，而且，即便是绿色的这个请求，响应数据也不对。费了好大劲，最终却发现，这个项目全部都是https请求，而我，习惯性的将协议写成了http。由此想到，如果第一步脚本录制的时候就停下来研究一下为什么不能录制，或许，还能少走些弯路。有时候，想要偷懒绕开某些困难，绕了一大圈发现，还是要回去面对。

将上例中的11 和 22调换位置，22作为循环体内的第一个采样器，重新执行可以看到，虽然22已经断言失败了，但是循环继续。因为循环条件仅判断循环体内最后一个采样器的结果。我们将之前的While Controller复制一份，稍加改造${__jexl3(${__Random(0,50,)}==0,)} //数字等于=0,)} //数字不等于${__jexl3("${var}".equals("qwe"),)} //字符串相等${__jexl3(!

用过JMeter参数化的小伙伴，想必对CSV Data Set Config非常熟悉。大家平时更关注变量名称，是否忽略首行等参数，其余的一般都使用默认值。然而我最近遇到一个未按照我的预想读取数据的案例，原因就出在最后一个参数“线程共享模式”上。记录一下，大家避坑。

性能测试过程中，对于数据库的增、删操作，除检查接口本身的响应之外，还需要通过查询相关数据条目的增减来验证是否真正成功实现了增、删操作，以确保系统在高并发情况下，仍然可以实现业务的准确性。通常，通过对比压测前后的数据增量与压测成功事务数是否相等来实现。某系统用户提交订单之后，在订单列表页面会新增一条记录。但是，因为测试过程中多用户并发，每个用户只能查到自己的订单，所以检查时需要逐个检查所有参与并发测试的用户名下的订单数量，然后加和求总。1、定义一个变量totalCount，来存储各用户所查询出来的结果2、 用

在BeanShell中使用fastJson处理json格式数据

大多测试场景中，我们执行登录之后，将始终使用登录的这个用户的身份信息，反复的执行某业务来进行压测。也就是说，登录这个动作，只执行一次。所以，将登录账号信息放在文本文件中，使用CSV Data Set Config读取，是常用的一种参数化手段。但是在我之前分享的案例中，修改密码后系统会自动将该用户登出，想要再一次修改密码，就需要重新登录。于是，就需要登录->修改密码->登录->修改密码这样的循环，直接使用CSV Data Set Config就不行了。

在昨天的博文中，因测试场景反复修改密码，为了保证测试结束后给密码复位，不影响别的场景测试，我的方法是在修改密码的线程组后面添加另一个线程组，执行密码复位操作。但是这样有一个风险：执行测试的人，必须要记得后面的这个线程组是用来复位密码的，要与修改密码的线程组一并启用，且仅循环一次。一旦疏忽，就可能导致后面计划的其他线程组的测试全部因登录失败而出现大量错误。我们的测试通常在晚间执行，这种风险，还是尽量规避。所以，我想找到一种不需要任何附加条件的执行复位操作的方式。

某系统要求压测修改密码功能。我们不讨论这个场景是否有必要压测，只从技术角度，讨论如何实现。乍一听觉得这个场景很简单，没有复杂的业务逻辑，也不需要前后关联，就一个接口的事儿。然而真正做起来，却还是费了点时间的，记录一下。

BeanShell作为JMeter的强大扩展，可以帮助我们实现很多JMeter内置组件无法完成的工作。但是，我接触性能测试仅仅一年的时间，在项目中似乎很少有不使用BeanShell的。尤其最近一次因使用BeanShell导致JMeter OOM，而使测试中断后，我开始反思，是否必须要使用BeanShell才能完成呢？或许正是因为我对JMeter的了解不够，而之前又有多年的编码经验，才使我更加习惯于直接编码来解决问题，反而忽略了对JMeter工具本身的探索。

一般来说，在JMeter脚本中，我们需要上传文件时，都会在本地保存一批固定的数据文件，反复执行上传；需要传递Json格式的参数时，会通过Sampler的Body Data上传，在其中可以方便地进行关联及参数化。然而，在前文content-type中的multipart/form-data中的案例，却是以上二者的综合体：其中的第三部分要上传的文件不是一个静态json文本，而是需要在运行时根据前面请求返回的响应，动态生成所需要的json文件，然后再在请求中，将该json文件上传。

JMeter提供了许多功能强大的内置函数，可以借以获取到JMeter属性及运行时的各参数、生成随机数据、完成字符串处理等操作。这些内置函数，可以通过JMeter提供的工具Function Helper Dialog方便地获取到。然而，函数及其使用方法可以快速学习，如何使用以解决业务中的实际问题，却需要日复一日地积累。本文将不断记录工作中所使用到的内置函数的案例，以期待为解决后续更多的问题提供经验和灵感。

了解JMeter内置函数的小伙伴，想必都对${__UUID}不陌生。不需要给它提供任何参数，就可以生成一个随机字符串，简直不要太简单。然而，即便是这么简单的内置函数，也让我掉坑了。

上一篇介绍了。

总结一下：1、Sampler中勾选Use multipart/form-data复选框来指定当前的content-type为multipart/form-data，而请求头Header Manager中，不要写content-type2、payload中有filename的部分，需要上传文件，在jmeter中的Files Upload中逐一指定参数名称，文件路径及文件类型；