jmeter元件分析

一、脚本通用性

1、性能测试脚本改动一下，加入断言等元件，就可以作为接口测试脚本来使用

2、但是接口测试的脚本不可以作为性能测试脚本来使用

3、原因：因为性能测试考虑更多的性能，我们写的性能测试脚本要考虑自身脚本性能，所以一般不会添加过多会影响到脚本性能的jmeter元件，例如GUI图形，聚合报告，断言等，而接口测试脚本只需要考虑功能性，会过多依赖jmeter元件的使用，所以一般jmeter脚本可以用来测试接口，但是接口测试脚本不能用来测试性能。

二、jmeter中性能较差的元件

1、所有beanshell元件

　　1.1 这个元件是用来执行Java代码的，而Java请求会对于性能要求比较高。

　　　　1.1.1 怎么执行java代码：jsr223元件，groovy函数，jexl3函数

　　　　1.1.2 beanshell元件性能差的原因是因为它是基于java代码再进行封装的一种脚本语言，beanshell执行时需要转换成java语言，再转换成字节码，所以执行起来会比较慢

　　1.2 所以，在性能测试中，能不用beanshell的地方都不用

　　　　1.2.1 可以使用jmeter的元件或函数来替换beanshell实现的功能。此方法不需要写代码

　　　　1.2.2 可以使用jsr223的元件来替换beanshell元件，通过写代码的方式

2、断言

　　2.1 断言是判断实际结果与预期结果是否相同，一般功能测试会进行断言

　　2.1 断言一般是由发起方来进行判断，判断需要一定的时间，而这个判断的时间会计算到服务器的响应时间中，从而我们发起下一个请求的频率就会降低。

　　2.3 所以，建议在性能测试中不做断言判断，没有断言，服务器返回的结果不准确，但脚本依然会继续运行，服务器依然会当做正常。不会计算到性能测试异常率中，也不会导致异常率偏高。

3、集合点\定时器

　　3.1 设定一个时间策略，然后来运行

　　　　3.1.1 时间策略，就是一个关键点

　　　　3.1.2 集合点，也有一个集合的策略，当这个策略不满足的时候，是不会向服务器发起请求的。

　　　　　　3.1.2.1 在没有满足集合点策略时候，会导致请求量下降，对服务器造成的压力变小，而当满足集合点策略时的瞬间，又会有大量的请求向服务器发起，从而导致服务器可能瞬间处理不过来而报错。所以，性能测试中，jmeter 不要去用集合点。

4、监听器

　　4.1 监听器：从不同的维度来展示响应数据　　

　　4.2 有请求发起方去做，通过监听器去做统计分析会导致我们jmeter用于发送请求的资源变少，请求量变少，请求频率也降低。所以也不可以使用

总结：jmeter做性能测试脚本，一定要考虑jmeter脚本本身的性能，尽可能追求脚本性能的完美，能少用元件就少用，逻辑能简单，尽可能简单