1. 前言

  在完成测试场景的设计、确定场景所涉及的业务流程范围之后，就可以开始针对该测试场景，编写性能测试脚本了。不同的测试场景，其业务流程的复杂程度也不尽相同。当某个测试场景包含上百个网络请求时，通过人工编写的方式，显然会增加更多的时间成本，编写过程中也极易出错。
  针对如此庞大的业务请求量的测试场景，可利用JMeter非测试元件中的HTTP(S) Test Script Recorder元件，以脚本录制的方式，快速而又便捷的将其全部“收入囊中”。

2. 脚本录制

2.1. 测试脚本录制器添加

  启动JMeter，在配置元件的Non Test Elements中，选择HTTP(S) Test Script Recorder元件，将其添加到Test Plan下面。

添加脚本录制器配置元件

2.2. 脚本录制器监听网络请求

  实现脚本录制器监听网络请求的方式有多种，如：修改系统级的网络代理、修改浏览器的网络代理等。由于修改系统级的网络代理，会导致系统所有的网络请求都会被JMeter监听并录制到脚本中，因此，我们使用修改浏览器网络代理的方式，使脚本录制器仅监听浏览器中制定IP和端口的网络请求。

  1. 浏览器添加代理插件

    • Chrome/Edge等浏览器可通过插件市场在线安装或下载安装，例如Proxy SwitchyOmega插件。打开插件设置后，新建一个情景模式，配置信息可参考如下。保存后，点击右上角的插件图标，单机选择刚才新建的的情景模式即可启用。
    • Firefox浏览器的高级选项中包含网络代理设置，设置内容大同小异，各参数参考如下。

    SwitchyOmega插件配置示例

  2. 脚本录制器配置

    • 脚本录制器中的配置主要包含端口号和主机名，需要与上一步代理插件配置中的参数保持一致，否则无法中正确监听到浏览器中的网络请求。

    脚本录制器配置

    • 在绝大多数性能测试场景中，静态资源请求由于不参与后台服务器的逻辑处理，一般是不在测试范围内的。因此，在脚本录制的过程中，可以将静态资源过滤掉，过滤的方法在脚本录制器的Requests Filtering中进行配置，如下图所示，过滤的表达式可参考如下。

    Requests Filtering配置

    1
    2
    3
    (?i).*\.(bmp|css|js|gif|ico|jpe?g|png|swf|woff|woff2)
    .*\.js.*|.*\.css.*|.*\.html.*|.*\.jpg.*|.*\.ttf.*|.*\.png.*
    .*\.otf.*|.*\.cab.*|.*\.woff.*|.*\.woff2.*|.*\.swf.*|

2.3. 手动执行业务流程

  1. 完成以上配置后，即可开始录制业务流程场景的性能测试脚本了。首先，根据被测业务场景的流程，将其划分为若干个事务（一个事务对应用户操作一次浏览器的过程），并选择一个事务控制器，添加在左侧的元件树列表中。以某购物平台的查询订单物流信息为例，可大致分为如下几个事务：登录、点击我的订单、查询未完成订单、点击物流信息、退出登录等。

    由于针对一个用户（线程）而言，登录和退出登录仅需操作一次，其他事务才是该场景中真正需要被测试的，所以登录和退出登录这两个事务控制器无需放置在循环控制器中。loadRunner中，一般会将这两个事务分别放置在vuser_init和vuser_end中，中间的事务放置在action中。

    事务划分和添加

  2. 切换到脚本录制器中，点击Target Controller下拉框，可看到上一步咱们添加的事务控制器列表，此项需要在业务流程操作的过程中同步选择。选择的原则是，下一步准备操作哪一个事务，就选择哪一个事务控制器。

    目标控制器选择

  3. 在脚本录制器元件中点击Start按钮，监听启动正常后，会弹出一个用户录制控制的浮框，打开浏览器，访问被测项目的地址，依次操作并录制各个事务动作后，点击浮框中的Stop按钮，即可停止监听和录制，此时，该业务流程场景对应的测试脚本就已录制完成，可在左侧的元件树中查看。

    注意：每一个的页面操作，需要等待页面完全加载完毕后，方可切换到下一个事务控制器，否则A事务中的网络请求将会被录制到B事务控制器中。

    业务流程录制后的脚本示例

3. 脚本调试

  到此为止，咱们已经完成了脚本录制的工作，接下来，则是到了性能测试工作中至关重要、也是最繁杂的脚本调试阶段，性能测试脚本的维护工作也主要集中于此。

3.1. 脚本调试的内容

  1. 将业务流程中的测试数据修改为由外部文件提供的方式，使其可被用户统一修改和维护，如：商品名称、商品数量、登录用户信息等。
  2. 寻找业务流程中存在上下文关联关系的数据，将其修改为上下文引用变量的形式。如：登录成功后的会话token、订单提交后的订单ID等。
  3. 验证脚本的可行性和正确性，运行过程中不允许出现接口不通（由于性能压测导致接口超时除外）、数据数据文件读取失败等错误。

3.2. 脚本调试过程

  1. 按接口请求顺序，依次查看各事务中各个请求的cookies、入参信息，确认是否有动态变化的参数。

  2. 如果有存在上下文关联关系的参数，向上分析最早返回这个参数值的请求，添加一个后置处理器，如正则表达式提取器、CSS选择提取器、JSON提取器均可，用来解析获取请求返回报文中的参数值。

  3. 在XX提取器中定义好变量名称，正确填写提取表达式、匹配维度、默认值等信息。

    正则表达式提取器提取sessionID

  4. 使用全局替换的形式，将相同参数值替换成变量名称，变量格式为：${VarName}。

    数据替换及变量引用

  5. 如果有由用户输入的参数，则在线程组之前添加一个CSV Data Set Config等配置元件，配置参考如下，然后以全局替换的形式，依次将原来的数据替换成对应的变量名称即可。

    Filename：数据文件名，建议填写相对路径，并将文件放置在JMeter主目录下

    File encoding：文件编码，根据数据文件确定，建议设置为UTF-8

    Variable Names：变量名，与数据文件中的数值相对应。如果有多个，用英文逗号分割

    Ingore first line：是否忽略第一行，根据数据文件中的第一行内容确定

    Delimiter：分隔符，根据数据文件中的内容分隔符确定，建议选择与数据无关的字符

    Allow quoted data：是否允许数据带引号，根据实际的数据文件内容确定

    Recycle on EOF：文件内容遍历结束后是否重新开始遍历，根据实际文件内容和业务场景确定

    Stop thread on EOF：文件内容遍历结束后是否停止线程，根据实际文件内容和业务场景确定

    Sharing mode：数据共享模式，实际文件内容和业务场景确定

  6. 最后，添加一个View Result Tree元件，用来查看运行时是否出现错误。当调试完成后，所有的网络请求和数据提取都没有报错（显示为绿色）时，则可以表明该测试脚本运行正常，可用于后续的正式性能测试。

性能测试工具JMeter合集
【Performance】01. 性能测试技术初探篇之性能测试介绍
【Performance】02. 性能测试技术初探篇之常用性能测试工具
【Performance】03. 性能测试技术初探篇之 JMeter 工具使用
【Performance】04. 性能测试技术磨合篇之性能测试场景设计
【Performance】05. 性能测试技术磨合篇之脚本录制和调试
【Performance】06. 性能测试技术磨合篇之脚本执行和结果分析
【Performance】07. 性能测试技术历练篇之性能监控工具
【Performance】08. 性能测试技术历练篇之性能分析神器 JProfile
【Performance】09. 性能测试技术历练篇之 Java 诊断工具 Arthas