降本提效｜JMeter插件二开完成 100-10-1 脚本的优化体验

背景

背景是这样的，针对底层通用服务，比如文件服务、文档服务等，同一份代码，会部署到不同的云岛(本地化)环境中去，提供的服务是统一的，基于不同环境配置参数的不同走不同的执行路径。为了提高回归效率，降低维护成本，结合目前公司基建的情况，当下可用的就是 JMeter 工具，希望最终能够基于 jmeter产出一份脚本，适用多个环境去执行。

需求

很多人遇到这个场景，惯性思维是每个环境都给整一份，这样每个环境回归时可独立执行。但是这样也带来了大量的维护量，比如现有 1 个应用含 10 个接口，需要部署到 10 个环境中去，后续服务每新增了一个接口，这 10 个环境10 份脚本都需要完善，做的都是重复性工作，每天疲于奔波其中，也没啥成就感。那有没有办法简化呢？那当前是有的，毕竟办法都是人想出来的嘛。我们先来整理下诉求，情况如下：

• 仅希望保留一份接口自动化脚本，一份参数文件，参数文件里面需要包含多个环境的参数

• 每次执行，不用改变已整理好的参数化文件

• 每次执行，仅希望跑目标行参数即可，无需把所有参数行都给执行一遍

• 可以指定参数变量，并能成功提取参数变量对应的行参数值，执行时仅执行目标行参数

• 界面最好可以可视化，这样可以在执行前自查确保提取的目标行的数据的正确性

现状

再来，我们看看当前的情况是咋样的呢？

目前已知的所有的 JMeter 处理器或者元件里面，都是循环去读取参数化配置文件，没有点对点提取参数去执行的，所以怎么办呢？当下有 2 种方式可实现：

• 其一：通过 beanshell 写代码来实现
• 其二：改造现有元件，使其支撑当前诉求

基于 beanshell的方式 对用户的开发能力要求较高，考虑到工具后续的可复用性和可传播性，不希望每次遇到这样的情况，都要再写一遍；另外对到开发能力弱的同学，也希望他们能快速使用，降低大家的维护成本，所以选择了第二种方案。

实现思路

那落脚点落在哪儿呢？

直接改 jmeter 源码里面现成的 csv 参数文件设置？还是类似的三方插件直接拿来改造？还是说新开一个插件功能来实现呢？

经过翻阅资料，综合比对下来，决定在类似的三方插件上直接拿来改造。

这个三方插件的名字叫：bzm - Random CSV Data Set Config。它和JMeter 原生的 CSV Data Set Config 插件的差别见我另外一篇文章：新玩具｜JMeter 插件之Random CSV Data Set Config

改造思路 

通过界面指定 目标行 的 关键字段 提取 对应的 行数据，作为目标执行参数

改造注意事项 

• 不能破坏现有功能（顺序读取、随机读取等能力）

• 新扩展的能力是可用的，包括界面上可直接查看并确认提取结果的正确性

• 目标行提取出来后，需要和脚本执行路径契合，不存在提取出来第三行的参数，结果执行的时候依然走的是第一行的参数(按照顺序执行)

改造后的效果