1.基本目的：验证是否达到用户的性能指标；发现软件中存在的性能瓶颈和优化
2.评估系统的能力：帮助做出决策，为后续性能优化提供数据
3.识别体系中的弱点，修复体系的瓶颈或薄弱的地方
4.系统调优：重复运行测试，验证调整系统的活动是否得到了预期的结果；改进性能。如：长时间的测试执行可导致内存泄漏。
5.验证稳定性：在一定的生产负荷下执行测试一定的时间评估系统稳定性和可靠性是否满足要求。
总括：
1，评估当前系统的性能情况
2，找出系统存在的性能瓶颈，并调优
3，预估未来的业务，看系统性能是否能满足需求
作用：多快好省
性能测试主要针对哪些方面测试：
1）后端代码的性能
2）应用服务器，数据库服务器，系统架构是否存在瓶颈
3）服务器资源的消耗
注意：
没有经过初始化的性能环境=没有作用的环境。
1.静态：网络带宽瓶颈、缓存多
2.动态：进程多、消耗内存多、磁盘IO频繁
3.动静结合：DB压力大、存储压力大、内存压力大、CPU压力大
性能测试关键指标:
1.资源指标：CPU（上限不超过85%）、内存、IO、带宽
2.系统指标：并发用户数、响应时间、事务成功率、超时错误率
用户操作一个请求得到响应的时间。
包含：
1、用户客户端呈现时间
2、请求/响应数据网络传输时间
3、应用服务器处理时间
4、数据库系统处理时间
一个系统普遍能接受的标准时间2/5/8s
含义：大量用户在同一个时间访问同一个业务
广义并发------不一定是同一个请求；例如双十一抢购。
严格并发----同一个请求
c:平均并发用户数
并发用户数=c+3*根号c
在线用户数，对系统的内存影响最大。（用户登录产生session）
单位时间内系统处理用户的请求数。吞吐量可以反映服务器承受的压力。
计算公式：F=VU*R/T
F：吞吐量，VU虚拟用户个数，R每个虚拟用户发出的请求数，T性能测试所用的时间
TPS：每秒事务数，即吞吐率.单位时间内处理的用户请求数
QPS：每秒查询数，服务器每秒处理指定请求数
操作之间的时间间隔，主要为了更真实的模拟用户的操作。
CPU,内存，磁盘使用情况 ：
一般cpu使用率不超过80%；
内存不高于80%；
磁盘不高于90%；
网络带宽不超过80%
负载测试：着重于用户规则和需求
关注软件系统极限负载的性能
着重于软件本身。识别系统的弱点和在极限负载下程序结果如何运行。规划能力，预估系统的使用情况。 期望： 面临压力时能够保证稳定，速度可以变慢，但是系统不能奔溃。
1.测试系统在一定的负载下长时间运行后是否会发生问题。
2.系统需要时间积累到一定量的程度。
3.一般是程序占资源却不能及时释放而引起的。比如内存泄漏。
4.客户端和服务器连接通路，不能有效的及时释放。
验证系统的并发处理能力
验收性能测试：模拟用户环境，测试系统是否满足要求。
特点：确定用户的环境；用户要求的性能指标；执行，分析结果；验收性质；一定要有客观性的结果。
分析如何开展验收测试：
1.性能测试需求分析：向客户了解用户数；高频/ 常用的功能，场景；运行情况时间（考虑并发时间段30分钟，2h，7*24小时；防火墙，负载均衡器都要长时间测试）。
2.了解软硬件情况。
相当于迭代版本对之前版本的功能测试。新增一个模块，判断模块对系统性能的影响。
对被测系统的软硬件环境测试进行调整，了解对系统性能影响程度，找到系统各项资源最优分配原则。
系统局部发生问题，是否能继续使用系统；该问题对用户影响的严重程度；能否快速地从错误状态恢复到正常状态。
1.性能需求分析：做性能测试条件；项目的熟悉；明确性能测试范围；性能测试指标；初步性能测试策略。
2.测试计划：怎么安排：时间（测试项目的开始结束；各环节的时间安排）；人员；使用的工具（并发工具，监控工具，分析工具，辅助工具）；场景模型（软硬件环境，网络环境）；方法。
3.性能测试设计：测试环境；场景设计；测试用例；脚本开发（录制，自己编写）；测试数据。
4.测试执行（执行脚本，记录数据，通过工具执行场景）。
5.测试分析与报告：性能分析（系统框架分析，指标分析，性能问题分析）；性能总结报告（测试环境，性能策略人员分配，场景描述，指标对比，问题描述，结果与原因，优化方案等）。
环境：http://47.96.181.17:9090/
1.熟悉被测系统
2.明确性能测试内容
3.明确性能测试策略----负载？压力？稳定性？并发
4.明确性能测试的指标
1）需求无明确指标-------通过查找相关资料，和类似的系统对比（竞品分析），跟客户沟通，以及对未来流量的预估
2）有明确需求指标----------下订单并发用户2个；平均响应时间小于3s;cpu使用率小于85%
有明确的指标根据分析结果和预期指标做对比即可。
1.项目背景
2.测试目标
3.人员安排
4.时间进度安排
5.性能测试环境（系统架构，软硬件配置，测试数据）
6.性能测试工具，监控工具
7.测试策略
8.风险控制
环境搭建：
根据测试用例的场景展现出来
提示：
1）虚拟用户数量及启动虚拟用户方式；
2）场景相关设置，如集合点；
3）脚本是否存在依赖关系（登录和注册）
运行脚本：
注意：
1）负载的测试机不能运行设定的虚拟用户数
2）没有“预热”过程 （本地多次测试可能会有缓存，需要注意）
3）没有模拟用户的真实环境
4）性能用例运行次数过少
性能测试分析人员经过对结果的分析对比，提出系统存在性能瓶颈
提示：
1）调优人员对系统进行调整
2）验证性能测试人员继续第二轮，第三轮…的测试。 到最终系统的性能是否有达标为止。
注意：
系统调优由易到难的顺序：
1）硬件问题
2）网络问题
3）应用服务器，数据库等配置问题
4）源代码，数据库脚本问题
5）系统架构问题
1）对整体性能测试阶段的回顾（覆盖需求，测试不同阶段的进度和产物、性能测试结果的分析，问题的解决）--------技术角度
2）对整体性能测试阶段风险的管理------管理角度
3）对项目性能测试结果的总结—通过与否，经验教训
Loadrunner特点：
1）工业化性能测试根据，能支持大量用户，提供详细的报表来提供测试分析的数据
2）支持协议多
3）使用c语言写的
优点：支持用户量大；提供精确报表；支持IP欺骗
缺点：收费高，体积大，不支持定制功能
jmeter 特点：
1、多线程框架-支持多并发操作
2、同于对服务器模拟负载
3、支持web、数据库、ftp服务器系统的性能测试
4、开源、纯java,可二次定制开发
jmeter是用java开发的，优点：免费开源，可以二次开发；体积小；
缺点：不支持ip欺骗；分析和报表能力相对LR欠缺。
应用场景：
当测试机无法模拟用户需要的业务负载量时，需要更多测试机配合测试
原理：
分布式相关注意事项：
分布式配置：
查找：
remote_hosts=127.0.0.1
修改为：
remote_hosts=192.168.9.99:1099,192.168.9.130:1099
特别注意端口号
2，关闭RMI_SSL
运行：
更多多机协作问题，参见：http://t.zoukankan.com/AmilyWilly-p-6794998.html
将插件管理器放在：安装目录/lib/ext/
插件安装方式：
1、通过Plugins Manager安装插件
2、直接将需要的插件放在/lib/ext/下
注意：jmeter一定要重启！！！
插件管理器jar包下载路径：https://jmeter-plugins.org/wiki/PluginsManager/
1、安装插件：
PerfMon只是安装显示在Jmeter的，实际使用需要客户端安装JMeterPlugin-Standard和JMeterPlugin-Extras（需要搭配ServerAgent使用，serverAgent需要安装在服务器上）
2、配置
将 JMeterPlugins-Standard-1.3.1.zip 中 lib\ext 目录下的 JmeterPlugins-Standard.jar 文件都放到apache-jmeter-2.13\lib\ext目录中。
将 JMeterPlugins-Extras-1.3.1.zip 中 lib\ext 目录下的 JMeterPlugins-Extras.jar 文件放到apache-jmeter-2.13\lib\ext目录中。
下载地址：https://jmeter-plugins.org/downloads/old/
将 ServerAgent-2.2.1 放到要监控的服务器中，window中执行startAgent.bat，linux中执行startAgent.sh（须要有执行权限，chmod 775 startAgent.sh 然后再执行 ./startAgent.sh）.
3、执行脚本，监控数据。
先在线程组中添加监听器jp@gc-PerfMon Metrics Collector，在AddRow中添加要查看的资源。默认主机为localhost，端口为4444（Server-Agent的默认启动端口），监控项目选择。也可以修改主机为对应服务器ip便可（端口不占用状况下使用默认便可）
grafana跟serverAgent原理差不多，都是监听数据运行的情况。优点：比较详细，并且能实时监控查看数据。
CPU使用率：用户进程与系统进程消耗的CPU时间百分比长时间情况下，服务器的使用率不能超过85%
通过putty工具连接linux系统，远程操作。
47.96.181.17
问题分析：
响应时间>10s
排查：
1、查看原因，使用jmeter监控系统指标，cpu、内存、磁盘等
2、若cpu使用率达到90%，cpu就一定有问题嘛？
分析：看具体哪一个进程使用率高-----top指令
若不是测试软件系统占有率高----先kill掉；若是本身测试系统的问题—很可能是cpu瓶颈
4、验证，确定是否是cpu的瓶颈
a)部署感觉的 ，cpu配置高的系统环境
b)降低并发数，看看情况。
答：否，可能一开始就有开启其他的应用，导致cpu已经达到了80%导致。
http请求包括四个部分：请求行，请求头，空行，请求体（请求参数）
响应也包含四部分：状态行，响应头，空行，响应正文
get 方法：向服务器i请求静态资源
特点：
1.所有的请求内容在url中
2.明文传输，安全性差
3.访问速度快
4.浏览器历史纪录中有记录
post方法：向指定的资源提交数据进行处理
特点：
1.所有的参数封装在body中提交，安全性高
2.没有数据参数类型要求
3.速度较慢
4.浏览器中没有详细记录
正则表达式快速格式转换见：https://www.json.cn/
正在表达式：元字符+限定符
最常用的几个字符：
| 元字符 | 定义 |
|---|---|
| . | 任意单个字符 |
| \d | 任意单个数字 |
| [0-9] | 等价于0-9的数字 |
| [a-zA-Z] | 等价所有的大小写字母 |
| 限定符 | 定义 |
|---|---|
| + | 匹配至少大于1次 |
| ？ | 匹配0次或1次 |
| * | 匹配0次或多次 贪婪匹配 |
| {n,} | 匹配限定次数 |
可以通过“在线正则表达式”来测试表达式获取的值是否正确。
其他补充：
1、线程中添加http cookie管理器即可。
2、利用正则表达式+http 信息头处理：
a)先发一个登录请求，查看response heads的数据，会发现有cookie内容
b)在登录接口下添加正则表达式，提取cookies.。注意：该正则表达式需要在信息头中获取数据！
c)将提取到的数据通过http request 默认值设置在下一个请求中
d)添加一个Debug Sampler查看请求是否成功
1.一个测试计划中多个线程组会同时运行，可以通过测试计划中的独立运行线程组解决。也可以通过setup线程操作，例如：创建一个setup线程组，将登录请求放在里面，那么每次执行整个测试计划的时候，就会先执行该线程，后面如果有接口关联可以通过json提取获取。
简单的接口关联操作：
1.在需求提取数据的请求下-----增加提取器（正则 or json）
2.增加一个后置处理器------beanShell PostProcessor
将提取器的数据获取并设置为全局变量：${__setProperty(newtoken,${token},)} newtoken代表设置的新的全局变量名称，token表示提取器中设置的名称(最好通过函数助手设置，容易出错！！！)
3.在后面的线程组请求中添加一个header manager，获取全局变量---------newtoken
${__P(变量名)} 基本等同于 ${__property(变量名 )}
注意事项：
1、当添加了http请求默认值，单个请求也设置了值，会以单个请求设置的值为准。
2、不同的参数传递格式会导致报错，详细解析见：遇到的疑难问题
