性能测试基础知识
目录
什么是性能测试？
什么是性能？
性能测试分类
基准测试
负载测试
稳定性测试
压力测试
负载测试和压力测试的区别：
并发测试
应用场景
性能测试指标
响应时间
并发用户数
吞吐量
性能计数器
思考时间
性能测试步骤
1.性能测试需求分析
2.性能测试计划和方案
3.性能测试用例
4.性能测试执行
5.结果分析与调优
6.测试报告总结
什么是性能测试？
性能测试是通过自动化的测试工具，模拟不同场景【正常、峰值以及异常负载条件】，对软件的各项性能指标进行测试和评估的过程。
系统的性能是一个很大的概念，对一个软件系统而言包括执行效率、资源占用率、稳定性、安全性、兼容性、可扩展性、可靠性等等。
性能测试主要用来保证产品上线或发布后系统的性能满足用户需求，性能测试在软件质量保证中起重要作用。
什么是性能？
性能：就是软件质量属性中的“效率”特性。
效率特性又包含时间特性和资源特性；
- 时间特性：表示系统处理用户请求的响应时间；
- 资源特性：表示系统运行过程中，系统资源的消耗情况；资源包括：CPU、磁盘、内存等。
性能测试分类
基准测试
基准测试：
狭义上讲，就是单用户测试。测试环境确定后，对业务模型中的主要业务做单独的测试，获取单用户运行时的各项性能指标。
广义上讲：是一种测量和评估软件性能指标的活动。可以在某个时刻通过基准测试建立一个已知的性能基准线，当系统的软件或硬件环境发生变化之后再进行一次基准测试以确定变化对性能的影响。
基准测试的用途：为系统/环境配置，系统优化前后的性能提升或下降提供参考指标。
负载测试
负载测试：是一种性能测试，指通过逐步增加系统负载，确定在满足系统的性能指标情况下，找出系统所能够承受的最大负载量。
例子：登录接口，我们先10个用户访问，然后100个用户访问，再然后1000个用户访问，关注程序的响应时间，所耗资源，直到超时或关键资源耗尽
稳定性测试
稳定性测试：在服务器稳定运行（用户正常的业务负载下）的情况下，进行长时间测试（1天—1周等），并最终保证服务器能满足线上业务需求。
【注意：系统在用户要求的业务负载下运行达到规定的时间时，系统才能正式上线使用。】
压力测试
压力测试:在强负载下的测试，查看系统在峰值情况下，是否功能隐患、系统是否具有良好的容错能力和可恢复能力。
压力测试是一种高负载下的负载测试，也就是说被测系统处于一个负载的情况，再继续对他进行加压，形成双重负载，直到系统崩溃，并关注崩溃后系统的恢复能力，再加压的一个过程，看看系统到底是否已经被彻底破坏掉了。
压力测试分为破坏性测试和稳定性测试。
负载测试和压力测试的区别：
负载测试是不关注稳定性的，压力测试是关注稳定性的。
并发测试
并发测试（绝对并发）：是指在极短的时间内，发送大量请求，来验证服务器对并发的处理能力。
相对并发：指在一个时间段内发生的事情。
绝对并发：指在同一时刻发生的事情。
负载测试是一种相对并发；并不会同时对服务器产生压力，真正的同时是绝对并发。
应用场景
特定活动场景：秒杀、抢红包、抢购等类似的活动。
性能测试指标
响应时间
响应时间：指用户从客户端发送一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。
响应时间是用户感知软件性能的主要指标
响应时间包括：
用户客户端响应时间
请求/响应数据网络传输时间
应用服务器处理时间
数据库系统处理时间
注意：
- 通过HTTP接口请求消息来测试
- 不包括 发消息时前端页面的处理时间 和 收到消息后前端页面的渲染显示时间
那么响应时间为多少合理呢？
对于一个Web系统，普遍接受的响应时间标准为2/5/8秒
2秒钟之内响应客户是非常好的
5秒内响应时间是可以接受的
8秒是客户能接受的响应时间上限
当我们在客户端发出请求时，在传输过程中会有损耗，所以不存在真正意义上的并发。在测试中添加集合点，也不能解决并发问题，集合点只是在客户端模拟并发，到达服务器的时间已经不是并发
并发用户数
并发用户数：某一时刻同时向服务器发送请求的用户数。
用户数的概念：
系统用户数：软件系统注册的用户总数 ，即数据库用户表的数据条数，对性能无影响。
例如：淘宝商城，注册用户有5亿。
（做系统性能环境时，需要初始化环境，注册的用户数据储存在磁盘，主要跟磁盘有关系。）
在线用户数：某段时间内访问过系统的用户数，这些用户只是在线，但是不一定同时向系统提交请求。
例如：当前登录了淘宝商城的用户数为2000万。
并发用户数：某段时间内同时向系统提交请求的用户数。场景不一定是同一个 。
例如：双十一做秒杀 、查询、付款等，有行为相同的并发，也有行为不同的并发。
并发：用于从业务角度模拟真实用户访问，同时访问
并发数：同时访问系统的用户数
在C/S或B/S结构的应用，系统的性能主要由服务器决定。服务器在大量用户同时访问时，压力最大。 并发用户数是可以通过公式计算而来
吞吐量
吞吐量:指的是单位时间内处理的客户端请求数量,直接体现软件系统的性能承载能力。
从业务角度看：吞吐量可以用：请求数/秒，页面/秒 ，人数/天 或 处理业务数/小时等单位来衡量；
从网络角度看：吞吐量可以用 ：字节/s来衡量
对于交互式应用来说 ：吞吐量指标反映的是服务器承受的压力，能够说明系统的负载能力。
TPS： 每秒事务数 -> 吞吐率
即控制服务器每秒处理的事务请求的数量。
事务：即业务，页面上的一次操作，可能对应一个请求或多个请求。
QPS:每秒查询数，即控制服务器每秒处理的指定请求的数量。
TPS和QPS有什么关系？
当一个事务对应一个请求时：TPS=QPS
当一个事务对应n个请求时：QPS=n * TPS
性能计数器
描述服务器或操作系统性能的一些数据指标 ，内存，CPU磁盘等资源使用率
在性能测试中重要的一部分就是监控测试执行过程中服务器的性能参数，大型商业测试工具：BM RPT,HP Load Runner已经提供完善的功能可以直接从服务器上记录保存数据。
在windows中微软提供一个小工具Performance Counter(性能计数器)
思考时间
消息和消息之间发送的间隔时间
从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔
在做性能测试时，为模拟这样的时间间隔，引入了思考时间这个概念更加真实的模拟用户的操作。
引入思考时间的原因：
-
业务需求。比如不能连续发帖，为了防止灌水现象的发生。
-
更加真实的模拟用户操作行为。在现实环境中，用户在操作的时候，不可能实现没有间隔的连续操作，通常输入用户名，登录密码或者选择查询条件等的操作中是需要有停顿时间输入或者选择。此时加入一些思考时间更接近真实场景，思考时间可以是固定的，也可以是某一范围内的随机值
思考时间对性能测试的结果不会有本质意义的影响，不会因为添加思考时间后，系统该有的那些瓶颈就不会暴露。
性能测试步骤
性能测试主要有以下6个步骤：
1.性能测试需求分析
主要分析以下4个方面：
- 明确被测系统（熟悉被测系统的业务功能和技术架构）
- 明确测试内容
- 明确测试策略
- 明确测试指标
2.性能测试计划和方案
主要思考以下三点：
（1）测什么
- 项目背景
- 测试目的
- 测试范围
（2）谁来测
- 考虑进度与分工
- 交付清单
（3）怎么测
- 测试策略
3.性能测试用例
设计测试用例
4.性能测试执行
主要包含以下几点：
（1）建立测试环境
搭建性能测试环境，包括硬件环境、软件环境、网络环境
（2）编写测试脚本
按照性能测试用例的需要，使用性能工具编写测试脚本
（3）性能测试监控
在脚本执行前，配置各项性能的监控指标。
如：响应时间、TPS等。
（4）执行测试脚本
设置性能运行场景，执行性能测试，并同步收集各项性能指标。
提示：执行性能测试脚本前，保证脚本都调试通过。
5.结果分析与调优
性能测试分析人员经过对结果的分析以后，如果不符合性能需求，则会提出性能bug，然后由开发人员进行后续的调优。
注意：
性能测试的必要条件：性能测试服务器的配置尽可能要和生产服务器配置相近（即测试环境要和实际环境相近）
6.测试报告总结
测试报告是对性能测试工作的总结，为软件后续验收和交付打下基础。
