本章大纲

什么是jmete脚本
怎么快速开发漂亮的脚本
脚本开发方案

什么是jmete脚本

概念：
通俗：用户操作被测软件系统某场景的动作流程
jmeter：用户操作被测软件系统某场景的请求
性能测试：重要场景从1到N，也就是说先设置一个用户跑通脚本，再设置多个用户跑脚本。

怎么快速开发漂亮的脚本

准确：最基本要求，脚本能正常运行
快速：借助技术手动快速高效完成脚本开发
漂亮：脚本逻辑、维护性高

方案一：jmeter代理

jmeter也有自己的代理，录制脚本前启动代理，手动通过浏览器来录制，录制完毕停止代理
提示：直接保存jmx文件；需要认为调试脚本；录制https需要设置
1、打开jmeter，保存文件：test.jmx

image.png

2、创建线程组：选中“测试计划”右键 - 添加 - 线程（用户） - 线程组

image.png

3、设置http代理：选中“测试计划”右键 - 添加 - 非测试元件 - http代理服务器：目标控制器：测试计划 - 线程组（不选会没有脚本），端口：代理服务器的端口

image.png

4、打开浏览器设置代理：更多 - 设置 - 高级 - 系统 - 打开您计算机的代理设置 - 手动设置代理输入jmeter ip和端口，点击保存

image.png

5、启动jmeter代理：点击“启动” - OK，显示录制窗口，关闭窗口jmeter代理就停止了

image.png

6、在浏览器上操作，jmeter就可以录制脚本了
7、由于录制的脚本太乱，存在很多无用的请求，需要通过排除模式过滤掉，重新启动录制（如果没有录制上，重启电脑再录制）

image.png

录制成功后，对录制的请求进行修改（删除不要的）

方案二：bodboy录制---已经不更新了

bodboy测试工具通过协议包进行数据交换
响应速度非常快，这款软件非常简洁，易安装
操作简单不需要输入代码，直接操作网站录制对应脚本
可以直接导出.jmx文件

image.png

方案三：fiddler

通过浏览器访问网站，同时fiddler抓包工具获取抓包数据，手动去jmeter开发脚本。
汇总：
fiddler是通过改写http代理，让数据从它那通过，来监控并截取到数据。
在打开fiddler的一瞬间，就已经设置好了浏览器代理。
当你关闭的时候，浏览器代理也会还原，所以不需要手动设置。

image.png

设置过滤

image.png

一切以抓包为主，如果抓包请求或响应数据与接口文档不符再去找研发，抓包显示的请求如何写的，我们在jmeter中按照抓包显示的格式去写，之后查看响应数据与抓包时的响应数据是否一致，如果一直说明这个接口请求成功。
【最好的方法是：接口文档+抓包】

脚本开发方案

1、打开jmeter，选中测试计划右键 - 添加 - 线程（用户）- 线程组，默认线程数1，等接口调过再增加线程数/循环次数/延时时间

image.png

Ramp-up Period（in seconds）

【1】决定多长时间启动所有线程。如果使用10个线程，ramp-up period是100秒，那么JMeter用100秒使所有10个线程启动并运行。每个线程会在上一个线程启动后10秒（100/10）启动。Ramp-up需要要充足长以避免在启动测试时有一个太大的工作负载，并且要充足小以至于最后一个线程在第一个完成前启动。一般设置ramp-up=线程数启动，并上下调整到所需的。

【2】用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。如果未指定ramp-up period ，也就是说ramp-up period 为零， JMeter 将立即建立所有线程。假设ramp-up period 设置成T 秒，全部线程数设置成N个， JMeter 将每隔T/N秒建立一个线程。

【3】Ramp-Up Period(in-seconds)代表隔多长时间执行，0代表同时并发

Delay Thread creation until needed

延迟创建线程，直到该线程开始采样，即之后的任何线程组延迟和加速时间为线程本身。这样可以支持更多的线程，但不会有太多是同时处于活动状态。

调度器

选中调度器后，需要输入启动和结束时间。当测试启动时，如果必须JMeter会等待启动时间到达。在每个周期结束，JMeter检验结束时间是否到达，如果是，运行停止，如果不是测试被允许继续，直到迭代限制到达。

另外你可以使用启动延迟和持续时间文本域。注意启动延迟会覆盖启动时间，持续时间会覆盖结束时间。

如何设置适当的值并不轻易。

首先，假如要使用大量线程的话，ramp-up period 一般不要设置成零。

因为假如设置成零，Jmeter将会在测试的开始就建立全部线程并立即发送访问请求，这样一来就很轻易使服务器饱和，更重要的是会隐性地增加了负载，这就意味着服务器将可能过载，不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值，可以通过Jmeter的聚合报告监听器看到这种现象。这种异常不是我们需要的，因此，确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率。当然，也许需要运行一些测试来确定合理访问量。

基于同样的原因，过大的ramp-up period 也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。

那么，如何检验ramp-up period I太小了或者太大了呢？首先，初始的ramp-up period=平均点击率并用总线程/点击率。例如，假设线程数为100，估计的点击率为每秒10次，那么估计的理想ramp-up period 就是 100/10 = 10 秒。那么，应怎样来提出一个合理的平均点击率呢？没有什么好办法，必须通过运行一次测试脚本来获得。

其次，在测试计划（test plan）中增加一个聚合报告监听器，如图2所示，其中包含了所有独立的访问请求（一个samplers）的平均点击率。第一次取样的点击率（如http请求）与ramp-up period 和线程数量密切相关。通过调整ramp-up period 可以使首次取样的点击率接近平均取样的点击率。

第三，查验一下Jmeter日志(文件位置：JMeter_Home_Directory/bin) 的最后一个线程开始时第一个线程是否真正结束了，二者的时间差是否正常。

总之，是否能确定一个适当的ramp-up time 取决于以下两条规则: 　　·第一个取样器的点击率（hit rate）是否接近其他取样器的平均值，从而能否避免ramp-up period 过小。　　·在最后一个线程启动时，第一个线程是否在真正结束了，最好二者的时间要尽可能的长，以避免ramp-up period过大。

有时，这两条规则的结论会互相冲突。这就意味着无法找到同时满足两条规则的合适的ramp-up period。糟糕的测试计划通常会导致这些问题，这是因为在这样的测试计划里，取样器将不能充分地采集数据，可能因为测试计划执行时间太短并且线程会很快的运行结束

假设：

线程数：n

Ramp-Up Period：T （有人称之为启动时间，有人说是准备时长，看个人喜好）

循环次数：a

若每个循环运行时间是 t

当时间到 S = (T- T/n)时，最后一个线程启动，若要使所有线程同时运作，则需要在最后一个线程启动的时候第一个线程仍未关闭，为达到这个要求，需满足 a·t > S及a > S/t

每一个个线程运行时间既是R = a·t(此处的a是大于S/t的某一值)，则第一个线程在时间点为R 的时候停止，整个测试理论运行时间则是：S + R = (1-1/n)·T + a·t

总结：

测试中变量是线程数 n ，每个循环时间 t 是个实践值，循环次数 a 只是为了延长单个线程的运行时间，从而保证当最后一个线程启动时，所有线程都在运行中，达到压测效果。

以上是我个人的总结，额，什么？看不懂！其实笔者写完了也晕了，下面我们用确切的数值进行试验

我们设置线程数 n = 5，循环次数a = 1000，请求[www.google.com]
，得到聚合报告如图：