一、Controller的基本工作原理：通过1、2、3设置来模拟用户的操作，收集出4的各种信息
二、场景设置一般步骤
- 1、新建场景（Controller）
- 2、添加脚本
- 3、设置Schedule（设置场景运行的策略，主要设置Globle Schedule 这一项）
4、添加压力机（可以指定多台windows或者linux压力机产生压力）
1）添加压力机方法：Scenario - Load Generators
2）添加的压力机于Controller所在机器在同一网段，把防火墙关了5、设置run time setting
1）以Controller中的选项为主6、运行观察
三、分析思路：
- 1、分析原则：由外到内，由表到里，层层深入。拆分问题，隔离问题（好比学习一样，把时
间段分成一片一片的，把零散时间灵活应用起来）。 - 2、 对于一个应用系统，性能开始出现了下降，最直观最直接的表象就是系统的响应时间，
如果响应时间变长，则系统响应时间就是分析性能的起点。 - 3、 任何一个复杂的系统都可以分为网络和服务器两部分。
- 4、 性能测试不是一蹴而就的，而是贯穿整个性能测试的流程。
- 5、 性能分析调优是一个不断推理不断验证的过程，不断试错，不断改正，打开自己的思维。
四、重点指标：
- 1、TPS（每秒通过事物数，直接反应服务器的处理能力，可理解为地铁进站口刷卡机）
- 2、平均事物响应时间（最直观的指标，可作为突破口）
- 3、每秒连接数（可初步判断是否需要调优连接数配置）
- 4、点击数（直接反应请求数、客户端、网络，点击数出现问题一般为脚本或者网络出现了问题）
五、分析思路模型：
1 、重点关注Transaction Summary （事物概要）模块
（1）平均响应时间：当标准差比较小的时候，选择事物的平均响应时间。
（2）90%响应时间：当标准差比较大的时候，去掉最高最低，取90%响应时间更有
分析价值。
*（3）Std：标准差比较小，则相对比较平稳，标准差比较大时，则表明浮动比较大
分析Web Tour中的Transaction Summary （事物概要），回想前面的内容，最直观的指标就是“平均响应时间”，可把它作为突破口
由图可以看出，check的平均响应时间是最大的，要相对的比较，可以把check作为分析的突破口。
其他事物可以不用分析，根据木桶原理，补最大的缺口。
2、HTTP Responses Summary（HTTP返回状态概要）
（1）HTTP Responses Summary主要统计服务器的返回状态
（2）由图可看出返回都是200的状态码，而且总数8789与Statistics Summary（标准概要）
中的值基本一致，说明大部分请求都是成功的。
** 注意：**
说非200的状态码不一定是错的，需要根据具体业务来分析，比如302、304状
态码也是很正常的，不会影响性能测试结果。但是返回500的状态码的话就是错误的，
说明服务器内部错误。
六、分析过程 重点、重点、、、
接触LR的分析过程：
1、首先来分析running Vusers这项，双击打开
分析：
首先要看坐标图，X轴代表时间，Y轴一般代表指标，这里就是代表模拟用户数。由图可以看出，模拟用户数慢慢增长，然后平稳一段时间，最后再慢慢下降，这是一个合理的过程。假如出现红线那样的坐标图，用户数急速下降，那么很可能就是服务器down掉了。
2、 Error statistics（错误描述统计）
分析：
能进行到这一步说明脚本运行是没问题的了（比如检查点不对这些因素就可以排除掉了）。
最后两行有Faied to connect server 明显可以看出是连接服务器失败了；有两行是timeout提示，这个出现的次数不多，可以不管。
如果要去掉的话可以在Controller中Run-time-Setting设置，把perferences中的HTTP-request connect timeout(sec)、HTTP-request receive timeout(sec)和Step download timeout(sec)的值调大一点。
前面两行初步判断可能是关联出了问题，关联抓不到，可能是服务器返回失败。
得出初步结论：
- （1）连接服务器失败，遭到服务器拒绝，可能是系统出现瓶颈无法及时处理请求
- （2）关联抓不到，可能是服务器返回失败
- （3）timeout提示一般可以不管，如果要去掉的话可以在Controller中Run-time-Setting设置
3 、Error per Second（每秒错误数）
- 每秒错误数图是对每秒出现的错误进行统计，数值越小越好。
- 2-7min过程中错误数明显增加，可以判断系统在这个时间段开始不稳定。
4、Average Transaction Response Time（平均事物响应时间）
每秒内事物执行所用的时间
由图可以看出，到3s后，事物的平均响应时间突然下降。在这里可以大胆地推测，是不是因为服务器非常好，处理事物的能力非常强，所以事物执行的时间很少。
但是联想到上面的每秒错误数的图，在一段时间内每秒错误数都是差不多平稳的，所以说服务器处理事物能力非常好这个结论经不起推敲。
也有可能是处理能力差或者出现大量的连接错误、服务器出现down机等，前面说到，任何一个复杂的系统都可以分为服务器和网络，所以说也有可能是网络的原因。
结论：
（1）服务器出现拒绝连接、出现大量错误或者是服务器down机了
（2）也有可能是网络连接的问题
5、 TPS（每秒通过事物数）
TPS是考查系统性能的一个重要指标，值越高，说明系统处理能力越强
可以看出来，整体的TPS不是很高，说明服务器处理能力有待提高，后续要把TPS提升
6 、Hits per Second（每秒点击数）
虚拟用户每秒向Web服务器提交的Http请求数
总体来看没有啥问题，还是可以。2-5min过程中出现了一些波动，每秒点击数是服务端侧的，
那就应该是脚本或者网络的问题，从前面的分析得知，脚本是没问题的，那就基本可以判断出现波动是因为网络问题导致的。
7、Connections per Second（每秒连接数）
每秒连接数就是每秒中打开的TCP/IP连接数，当连接数到达稳定的时候而事物响应时间增大时，
添加连接数可以使系统性能得到提高。好比一个池塘放水，多开几条沟水会放得越快。
每秒连接数统计新建的连接数和关闭的连接数，可以了解每秒对服务器产生连接的数量，
图中可以看出每秒连接数都是比较低的，可以适当增加连接数来提高系统性能。
七、性能测试流程
过程分析：
（1）性能需求点获取
- 根据客户的需求由客户方提出
- 根据历史数据分析
- 参考历史项目或者其他同行业的项目
- 业内通用规则
- 确实没有数据，那就根据自己来，然后一边分析
（2）测试点的提取，常放在客户常用的、重点的模块和功能上
- 用户常用功能，比如登录
- 数据流转向复杂或频繁的地方
- 发生频率高的地方，比如搜索，提交订单，下单结账。
- 关键程度高的（比如产品经理认为绝对不能出现问题的地方，登录、下单等）
- 资源占用非常严重的
- 关键的接口
（3）测试环境
- 最好能和线上保持一致
- 如果不能那就等比的放大或缩小
- 软件版本应该一致
（4）测试数据
- 铺底数据的准备：是空库还是有数据量。数据量的选择参考线上的数据量进行
等比的放大或缩小。 - 最好的数据来源于线上的真实数据，因为分布合理
- 如果涉及到保密的数据，注意数据的脱密处理
（5）测试过程
- 性能测试时一个需要不断改进的过程，每一次尽量做得更好，多做一点点以前
没想到的东西，然后不断积累总结，然后你会发现自己对性能测试有了更深的
理解
（6）响应时间预估
- 线上监控系统得知
- 业界统一参考标准：2 - 5 - 8
（7）TPS预估
系统的性能由TPS决定，跟并发用户数没有多大关系。系统最大的TPS是一定
的，就好比池塘里装的水是有限的。但是并发用户数不一定，可以通过减小思
考时间来增大并发用户数。- 新系统：没有历史数据参考，只能通过业务部门来评估
- 旧系统：最好通过日志分析来得出
对于上线的系统，可以选取高峰时刻，在五分钟或者十分钟内，某个交易的最
大值，按照单位时间内完成的笔数计算书TPS，即业务笔数/单位时间