目录
一． 编写目的
二． 术语定义
三． Jmeter 基操

1. 测试计划
2. 线程组
   
3. Test Fragment
   
4. Transaction Controller
   
5. User Defined Variables
   
6. User Parameters
   
7. Regular Expression Extractor(正则表达式)
   
8. Response Assertion
9. BeanShell Assertion
   
10. JSON Extractor
    
11. Module Controller
    四． Jmeter 的接口自动化测试
    
12. 框架详解
13. 框架的利弊
    

一．编写目的
(1) jmeter 的基本操作。（以支持接口自动化测试）
(2) 如何使用 jmeter，进行接口自动化测试。

二．术语定义
术语 说明
接口测试 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

三．Jmeter 基本操作
1.测试计划

创建一个项目会自动生成一个测试计划
1）测试计划页勾选 “Run ThRead Groups consecutively”，可控制线程组的运行方式，使之按顺序连续运行。
2）测试计划页的 “User Defined Variables” 为用户指定变量，测试计划下的组件都可使用，也可以在测试计划下添加一个 “User Defined Variables” 的组件。
2.线程组

测试计划下添加 “Thread Group”
1）并发测试时，可根据 “Thread Properties” 栏去控制并发场景。

2）遇到请求 error 时的处理方式，可根据 “Comments” 的选项选择适合的场景。

3.Test Fragment

是控制器上一个种特殊的线程组，它在测试树上与线程组处于一个层级。但使用时需要和 include Controller 或者 Module Controller 配合。它的主要作用是模块化测试过程，类似于编程语言中的函数。即，将测试过程封装成测试片段，就可以在其他地方直接引用了。
4.Transaction Controller

事务控制器
1）勾选第一个选项 “Generate parent sample”，生成父样本，在查看树中可看出父子关系。

5.User Defined Variables

用户指定变量，同级或同级得子集都可使用该变量。
6.User Parameters

参数化，根据场景得并发数或执行次数循环多次参数值。
7.Regular Expression Extractor(正则表达式)

正则表达式，可获取某个请求结果指定得值并定义变量，最常用得场景就是关联所创建得 Id 给其他请求所利用，如商品订单等。
1）“Apply to” 应用得场景，默认选择 “Main sample only”。
2）“Field to check” 字段校验得场景选项。
3）“Name of created variable” 参数名。
4）“Regular Expression” 正则表达式，常用场景为选择所需字段得左边界值和有边界值，包括引号等，() 括起来的部分就是需要提取的，括号规则如下，常用得有 (.+?)。

5）“Temple” 模板，用 $$ 引用起来，如果在正则表达式中有多个正则表达式（多个括号括起来的东东），则可以是 $2$，$3$ 等等，表示解析到的第几个值给 user_id。例如：$1$ 表示匹配到的第一个值。
6）“Match No” 匹配数字，0 代表随机取值，-1 代表所有值，此时提取结果是一个数组，其余正整数代表第几个匹配的内容提取出来。
7）“Default Value” 缺省值，正则匹配失败时，取的值。
8.Response Assertion

返回断言，正常来说主要是断言请求结果存在或不存在某些字段或某些值，也可以宇 JSON Extractor 结合使用。
9.BeanShell Assertion

自定义断言，断言的进阶，适用的语言为 java，可参考如下 demo

10.JSON Extractor

后置处理器，可处理较为复杂的结果获取后置结果某个值，homin 目前使用该组件主要是获取队列结果的长度，即一个 list 里有多少个 map，以此保证 assert 的准确性，具体方法如下：
Json Extractor

Response Assertion

_MatchNr 为正则个数的统计，断言返回结果 [] 中有 1 个{}。
11.Module Controller

模块控制器，一般与 “Transaction Controller” 事务控制器结合使用，选择对应的事务控制器，线程组运行时，该模块就会运行所选的模块。

四．Jmeter 的接口自动化测试
目前使用 jmeter 的框架思路主要是利用 Test Fragment 封装用例单元，使之模块化，按接口划分线程组，线程组下添加事务控制器作为测试用例，在事务控制器下利用模块控制器进行测试单元的组装。
思路图：

Demo：

用例图：

1.框架详解
~从上往下
测试计划：=项目名称/用例模块，如：电商项目一个测试计划、用户管理一个测试计划、订单管理一个测试计划。
字段参数化：字面意思，便于该用例模块的参数调用。
Test Fragment：=用例模块，如：用户管理一个测试计划、订单管理一个测试计划。
Transaction Controller：=用例组件，将接口请求和对应的断言封装起来作为用例组件，便于用例组装。
线程组：=以接口为单位划分的 RunAll 组件，如创建订单的接口用例。
线程组下的 Transaction Controller：=测试用例，由单个或多个 Module Controller 组装而成。
Module Controller：=用例模块的调用。
结果监控，报告生成：目前暂时没有一个适用于接口自动化的测试报告，添加一个查看树去看报红的用例。

2.框架的利弊
利：
1）能够循环利用已封装的测试单元
2）单个接口场景的运行较方便，运行一个线程组即可

弊：
1）单个用例场景的运行较不方便，需要屏蔽线程组下的其他事务控制器再运行线程组

（只运行 testCase003）
2）不利于公共断言方法，模块控制器所能控制的最小单位为事务控制器
3）暂无适用于接口测试报告生成的方法
4）有多层级用例模块时不好划分，目前是创建多个测试计划解决，即多个 jmx 文件。。。