众所周知，在进行接口测试的过程中，需要创建不同的场景（不同条件的输入，来验证不同的入参的返回结果）。因而，在日常的自动化接口监控或商品监控等线上监控过程中，需要配置大量的入参来监控接口的返回是否正确。

日常常见的线上监控几个简单的监控示例场景如下：

• 监控电商网站某个类目下的商品数量。若类目中商品的数量小于一定的数量，则认为需要认为查看商品池的商品是否正确；
• 监控商品的价格。当商品价格出现超出限定的波动幅度时，通知相应的商品负责人，对其进行确认，从而保证商品价格的正确无误。
• 监控商品在某一地域是否有货。当地域存货达到最低库存时，通知负责人进行货源补充；或者当某地域限制出售或未配置地域库存时，若发现存在相应库存，则可通知相关人员查验等。

那么，在 JMeter 中改如何对 HTTP请求进行参数化呢？

在 JMeter 的配置原件中就为我们提供了参数化需要的配置，下面以 CSV Data Set Config 进行参数化演示示例的配置，路径如下图所示：

PS：通过上图可以看出我们可以进行各种各样的参数化设置，例如用户自定义变量、计数器、HTTP Cookie 管理器等，同时也可以通过 JDBC 读取数据库中保存的测试数据（需要相应的 jar 文件支持）。

CSV Data Set Config 读取的文件不仅仅限于 csv 文件，其可以读取文本文件，文件内容需以英文半角 "," 隔开，每一行为一条测试用例数据。

下面开始以大家都熟悉的搜索功能展开 HTTP请求 参数化配置实例演示，具体的操作步骤如下所示：

第一步、获取搜索的 HTTP请求

获取搜素的 HTTP请求如下图所示（此步不再赘述，不知如何获取 HTTP请求 的小主，敬请参阅之前的博文，非常感谢！）：

第二步、通过 HTTP请求，确定需要参数化的变量

通常根据实际的参数化需求，选取符合测试需求且经常变化或未来会变化的变量为需要参数化的变量，例如本例中的查询关键字、配送区域、大区、产品源（或产品平台，例如：PC、Android、iPhone等）、产品版本，均可作为参数化的变量。

第三步、创建参数化文件，并填充测试用例数据

创建参数文件 mobileApp-IDC-0-searchGoods.txt，参数文件内容如下所示（注意参数文件编码方式建议选择 UTF-8）：

第四步、通过 【配置元件/CSV Data Set Config】读取参数化文件，并对变量进行赋值。

最终的配置如下图所示：

• Filename：参数文件名，可以写绝对路径，个人强烈建议采用相对路径，避免脚本迁移时需要修改路径。
• File encoding：参数文件的编码格式。推荐选择 UTF-8。
• Variable Names：对对应参数文件每列的变量名。类似于 Excel 文件的文件头，起到标示的作用，同时也是后续引用的标识符，建议采用有意义的英文标示。
• Delimiter：参数文件分隔符。与参数文件中的分隔符保持一致即可。
• Allow quoted data？：是否允许引用数据。默认设置为 false。例如数据样式为："101-005-98536","29357","1","1993575","477948510289","android","45" 时，此处需设置为 true，一般默认为 false 即可。
• Recycle on EOF?：是否循环读取参数文件内容。默认设置为 true。设置为 true 时，当已经读取完参数文件内的测试用例数据，还需要继续获取用例数据时，此时会循环读取参数文件数据；设置为 false 时，若已至文件末尾，则不再继续读取测试数据。通常在 线程组的线程数 * 线程组的循环次数 > 参数文件行数时，才需要将此项设置为 true。
• Sotp thread on EOF?：当读取到参数文件末尾时，是否停止读取线程。默认为 false。当 Recycle on EOF?  设置为 true 时，此项不起任何作用。当且仅当 Recycle on EOF? 为 false 时，此项配置才生效。
• 若为 true，则在读取到参数文件行末尾时，终止参数文件读取线程。例如：线程组的线程数 * 线程组的循环次数 = 10，参数文件行数 = 7，那么将在第 8 次开始停止线程。
• 若为 false，此时线程会继续读取，但是会请求错误，因此时读取的数据为 EOF。以上同例，自第 8 次开始，线程的请求数据为 EOF。
• Sharing mode：共享模式，即参数文件变量作用域。主要有以下几种方式：
• All threads：当前测试计划中的所有线程组中的所有的线程均有效。默认。
• Current thread group：当前的线程组中的线程有效。
• Current thread：当前线程有效。
• 编辑：（俺暂时没有用过，嘿嘿 ^_^）

第五步、修改 HTTP请求 中对应的参数为参数变量

将如下部分中值替换为参数文件的值，即对应的 Variable Names，应用方式类似于 shell 脚本的变量引用，例如：${goodsNo}。

第六步、设置 HTTP请求 断言

将参数文件中的第 5 列（即商品的 skuid 设置为校验数据，通过此判断单品是否正确），测试数据如下所示：

设置断言如下所示：

第七步：执行脚本，查看结果

参数文件用例数据 101-006-25777,29358,1,2035074,480647572731,android,45 对应的 skuid：480647572731 设置的是错误的（方便对比断言结果）。执行结果如下所示：

第八步：脚本改进

其实，有些朋友看到这儿，可能会问执行结果列的标题均为线程标题，都是相同的无法区分，不方便阅读？其实，我们可以将脚本中的变量添加到线程名的后面（PS：需要考虑变量的作用域）即可简洁明了的区分每个线程，同时也可查看不同的入参，非常的方便。

将上述 HTTP 请求的线程名稍作修改，如下所示：

再次执行脚本，执行结果如下所示，通过下图是否可以非常直观简洁的执行结果，及对应的入参了 ^_^