性能测试如何看测试报告
概念
性能测试
- 性能测试是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。评估当前系统当前的能力，寻找瓶颈，优化性能
- 性能测试是一种“正常”测试，主要测试使用时系统是否满足要求，同时可能为了保留系统的扩展空间而进行的一些稍稍超过“正常”范围的测试（比如：当前系统使用用户100人，可能未来人数会增多到300人，所以要让系统能够在300人情况下正常运行，可以理解为需求）
负载测试
- 是通过逐步增加系统负载，测试系统性能的变化，并在满足最终确定性能指标的情况下，系统所能承受的最大负载量的测试
- 性能指标：是系统应该满足的，比如请求响应时间，错误率等
- 负载测试是正常范围的测试
压力测试
- 逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试
并发测试
- 指多用户在同一时刻，共同执行某一操作；并发测试要求比较严格，着重考察系统的瞬间压力
压力测试与负载测试区别
- 相同点：都是性能测试
- 负载测试强调系统正常工作情况下的性能指标
- 压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点。
- 举例：工人建桥，桥身上表明，该桥的最大负重量为60吨。—负载测试
- 该桥的内部建筑资料中，表明该桥的最大载重量为70吨。这个数据是给内部建桥工程师掌握的。—压力测试
不要拘泥于概念，做性能，还是看你想要达到什么样的目的，至于过程你可能涉及多种方法，没必要非得区分严格的测试类型在做。
步骤
第一步 明确目标
做此次性能测试的目的是什么？业务需求？技术选型？硬件服务器选型？ （基本做的全是业务需求）
-
业务需求，业务指标，常见的，测试系统的核心事务相应时间是否满足用户的需求，测试系统的最大并发用户数，测试系统的最大业务吞吐量，测试系统的稳定性和健壮性（比如：抢购秒杀支持多少并发，测一下咱们现在服务器能支持的业务情况？或者，错误率是0%情况下的压力情况，或者并发情况，响应时间不超过2s等）
-
技术选型，语言、架构、框架、中间件（基于性能指标去选择技术） 服务器（Nginx、apache、tomcat）、数据库
-
硬件服务器选型，对机器的硬件配置要求，商业的服务器，增加一点点配置，成本比较高
第二步 设计&执行（如：测试一下名医下单流程的能力）
1.搭建环境，硬件配置，软件配置，各项指标，线上线下的配置差异
2.制定测试策略
- 人力资源（多少人，需要哪些人配合，开发，运维，测试、需要多少机器，什么配置，什么时间执行等）
- 测试方案的制定（如：编写下单业务测试脚本。二分法找中间范围值。设置对服务器的性能监视，作业一段时间后，查看各性能批标。找到性能峰值。多次测试取平均值，增加数据可靠性。记录测试报告。分析图表、聚合报告、cpu折线图。得出结论、使用拒工具jmeter，进行分布式测试）
3.测试场景的设计（模拟真实业务）
- 设计合理的场景 如下单 （登录、首页、黄页（可能不止一个接口）、时间选择页、下单、支付、查看）。 登录一次性的，一次性控制器， 多个请求是无序的，随机控制器，有重复操作时，加循环控制器， 等待时间（思考时间）用户每个操作之间是有等待时间的，加随机定时器等等，设计成一个事务（事务控制器）jmeter整理.doc
- 参数化，1.保证数据的真实性，2.数据库本身提供个缓存机制（有开关控制），可以对数据表建立的高速缓存。数据库的数据临时保存在一个位置上，再次同样的请求直接把这个数据返回去，而不需要再次去查询各种表取数据了
-
加压方式，设置用户数阶梯在自适应时间，启动完成。平均每秒增加自适应线程个数
- 数据库准备，数据库中不可以为空或者条数很少，这种情况下测试不符合实际的生产情况。一定要根据系统实际的在线情况，插入足够数据（背景数据）后再进行测试
4.用例编写&数据准备&环境准备
- 查看，服务器是否有屏蔽压力的机制，比如同一用户，禁止多次操作，同一ip限制，同一用户限制，查询同一条目的缓存限制。
- 【技术】Jmeter进行压力测试 里面有具体的操作
5.用例的执行
- 根据场景设计去执行，多次执行取平均值，增加数据可靠性
- 阶梯式增加负载，记录每次的执行情况
第三步 分析执行结果得出结论
（通过测试报告进行一步一步的分析）
名词解释
TPS图表：系统处理业务随时间变化折线图。（它是衡量系统处理能力的重要指标。TPS是重要的性能参数指标）
点击率图表：客户端每秒向服务器发送的请求数随时间变化折线图。
吞吐量图表：传输数据量随时间变化折线图。（对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力。）
平均响应时间：测试线程向被测系统发请求，所有请求的响应时间的平均值。
处理能力：在某一特定环境下，系统处理请求的速度
错误率：出错业务或请求的百分比
cpu： 查看性能测试的过程中CPU资源的占用率，反映系统处理能力以及应用是否稳定
I/O：磁盘的使用情况，度量磁盘读写性能
内存：查看内存使用情况
负载量&处理能力的的关系图：横坐标负载量， 纵坐标处理能力
扩展内容
影响性能的点
1.通过刚才查看报告，tps的指标，聚合报告的分析，“计算运费接口错误率高” 这个接口是个瓶颈，这个说法，是否一定准确？是不是有些武断？
- 当加压的量上来了，服务器已经有了压力，请求是排队的，“计算运费接口” 错误率上升，也有可能已经有请求积压了，导致这些“计算运费接口”接口 直接超时失败，而根们没有处理这些接口逻辑
- 确定那个接口的性能有问题，可以做单接口压力， 也可以那mock掉其他的接口
2.出现瓶颈一定是代码问题吗？
- 性能测试关注的点，有两个 1.响应时间，2.资源（cpu、内存、磁盘）
- 响应时间=客户端时间+网络时间（传输时间）+服务器时间，由此可以看出，还和网络有关，实际的项目测试过程中，经常将被测系统部署到内网环境，这样有充足的带宽，即可规避网络的瓶颈。（因为网络是不可控的，是运营商提供的，不可控的，注意测的是系统，而不是网络，若系统测试，最终测出是网络问题，也是无法解决的）
-
服务器时间，从发出请求到接收响应，整个的时间，基本经历下图整个流程，那么每一块都有可能影响响应时间，那么每个模块都是要关注的，都有可能是一个瓶颈
-
服务器，tomcat、Nginx、apache、等
-
是不是本身服务能够支持的量级已经不行了？ （上百万）
-
负载均衡策略是不是没有做好（轮询、权重、ip分配）.……资源不够请求排队了
- 2.服务器本身没有问题，配置出了问题，配置调优，比如，连接池的配置，当然还有很多配置
-
-
- 数据库服务器，Oracle、MySQL、MariaDB、SQL Server等
- 数据库服务器本身已经不能支持那么大的量级了
- 服务器本身没有问题，配置出了问题，如 连接池的配置 或者其他
- 网站框架，就是开发写的代码（也包括框架的springBoot等）
- 代码的逻辑设计是否合理（频繁调用数据库，或者写的质量不行）
- 是否存在慢sql
- 编程语言选择的问题
- ……
- 系统架构的问题
- 是否系统架构有能优化的地方，或者存在不合理的地方
- 硬件服务器的资源
3.影响系统性能的几个主要因素
- 硬件：CPU、内存、硬盘、网卡以及其他网络设备
- 操作系统
- 网络
- 中间件（也叫应用服务器，如Jboss、websphere、weblogic等）
- 数据服务器
- 客户端
- 编程语言、程序实现方式、算法
常见的性能调优
- 部署建议， 中间件的部署，负载策略等
- 扩容，链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快，这一类需要横向扩展资源。
- 应用逻辑优化，比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。
- 超时时间的合理设置，对于应用之间的rpc调用或者应用与其他基础组件之间的调用，均需要设置合理的超时时间，否则过长的等待将造成整个链路的故障。
- 缓存的应用，请求尽可能从前端返回，而不是每一个都要让后端应用处理后再返回，减轻后端应用及数据库压力，提高系统吞吐能力。
- 限流，对于超出承载能力的QPS或并发，可以进行拦截并直接返回提示页面。
- 降级，对于非核心链路上的应用，允许故障关闭而不影响核心链路
- 扩容和优化也是有限度的，在评估容量内，保障核心交易链路正常是重中之重，对于非核心功能模块考虑降级场景
系统架构图（很多种）
负载量&处理能力的的关系图：横坐标负载量， 纵坐标处理能力