jmeter组件使用详解（二）

1.jmeter组件使用详解

1.1 断言（Assertions）

请求成功（返回200），不代表业务成功，业务的成功，只能靠业务来判断

断言不要检查中文（检查元素）

jmeter最佳实践说少加，加不加根据实际情况

为了方便（压力机性能好的情况下）：

• 单场景：建议查询加，非查询不加
• 混合场景：建议每个请求接口加

1.1.1 响应断言详解

apply to:

• main sample and sub-samples
• main sample only
• sub-sample only
• jmeter variable name to use(比较自定义变量值)

一般勾选“main sample only”就足够了(默认)

重定向请求（勾选了“跟随重定向”）那么就要有 main sample and sub-samples

模式匹配规则

• 包括：正则表达式匹配部分和全部，可以断言多个，and
• 匹配：正则表达式匹配部分和全部
• 相等：纯文本，区分大小写（完全匹配，比“匹配”更严格，因为区分大小写）
• 字符串：纯文本，区分大小写（完全匹配，比“匹配”更严格，因为区分大小写）
• 否：取反（如果是选择包括+否，就是不包括）
• 或者：可以断言多个，包含一个就成功

说明：

1. 模式匹配规则为“包括”和"匹配"时，支持正则表达式
2. 当为“相等”或“字符串”时完全匹配
3. jmeter中，断言成功不显示，失败才显示

1.1.2 断言持续时间

响应时间大于这个值，就报错（不会忽略思考时间）

1.1.3 Bean Shell断言

1.2 监听器（Listener）

1.2.1 查看结果树

 调试脚本用，调试成功后禁用，否则影响性能，或者只显示错误的

默认是接受返回数据但是不保存，要保存什么数据就勾选

1.2.2 聚合报告

样本：请求个数

平均值：平均响应时间

中位数：50%的请求所用的时间不超过该值

90% 百分位：90%的请求所用的时间不超过该值

异常 %：错误率，比如断言失败。本次测试中出现错误的请求的数量/请求的总数

吞吐率：即每秒多少请求/业务（包含成功和失败的）

Kb/sec：网络吞吐率，每秒多少Kb

1.2.3 jp@gc - Transactions per Second（tps）

1.2.4 jp@gc - Response Times Over Time(响应时间)

1.2.5 jp@gc - Active Threads Over Time（活动线程时间分布）

1.2.6 用表格察看结果

说明：运行的时候，监听器用得越少越好，尽可能只用一种监听器作结果记录，否则会十分影响性能

1.3 逻辑控制器

1.3.1 事务控制器

 1.3.2 吞吐量控制器

业务模型、业务比例

有关联的业务模型

业务1 查询

业务2 下订单

业务3 查订单

 比例：2:1:1

 无关联业务模型

业务1：

 业务2

 业务3

 比例2:1:1

 

1.3.3 ForEach控制器

 

 1.3.4  仅一次性控制器

2.场景设置案例

2.1 混合场景（业务比例应用）

2.1.1 业务比例 ：注册:登录:添加=2:1:1