ThinkChat2.0新版上线,更智能更精彩,支持会话、画图、阅读、搜索等,送10W Token,即刻开启你的AI之旅 广告
**一、建立一个测试计划(test plan)** 之前有说过,jmeter打开后会自动生成一个空的test plan,用户可以基于该test plan建立自己的test plan 一个性能测试的负载必须有一个线程组完成,而一个测试计划必须有至少一个线程组。添加线程组操作如下: 在测试计划处右键单击:添加→Threads(Users)→线程组 ![](https://img.kancloud.cn/f6/e9/f6e93223671b50f2e353d68592a586d1_551x79.png) 每个测试计划都必须包含至少一个线程组,当然,也可以包含多个,多个线程组的运行在jmeter中采用的是并行的方式,即:同时被初始化且同时执行其下的sampler ![](https://img.kancloud.cn/4a/75/4a75cef3bcdfa91287e6f9c205817b3c_722x318.png) 线程组主要包含三个参数: **线程数:**虚拟用户的数量,一个线程指一个线程或者进程 **Ramp—Up Period(in seconds):**准备时长。设置的线程数需要多久全部启动,比如上图,线程数为6000,启动时间为60,那么需要60S内启动6000个线程; **循环次数:**每个线程发送请求的次数。如上图,6000个线程,每个线程发送1次,如果勾选了永远,那么它将永远发送下去,直到停止脚本; 设置合理的线程数对能否达到测试目标有决定性影响。比如在本例中,如果线程数太少,则无法达到设定的要求; 另外,设置合理的循环次数也很重要,除了给定的设置循环次数和永远,还可以通过勾选**调度器**,设置开始和结束时间来控制。 **二、添加sampler** 添加完线程组后,在线程组上右键单击:添加→Sampler→SOAP/XML-RPC Request(SOAP/XML-RPC:都是报文中不同的数据格式) ![](https://img.kancloud.cn/e1/ef/e1ef10905379aef95133b8cf193af7ea_547x579.png) 前面说过,取样器(Sampler)是与服务器进行交互的单元。一个取样器通常进行三部分的工作:向服务器发送请求,记录服务器的响应数据和记录相应时间信息 ![](https://img.kancloud.cn/da/95/da951ba6456d599401116982495e9147_1211x756.png) 这里解释一下,因为微信H5界面的会员注册,向微信端发送的是xml文件,所以这里我选择的取样器是SOAP/XML-RPC Request 上面的图中,选择SOAP/XML-RPC Request取样器,然后URL一栏输入我们需要进行加压的URL 然后默认选项,Use KeepAlive的意思是:保持连接,这个是http协议报文中的一个首部字段,之前的关于HTTP协议的随笔写过 下面的SOAP/XML-RPC Data输入需要发送的xml格式的文件就行(也可以导入xml文件的文件夹进行读取),下面是xml和json的区别: ![](https://img.kancloud.cn/f2/7c/f27cee263cfeb4199e7c124d35051362_691x146.png) 添加完取样器和具体的地址参数之后,接下来就是添加监听器,对测试结果进行获取 **三、添加监听器** 在线程组上右键单击,添加你需要的监听器,一般常用的就是结果树和聚合报告 ![](https://img.kancloud.cn/97/39/973934049bc19e63269f349f25843273_616x618.png) 添加后启动线程组进行测试,等线程执行完成后,根据结果树中的请求和响应结果(成功或者失败)就可以分析我们的测试是否成功,以及根据聚合报告结果来确认我们这次确认是否达成了预期结果。 **四、聚合报告简析** ![](https://img.kancloud.cn/47/e4/47e425276224b07dc4b634199a9d0aa3_866x192.png) **ggregate Report:** ****JMeter**** 常用的一个 Listener,中文被翻译为“聚合报告” **Label:**每个 JMeter 的 element(例如 HTTP Request)都有一个 Name 属性,这里显示的就是 Name 属性的值 **#Samples:**表示你这次测试中一共发出了多少个请求,如果模拟10个用户,每个用户迭代10次,那么这里显示100 **Average:**平均响应时间——默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也可以以Transaction 为单位显示平均响应时间 **Median:**中位数,也就是 50% 用户的响应时间 **90% Line:**90% 用户的响应时间 Note:关于 50% 和 90% 并发用户数的含义 **Min:**最小响应时间 **Max:**最大响应时间 **Error%:**本次测试中出现错误的请求的数量/请求的总数 **Throughput:**吞吐量——默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 ****LoadRunner**** 的 Transaction per Second 数 **KB/Sec:**每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec