jemeter性能测试
1：性能测试关键指标
衡量性能测试的参数
一：响应时间
二：并发用户数
三：吞吐量
四：系统性能计数器（资源使用率）
五：思考时间
功能性测试：pass和fail
性能测试指标：多维度的指标衡量：快不快，强不强，好不好
多（支持最大的用户访问量） 快（响应时间多快） 好（持久运行） 省（资源节省）
多：并发量 快：延时，响应时间 好：稳定性，长时间运行 省：资源使用率 +一个思考时间
一个好的系统就是多快好省的一个系统
2：响应时间
对请求做出响应所需要的时间，是用户感知软件性能的主要指标
如上典形的三层模型：客户端（浏览器），应用服务器，数据库服务器 所有的应用服务器和数据库都是基于操作系统的
客户端在桌面上打开一个电脑，输入网址，通过http请求先发送到web服务器，web服务器根据链接查找文件，有网络接收时间
有处理时间A1，之后如果要查数据（比如登录验证用户名密码）需要访问数据服务器，有个N2网络时间发过去，
如果数据服务器和web服务器是同一台，那么N2和N3基本认为可以没有了，变成了程序时间的进程通信，本机交互
如果web就在web服务器打开网页请求，那么N1和N4就没有了，三合一就没有网络时间了
响应时间包括上面的全部：N1,A1,N2,N3,A3,N4
用户不知道经过多少服务,只看打开页面和接受的时间（两者时间差），客户感知的感应时间：是端到端的（不管中间经过多少请求，多少处理不管）
发出请求多久能受到
测试工程师需要关注：N1到N4所有的请求的时间 web服务器和数据库服务器的网络响应时间N2和N3：linux ping命令查看两台系统的响应时间，简单
这是网络时间，不是处理时间
响应时间多少合理：
对于一个web系统，普遍接受的时间标准为2/5/8秒
2秒钟之内响应客户是非常好的
5秒钟之内响应客户是可以接受的
8秒钟是客户能够接受响应的上限
响应时间包括：
1：用户客户端呈现时间
2：请求/响应数据网里传输时间
3：应用服务器处理时间
4：数据库处理时间
3：并发用户数
用户三种类型：
系统用户数：1w个人注册了，下载了app并且注册了，保存在数据库里面真正的一条条数据（app热不热门看app的注册量，不是下载量）
注册用户数对系统影响不会太大，主要影响磁盘空间，存储上面，内存也会受到影响，cpu也会受到影响
响磁盘空间满和空对于系统查询来说是有很大影响的，系统性能测试的时候一定记得初始化环境
装的东西多了，找东西更花时间，捞数据更慢
性能测试需要部署这部分系统用户数，存量用户，系统的环境
系统性能测试需要构造出跟现场差不多的环境，数据库空的，和数据库有一亿数据的是有很大差别的
存储区域满的的需要寻址去写入数据，空白的写和塞满了找空格去写，写的速度一样，找地址的速度相差很大
没有经过初始化的性能环境==没有作用的环境（现场的配置，现场的用户量，还有网络环境，测试的时候数据a机器，服务器b机器，两个机器背靠背网线一连接
交换机都不过，这样进行系统测试也是没有什么意义的，现场a机器上海，b服务器北京，一测就是gg
测试时候：a-b可能就是0.0001s，现场：a-b可能就需要2s了，这时候找运维：注入延时，两台电脑的防火墙上面注入延时
linux系统注入网络延时的方法，windwos注入网络延时（命令工具注入都可以）规定必须2s才能牵手）
在线用户数：
登录了，但是没有行为，什么都不干，对系统就没什么压力
12306：在线被踢了，登录不上系统
在线用户数影响：
内存（web的session会话需要保持，会话放在内存里的，同时在线需要保持登录状态，内存消耗很大）
cpu：在线用户数和cpu有关系但是关系不大，
cpu：时间片，cpu基于时间戳的，每个进行任务分个固定时间，看状态好不好执行，执行好了执行下一个，保持业务任务公平执行
每一个进行都有个时间片，用完了下一个，排队，全部塞在内存里面的进程，在线用户就是一个session，cpu会看里面有没有动作
一个个过掉了，因为用户没有操作，没有行为，会花时间，基本上很少，切换的很快的，和cpu关联不大
磁盘：一丁点关系
网络：一丁点关系
对什么要求最高，什么就容易产生瓶颈，系统测试就是在木板里挑选一个短板，
并发用户数：秒杀了，同时在线做操作，
1：严格并发 所有的人再同一个时间做同一件事，同一时间点一个按钮
2：广义并发 不严格并发，你点你的按钮，我点我的按钮，你打开页面，我登录，你查询，我下单 这也是并发
性能测试需要两个都在，极端情况下做一个最敏感的，秒杀双11抢购，平时有秒杀的，查询的，改订单的，等做成一个不同的场景出来
用不同的jemert去洪他，所以性能测试只有一个jemeter是不合格的，只有一种场景不得行，（性能测试需要几个jemert，脚本需要几套）
极端的可能就一种情况，但是一般需要规划的：100个用户，25个登录，25注册，25查询，25评价
一般严格并发和广义并发都要测试---这就是性能的规划了
并发用户数的计算公式
知道平均的每天多少访问量，一天内登录导退出的平均响应时间，总共观察多少时间得到一个这样的公式
每天多少访问量，每个人访问的时间，考察的时间长度（一天或者半天）来进行计算，就是平均并发用户量
3000用户，平均每天400个系统访问系统，典形用户一天只在8小时内使用改系统，从系统登录到退出系统的平均时间4小时
C=nL/T=400*4/8=200 得出并发用户数200 估算
C^=200+3*根号C
如果系统不熟悉，并发用户数怎么计算
并发用户数量的统计的方法目前没有准确的公式
不同系统会有不同的并发特点
假如QA系统统计并发用户数量的经验公式为：使用系统用户数量*(5%~20%) (系统注册用户数量的百分之5-20)
1w人注册，固安一下500人的并发量
前面用户量从0-500，系统还好的响应时间基本不变，后面用户量达到500了时候，突然升到很高，这里就是性能拐点，
到了这个临界点性能就很糟糕了，500用户量达到性能瓶颈了，用户响应时间超长，用户还可能没有响应了，500这个并发量就是
性能拐点，jemter有监听和统计报表
4：吞吐量
吞吐量：单位时间内系统处理用户的请求数，单位时间，比如1个小时，系统让1w个人正常访问
吞吐率：单位时间变成1s，每秒钟多少，一般关注吞吐率，一秒钟能处理多少，这时候TPS出来，每秒钟处理的事务数
一个事务可能包含几个消息，TPS吞吐率，js有这种空间计算的
吞吐率吞吐量有不同的方式，每秒钟多少字节，多少请求，一般使用请求数的比较多
吞吐量的估算计算公式
100个并发，每个VU间隔1s法出一个请求
吞吐量=100*1/1=100
图形分析
随着用户量的上升，吞吐量上升，再上升的时候就平了，并发用户再多的时候，不变了，瓶颈了，上不去了，饱和了，性能瓶颈了
这时候需要加一套服务器或者看一下内存满了还是cpu满了，还是磁盘满了，资源监控和分析
这里面出现饱和的基本上都是网络原因比较多，cpu和内存的问题不会一条线那么绝对会不变动，会有波浪
这时候可能是网络臃塞了，需要加带宽了，网络丢包了，很无情，满了就丢
内存满了会和磁盘进行交换，用交换空间，会震动一下
cpu满了有时候会下来一些，，空闲时间突然可能好了一点，会波浪线上上下下，一条线这么绝对可能就是网络
后面可以网络命令监控一下
5：性能计数器（资源使用率）
性能计数器：描述服务器或操作系统性能的一些数据指标
比如：
内存
cpu
磁盘等资源使用率
6：思考时间
消息和消息之间留一个等待时间，发一条消息，然后等1s再发一条信息，更加真实模拟用户的行为，
Think Time：业务角度来看，这个时间指用户进行操作时每个请求之间的间隔时间
在做性能测试时候，为了模拟这样的时间间隔，引入了思考时间这个概念，更加真实的模拟用户操作
7：系统环境初始化：重点
网络方面：注入延时
对于数据库：不是很敏感的数据，把数据库dump过来，导出来，备份还原进去、数据很敏感，根据数据的表格格式
姓名，密码，电话号码，邮箱，等，知道格式后使用数据库脚本创建就行了，模拟出来，构造出来
知道结构和量就行了，1千万的数据脚本刷进去就行了
对于在线用户数：warm up热机，热身，让用户跑进去，把内存填起来，不要为空，让系统接近于正在运行的系统，让系统查询速度更快
，数据从磁盘进入内存的一个过程，正常跑的系统，里面大部分用户数据在内存里面的，速度更快，
一开始跑，特别是查询的时候，速度很慢，长时间跑的数据片和数据区在内存里都存在，直接从内存里调导cpu去
什么都没跑过的，什么都要从磁盘里面去拉，内存和磁盘速度相差几千几万倍的差别，性能之前需要热机
1：磁盘用户调入内存 2：让内存接近现实场景，更加精准
热机：jemeter先洪一洪，洪一段时间然后再开始算响应的时间，jemeter跑一跑再算时间，前面热机的时间不要算时间
尽量让用户都进去，跑半个小时之后再计算性能的响应时间，tps，资源使用率，系统进入稳定期才开始计算
8：测试下这个web系统的性能，看能支持多少并发
在确定并发用户数之前，必须先对用户的业务进行分析，分析出其中的典形业务场景（用户最常见的，最关注的业务操作），然后基于场景获得其并发用户数
常见场景：访问网站首页，登录功能，核心业务功能，个人中心
9：jemeter性能测试工具简介
多线程框架，
进程：启动jemeter是一个java进程
线程：java并发去创建用户数，这个用户数就是java进程里面的线程
多线程框架：jemeter里面可以创建很多线程数（用户数）
对服务器的模拟负载：
性能测试两个级别，用户线程级别的，用户进程级别的，行业用的比较多的都是线程级别的
jemeter可以模拟很多线程，一个线程就是一个用户数，然后去压测服务器，对服务器进行模拟负载的测试
模拟一千个用户在线：通过jemeter可以实现
支持各种服务器的性能测试：
web的，数据库，FTP的各式各样的都可以，可以专门测试某些接口，也可以测试对应的这个数据库都可以
开源，存java，可二次定制化开发
jemeter发tcp协议的时候，发现自带的tcp取样器有时候结尾是uf结尾的，有时候协议不太支持，这时候需要进行二次开发
10：jemeter运行环境搭建
jemeter下载好电脑有java环境就ok了
工具一般不用最新的，除非需求新工具的新需求，
jdk：一般是带开发小组件的，可以开发程序的工具包
jre：java运行时环境，如果只运行java程序要jre就行，不需要jdk
jvm：java虚拟机
jmeter.bat windows批处理文件，jmeter在windows环境运行的按钮，双击就可以启动
jmeter.log jemeter日志文件，跑的东西都在这里面记录下来
jmeter.properties jemeter属性文件，很多属性在里面设置
jmeter.sh .sh表示linux服务器启动的执行文件
jmeter-server 启动单台jmeter在windows里面jmeter.ba这个就可以启动单台，如果通过分布式去做的话需要jmeter-server使用这个
分布式：一台电脑能承受多少用户数
每一条机器能创建多少个用户数：
内存（物理内存32g）
jmeter本身是一个java进程，进程需要消耗一定的内存资源（堆内存）
所以一台机器能虚拟多少用户数，一个是本机物理内存多大，另一个是给jmeter这个进程多大的堆内存
端口号：端口号分配不均，不合理也达不到很好的发挥
所以很多时候虚拟5000个用户机器牛逼就行了，还需要多台机器做分布式，
主机下面很多从机
如果需要虚拟4000个用户，找四台机器，主机下面四台从机，每个从机都是1000，主从的方式实现分布式
正常性能测试一台机器搞不定的，
分布式：负载均衡，用户负载，找几个哥们分担用户数
jmeter是java进程，每个进程会消耗一定的内存，所以打开jmeter的时候有个默认的堆内存，堆内存是提供java进行使用的内存空间
jmeter环境设置：
jmeter home和path路径
dos运行命令：里面有个path路径，输入jmeter的时候会到每个path路径去找，有没有这个命令，有就能运行，没有就会提示不内部或者外部指令
找环境变量
用户变量：a用户设置的变量b用户使用不了了，一般设置系统变量
系统变量：
gui：带窗口的界面化模式，gui模式，jmeter一般不使用gui模式去做负载测试，因为gui会消耗一定的资源
windows和linux系统的差别：gui模式会有很多资源处理页面的一些操作，会消耗很多性能资源的，性能下降
这就是为什么设设置path路径使用命令行模式
HEAP：堆， jmeter配置了堆之后cmd显示得还是不会改 ，显示得时候写死了，设置8g显示还是256m，正常设置是生效得
这个只是个提示
11：jmeter工具的使用
文件
新建
模板：其他请求的模板（不太知道的接口不知道怎么写，里面对着写就行）
编辑
启用：某些原件本次测试不需要，右键禁用就可以，禁用后选项不起作用了
禁用：
运行：
远程启动：远程启动两台机器，多台机器，其他机器来跑也是可以的，脚本自己会同步的，不需要传，只要自己关联好
主机控制从机去运行（分布式）
参数化：怎么做，文件怎么放，放到那里去，复制几份，内容怎么分盘，放哪个目录，不同版本目录要求不一样
选项
一些皮肤外观或者语言的设置，放大缩小
语言设置目前是临时设置，如果想永久生效需要修改jmeter.properties的37行，保持重启jmeter
下面还有一些分布式的设置也在jmeter.properties里，如下
Tools工具
创建html_report报告：
聚合报告的查看：聚合报告汇总的一个窗口信息
libei：请求的名称
样本：请求个数
平均值——最大值：响应时间，单位ms
异常：错误率
吞吐量TPS：单位时间内系统处理用户的请求数，单位时间，比如1个小时，系统让1w个人正常访问
接收：
发送：
12：jmeter生成html报告
一：点击html_report
二：通过下面的页面使用csv文件生成报告
1：Results file：结果文件，两种格式，csv，grl都是数据文件，选择浏览，选中桌面的csv文件即可
2：user.preperfiles file：用户的属性文件，很多设置都在属性文件设置的，不同的属性文件代表jmeter配置不一样的
找到jmeter文件——>bin——>jmeter.properties
3：output directory：导出的html报告放在哪里，可以放在一个html_report的空目录去
4：generate report：点击生成报告，生成html页面，多少错误率，多少数据都能记录
13：线程组，setup和teardown的区别
线程组：普通的线程组，正常运行的，初始化
setup：无论怎么放都是第一个运行的，与位置无关
teardown：无论怎么放都是最后与一个运行的，退出恢复的，环境清除
14：jmeter性能测试脚本开发
一：什么是jmeter脚本
俗称：用户操作被测软件系统某场景的动作流程
jmeter：用户操作被测软件系统某场景的请求
性能前功能肯定ok的，功能测试和性能测试最大的差别：功能一个用户就可以了，功能实现就ok了
性能测试需要n个用户，n个用户取决场景的需求，需要多少用户
用户从1到n的区别
被测项目的性能测试，模拟用户量，并发数，不止一个用户，n个用户操作需要一个剧本，
脚本就是用户操作被测系统某些场景的动作流程，让用户干什么
jmeter操作的流程翻译成jmeter能识别执行的对应的脚本
性能测试脚本流程 ：
1：找到测试哪个场景，
2：场景如何去做，步骤
3：开发对应的脚本
脚本开发一开始都是用一个用户去跑，一个用户没有问题根据需求去并发n个用户去做性能测试，通了再说
二：快速开发漂亮的脚本
准确：最基本要求，脚本可以正常运行，只是能通
快速：借助技术手动快速高效完成脚本开发
漂亮：脚本逻辑，维护性高
整个性能测试重点是性能的监控分析调优
三：开发脚本方案
1："代理"剑
最合适的脚本方案：文档+fiddler抓包，最快速靠谱的，
通过jmeter代理录制的，这个脚本的录制脚本很乱，都是需要调试的，工作量也很大
jmeter有个代理服务器的原件，抓包工具和工具自带的录制都是代理的
代理在pc和server中间加个中转站，通过代理转发http请求，请求和响应都会在代理服务器全部捕获到
fiddler和jmeter的代理录制的方式都是一模一样的，所有录制都是辅助脚本开发的，
15：jmeter脚本的保存
保存之后就有对应的工程了，
2：创建线程组，脚本在线程组使用，录制的地方放在这个里面去的
3：设置一个代理，jmeter本身有代理的，点击一下右键增加非测试元件，选择http代理服务器
如下：
目标控制器就是脚本放在什么地方的：选择测试计划>线程组
global settings：代理服务器的端口号，浏览器访问的时候就需要经过这个代理了，pc浏览器也需要设置包经过代理
pc浏览器设置手动代理，让他去访问这个代理服务器，抓取对应数据，保存到脚本
浏览器设置代理服务器如下
127.0.0.1 8888 然后点击保存
浏览器设置了代理我们的web端现在是访问不了服务器的，因为jmeter的代理没开，需要点击启动打开一下
然后启动jmeter的代理服务器，代理就是jemert本身，点击一下上面图片的启动按钮，现在就可以进行抓包了
现在jmeter录制的脚本很粗糙，里面很多静态资源，图片的，js的，增加一个排除模模式
先过滤掉这四个，都是常用的，还有js也可以过滤
现在过滤一部分请求了可以少抓很多请求了，过滤，不过滤太麻烦了
上面就是代理服务器的录制方法：两大步
1：浏览器代理的设置
2：jmeter代理的设置
16：badboy录制脚本
现在很少用了，已经不更新了，也能录制脚本
17：fiddler进行脚本录制（把抓包的会话转成jmx文件）
fiddler原理：正向代理，打开fiddler自己打开代理，关闭的时候自己关闭代理
fiddler抓包后——>file——>export sessions——>all Sessions——>导出一个jmx文件
jmx文件直接拖到jmeter里面就行
19：文档+fiddler开发脚本是最快的，实在不会写还可以借助录制的脚本对比一下，看录制本身怎么构建请求的
文档为主还是必须的
20：token脚本实战
任何脚本里面都需要创建一个线程组，线程组里有用户数，
一百个客户，五百个客户都是在线程数里面设置的，开发前期都选择一，搞通了再往下
一：线程里面增加一个什么协议的，比如取样器选择对应的哪个就行了 如下
选择http请求，然后在页面修改一下接口名称，添加注释
然后一下基本信息按照接口文档填写：ip地址，端口号，请求方式，路径，编码（看请求，如果有中文加utf-8就可以了，没有就不要写）如下
接口名称，协议，ip、地址，端口号，方式，路径必须填写
参数：一般表单形式比较多，变量等于值这种类型
消息体数据：一般放json格式的，或者xml格式的，也可以放表单（a=1&c=2）
文件上传：文件上传的接口里面需要放到，比如文件路径，文件名称，文件格式
二 最后记得写一下请求头，很多时候默认版本不一样的，写一下：
名称：Content-Type 值：application/json 写在请求头里面
http请求头的添加需要配置原件：如下 线 程组右击鼠标
找到http信息头管理器，整个jmeter有个很关键的东西：作用域：
消息头管理器放在整个线程组里面表示整个线程组所有请求都是共享它的，
所有如果不想在整个线程组生效，只是单个接口生效，把针对这个请求的请求头拖拽到get_token这个请求里面就行了
现在消息头管理器就到接口里面去了，作用域变了，只对这个请求有作用 重点
操作如下：
基本请求和头写好了后，还需要一个监听的 如下：
三：增加监听器
添加查看结果树后点run一下，请求就成功了，很简单
现在就能成功看到响应结果，这个接口就完成了，单个接口ok
还可以切换格式查看请求结果
如果想把参数提取出来：输入 $.token test一下就可以了
把这个值复制给一个变量，以后所有的接口都可以使用这个变量了，token共享了，关联接口，其他接口都需要这个令牌直接使用这个变量，参数化来做，
用的时候把变量放到头里面，这样就行了
后续响应数据是json的不要用正则，$.token 这个更简单，错不了，很清晰（json提取器）
后续接口需要用到这个接口的token的，关联技术，获取token复制给变量就可以使用了，
增加一个后置处理器，json提取器
21：性能测试规范流程
场景提取
脚本开发
场景设计
场景执行
监控分析
调优
回归
22:jmeter主要元件的讲解
配置元件
监听器元件
其他常用元件
什么场景需要什么元件get到
23：配置元件 config
http请求默认值：
http消息头管理器：
http cookies管理器：
http cache管理器：缓存
一：请求默认值
1：保存一个测试计划：类似工程一样的东西，计划不要放在bin里面，千万谨记：如下保存，这是一个工程，保存完成之后是一个测试计划
2：有了测试计划后增加一个线程组，本身性能测试就是多组账户和用户的，并发数,线程数就代表用户数
本身jmeter是多线程的，Ld有个多线程模式
3:线程组增加好了之后增加一个请求叫 取样器，增加http请求
80：http默认端口
8080：tomcat默认端口
8888：一般是代理服务器用的端口号
443：https的默认端口
4:填写http接口请求信息：参数和消息体数据和文件上传三个是互锁的，只能填写一个
参数填写表单，消息体数据写json，xml，表单都可以
5：使用查看结果树查看结果是否成功
监听器就是查看结果的，通过查看结果树的响应查看结果
前期调试使用一个线程组，脚本正确再考虑并发，脚本通了才行
返回绿色的不代表成功，只是说明有返回，需要看请求和响应数据是不是正常
6:需要增加一个http——>配置元件——>http信息头管理器
这个元件是有作用域的，如果放在线程组下面会对线程组所有的请求都是共享的
如果只是单个接口是有拖到登录接口里面去，改变作用域
填写消息头是个表单形式
7：请求头还需添加cookie cookie是通过一个请求获取的，
登录接口第一次直接访问不得行的，需要前面加一个访问首页获取cookie的请求
访问首页接口可以获取cookie值。访问首页不需要头，可以删了
要注意顺序写：请求cookie接口在前面就写前面执行，登录接口就写在后面执行的
请求在前先执行的，请求在后后执行的，jmeter默认顺序从上至下依次运行的
访问首页放前面，获取到cookie值，然后cookie传到登录接口就可以了
接口需要带cookie，所有需要一个前置获取cookie的操作，把两个请求关联
可以把访问首页的sessionid值拿出来再组装，用正则表达式提取sessionid值组装到请求头里面
jmeter为了方便自己提供了cookie管理器，希望访问首页的cookie值能给登录接口来用
选择组里增加配置元件：http cookie管理器，放前面去 这样就不需要提取
这个管理器自己会帮忙管理cookie，自动关联的，这样请求就有cookie值了
利用好jmeter自带的元件，让测试变得更加便捷
一个项目很多接口，协议一样的，ip地址一样的，端口号一样的，测试环境
测试环境：
预生产环境：
生产环境：
性能测试这个ip地址是测试环境的ip地址，如果脚本想放到预生产环境测试，端口号和ip都需要修改 ----参数设置成默认的
8：http请求默认值，把我们的一些参数全部填上去就可以了
请求默认值：所有的线程组下面的请求都会利用默认值，以后增加的请求一些内容就不用写了，只要写请求方法和请求路径就可以了方便
所以以后项目环境改变了只要改http请求默认值就可以实现 整体修改：类似配置全局参数
9：http请求cache缓存，缓存用的不太多
浏览器有缓存的，项目改了东西，页面修改了一些东西，很多静态资源不是从服务器获取的，静态资源里拿，拿的是以往老版本的数据
所以需要清缓存，-----jmeter cache管理器也是做这个事情的
24：监听器元件
一：查看结果树
1：分析查看具体某一个请求的详情：请求头，请求体，响应头，响应体
2：性能场景的时候分析错误的请求的原因
分析某个请求的内容，
做高并发跑场景的时候几十个几万个请求：几万个请求查看结果树里面的信息会一直拼命的刷新
有错误率也一般找不到，正确一般不看，脚本通的，需要看一下为什么报错，勾选 仅错误日志
就可以了，这时候只显示错误的，成功不显示，不勾选这玩意根本看到错误率
勾选了正确不显示一个，一旦错误就有了
二：接口请求还能增加断言 使用响应断言
这是根据响应文本进行断言的，断言成功绿色，断言失败红色，如果查看结果勾选了 仅错误日志，就只会显示断言失败的
仅仅显示错误的，正常的不显示，几万个请求，跑一个场景半个小时，如果不仅错误日志这么设置，如果有错误率那么就看不到为什么错误了
只能看日志，可以查看为什么断言失败，都正确的一个都不显示，场景脚本都通的，不用看正确的，看错误是为什么发生的
三：聚合报告
汇总统计的结果：里面包含
请求数，响应时间（平均的，百分之90的，百分之95的，百分之99的，最大max，最小min）单位是ms毫秒
错误率：越低越好，
吞吐量：TPS 越高越好
发送/接收---带宽
上面就是聚合报告，两个请求的一些数据，
四：表格查看结果
请求什么时候发的什么时候结束的，中间间隔多少时间里面是有的，这个更细
表格查看结果如上：会显示请求什么时候发的，可能没有聚合报告那么细，但是带时间的，详情都会有，
五：图形结果
一般发一个请求查看图形界面没什么意义，发很多请求会由一个曲线图，每个线表示什么意思
如果请求失败了，想分析请求为什么失败用 察看结果树
如果想查询性能跑了半个小时想查询整体性能的概要，概述 聚合报告
如果想看整个场景，做了一些定制器，想看请求到底什么时候起的，怎么规划请求发送的 查看表格结果
整体效果看曲线图 图形结果
根据具体场景选择
25：其他常用的元件
断言不能放线程组里面去：jmeter很严格的作用域的问题，如果作用域放错了就全局gg，
断言放整个线程组里面会对整个线程组所有的请求都起效果，谨记相对哪个请求做断言，把断言拽到某个请求的里面去
作用域的问题，不能乱放
一：前置处理器 以请求作为分界线
请求发之前执行的控制器（元件） 比如：加密（md5），
如上:选择最后的Bean shell预处理程序，放在请求里面，这里面会顺序执行的，请求发之前处理，做一些加密
二：后置处理器
请求发之后得到响应执行的控制器（元件）比如：正则表达式，json表达式提取数据
三：定时器
1：固定定时器 slepp，思考时间 jmeter本身请求时间是没有延时的，发请求只会立马发，不等，实际工作人去操作项目会有延时
有等待，先等，等会再点，服务器不管你干嘛，只要是两个请求之间间隔一段时间就人为这是思考，休息时间
模拟用户习惯加一个思考时间（固定定时器）
2：同步定时器 集合点 很多商城，三折，五折，告诉你9点开始活动，用户聚集在这一块，这时候就是集合点，把人按照一定条件集合在一块
然后到底一定时间或者条件的时候把这个阻碍器拉掉，高并发过去同时访问----严格的并发（比如秒杀操作）
3：随机定时器 随机点 定时器的时间是随机的，
4：吞吐量定时器 分流的效果
项目中一些常用的元件
线程上的延时和集合点上的延时不一样： 线程上的延时指的是整个性能组启动前的延时，集合点是在性能里面的
线程组延迟多少时间启动 集合点：在整个线程组里面的对于请求而已的
26：jmeter参数化技术实战
参数化，数据驱动
一：什么时候需要参数化技术
某一个接口用一组参数去，
登录：单点，多点
单点：一个账户登录，这个账户再登前面的账户会被顶号 前面账户outline掉线，
这种接口做性能测试不能使用一个a账户，那么只有一个能成功，其他都会失败 ---一定需要参数化
很多接口里面，假如增加用户的接口，手机号码唯一的，每新增一个账号，这个接口手机号码必须唯一，这时候一组手机号码做性能测试不行
手机号码需要采取参数化技术，
多点：可以不做参时化，但是最好最一下模拟真实环境
二：参数化技术是什么
写好一个脚本跑通了，里面的数据不是写死的
参数化是自动化测试脚本的一种常用技巧
简单来说，参数化的一般用法就是将脚本中的某些输入使用参数来代替，在脚本运行时指定参数的取值范围和规则
比如下面获取token的接口，账号密码写死的，意味着如果并发100个用户，100个用户都是用这组数据
可以理解成常量的概念，写死的 采取参数化常量不能使用一个数据需要使用变量
三：参数化的流程：
1：先找出需要做参数化的数据
2：准备提供给参数化需要数据源
3：脚本里的常量——>变量(使用前面的数据源数据)
四：jmeter参数化方式
1：csv方式--需要配置元件的 config
使用场景：账号密码，
token有时效：1：固定使用一个月（固定时间），不管用不用到期就干掉
2：从不用的时候开始一计算段时间
一：找出需要参数化的数据 账号+密码
二：准备参数化需要数据源 数据账号密码要有效的，不要乱编写
三：数据源和脚本里面的常量替换成变量
jmeter和文件打交道需要一个元件配置——>添加——>配置元件——csv配置元件设置
作用域参数化只对一个请求有效放请求里面去
参数化对整个线程组有效放在线程组里面去
对整个测试计划放在测试计划下面
作用域很重要
文件名称（需要些路径），如果分布式多机，jmx脚本文件写成固定的g盘的某个目录，
脚本给别人用，不一定跑的起来，可能没g盘，有时候运行jmeter没有任何反应，很可能脚本问题，路径的问题可能出现这种场景
做项目的时候配置文件最好放在jmeter目录的bin文件，这样谁使用脚本就可以跑，
文件编码：utf8
变量名称：现在配置文件式两列的，csv式格式统层，数据中间用英文逗号,隔开，一列式username，二列password
忽略首行，csv文件可能首行式列名，不起作用这时候噶False改成True就行了，不存在列名，第一列就可以使用的使用False就可以
分隔符：英文逗号 ,
是否允许引号：False
遇到文件结束符再次循环：True
遇到文件停止符停止线程：False
线程共享模式：当前线程组，不对外有用 如下：
每个参数需要了解，现在把数据源文件通过jmeter元件数据导入进来，接下来需要把变量用起来，脚本里的常量——>变量
参数里面填写变量需要使用${}这样来写
如果想跑五个或者多个在线程组里面设置 :如下
线程数5，1s起一个就五个账号密码去请求
2：函数式 很多简单的不需要使用外置文件，
参数化数据可能不需要自己搞定：订单号，编码号，可以借助函数来搞定
随机数
time时间函数：时间戳，默认ms 13位数据
计数器counter
如上，把get_token获取的值提取出来给新增用户接口使用，否则新增不了课程，两个接口做关联，用关联关联起来
json表达式可以使用json语法提取 如下：
响应式一个json格式使用json表达式语法，不需要那么复杂，
把：Result[0]=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJKMjAxOTAzMDcwMDU4Iiwic3ViIjoiSjIwMTkwMzA3MDA
1OCIsImlhdCI6MTYxNjAwOTY0Mn0.luaI9-MA-DnLPIsR-8vdSOMH2X2vBrJ_tG5hZroItPQ
这个数据存储到变量里面去，这个变量给到新增接口的请求头就完成工作了 -----思路 使用后置处理器
前置后置对请求而言的，前置是请求前处理的，后置是请求发之后处理的，用后置处理器
$：根目录 .表示调用关系
现在添加一个debug调试器 如下：查看token的值
所以现在getToken变量是有值显示的 下面还显示账号密码 debug调试器相当于编码里面的debug模式
现在取值到getToken变量变量了需要和接口关联，放在下面的请求的消息头管理器里面
按照接口文档加上token头参数就能实现 如下
现在又出现客户必须为中文，新增用户接口里面参数有中文，需要加个内容编码utf-8
现在请求就没问题了 -----前期脚本调试的阶段，脚本的参数化和相互关联
问题解决
1："msg": "TOKEN值为空", 解决方案：请求头里增加一个token的
2："message": "客户姓名必须为中文??" 解决方案：设置请求编码为utf-8
3：该客户手机已经存在 解决方案：对手机号码必须参数化，
搞个csv文件没有必要，可以搞一些随机号和时间戳来，如下
打开函数助手，打开随机数函数，生成后复杂到请求里面就行
在这里之间符号替换就可以了，123+一个八位随机数
现在再请求新增用户就成功了 手机号码操作的时候需要符号后代校验 ---简单的编码类random
3：变量操作
内置变量
全局变量
测试环境好几个，沙箱，测试环境，预生产环境不一样 可以设置ip地址：
测试计划——>配置元件——>用户自定义变量 如下：
设置好了后就可以在每个请求使用$ 符号调用变量，使用ip地址，以后便于维护，修改用户自定义变量就行了
严格注意一下元件的作用域
脚本调试ok的化调试取样器后期可以禁用了，本身调试使用的，
4：编程式
一：引入外部的jar包，java class
二：使用beanshell编程
高级部分
一些数据不好生成采取编程方式，编程方式看开发提供什么格式，一般来说提供jar包比较多
开发写好一段加密的算法类的，数据的产生数据环境的东西都可以写在jar包里面的，jar包直接导入进来
会使用编程语言beanshell，beanshell和java很像，自定义变量
最牛皮的jmeter可以修改源代码，可以定制化里面的东西
27：jmeter关联技术
一：关联描述
二：关联的作用 对上一个请求做数据提取，两个请求的关联 关联的核心是提取数据
关联核心是提取
断言重点是对比
token：账号密码进行一个算法，生成一大串字符串
三：jmeter中的关联
请求之间数据的传递
jmeter使用正则表达式提取器提取响应中的特点内容
还有一些json提取器
四：正则表达式 .*?
（） 括起来的部分就是要提取的
. 匹配任意字符串
+ 一次或者多次
？ 放量词后面表示非贪婪模式，找到第一个匹配项后停止
正则表达式提取多个字符串，有几个就写几个
MYREF什么都不写表示提取的内容，写 g0表示全部，g1表示第一个，g2表示第二个
五：使用场景
第二个请求参数中需要加入第一个请求的返回值时
通过正则提取器可以提取第一个请求返回值中指定的字段信息并复制，在第二个
六：创建的时候是使用后置处理器
等请求完成之后再做提取
28：正则表达式提取器实战操作
