性能测试的理论知识

1、为什么要做性能测试？

1）目前绝大多数应用都是基于网络的分布式应用，我们无法知道用户数量，用户场景的不确定性，导致系统测试时，不仅仅是功能，业务逻辑，接口测试，还要测试系统性能。一个用户没问题，但是用户一旦多了就可能出现各种各样的问题，所以需要进行系统性能测试。
2）用户数量增加，系统负载增加，进行系统性能测试，知道系统承受的并发用户数量，带宽是否够用，cpu是否够用，内存是否够用，硬盘速度是否跟得上。从服务端来看，测试服务器是否能承载用户多并发，系统是否稳定，从用户角度看响应时间速度。

2、性能测试内容

1）负载测试（load test）：对于分布式网络，测试不同用户数量来测试系统的反应，主要关注性能指标，系统不同表现。
负载测试：通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
如实际中我们说从比较小的负载开始，逐渐增加模拟用户的数量， 直到应用程序响应时间超时，就是说的负载测试。
通过逐步增加并发用户数向服务器发送请求，看服务器性能瓶颈区间，每个并发用户，每秒钟的请求数量是各不相同的）
（负载测试是测试软件本身最大所能承受的性能测试；）
2）压力测试（stress testing）：高压状态下多用户高并发测试，主要关注系统是怎么崩溃的。（内存泄漏，cpu无响应，数据库无反应，网络堵塞）
压力测试：压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在
（压力测试就是一种破坏性的性能测试；）
用一定量的并发用户数，持续比较长的时间，向服务器发送请求，看服务器的稳定性
3）容量测试（volumn testing）：系统最大支撑的相关数量，数据库最大数据数量，用户数量。
容量测试 容量测试是指测试系统最大的支持用户数量。比如一个web系统，容量测试就是测试系统最大能支持多少个用户登录系统完成正常的操作而不会出现问题。

3、性能测试评价指标

1） 响应时间（RT）（response time）
从发起请求到请求响应的时间
发送请求网络传输时间+服务器处理时间+返回响应网络传输时间
2）吞吐量/率TPS（transactions per second）:服务器每秒处理事务数，衡量服务器处理能力的最主要指标（吞吐量）
硬盘IO（读写），网络IO（上行下行带宽），cpuIO，服务器处理能力，客户端打开页面的数量。
3）事务处理能力（TPS tansaction per second)：打开页面，登陆服务器，实现消息发送等等用户的某一动作就被称为事物。
指一个客户机向服务器发送请求然后服务器做出反应的过程

并发
侠义：指同一时间点执行相同的操作（秒杀）
**并发用户数（**重要指标）
同一时间，执行相同请求的用户数
系统用户数、在线用户数、线程数
500ms和1500ms，接口响应时间，小于500ms比较好的， 500ms~1500ms是可以接受的， 大于1500ms是不能接受
TPS、QPS、RPS、HPS的区别
TPS （transaction per second ）服务器每秒处理事务数，衡量服务器指标的最主要参数
QPS(queries per second) 每秒查询率
RPS（request per second）每秒请求数
HPS（hit per second）每秒点击数
差异 ：一个transaction可能有多个queries，如访问网页
TPS>服务器 服务器处理能力 响应时间小，tps可以增大
QPS> 并发用户 并发用户发起查询， 接口查询多+人多 qps可以增大
RPS >并发用户 并发用户发起请求 人多，rps可以增大

4、性能测试关注点（也是软件测试的关注点）

1、软件测试的作用和价值：两个方面产品和用户。产品角度：在研发过程中尽早的发现问题，提高软件质量，确保产品交互，功能完善，稳定可靠。用户角度：关注用户体验，操作，界面，性能，尽可能想办法提升用户体验，持续改善。

2、性能测试的关注点：（三层架构，多方面制约，采用集群，云计算，虚拟化）

响应时间快慢，服务器端的处理速度
服务器端的使用情况
数据库端的资源使用情况
最大用户访问数量
同时处理最大业务数量
考察系统能否支撑7x24小时运转
内存资源、线程资源能否正常回收
代码，算法，sql语句设计是否合理
整个系统的稳定性，可恢复性

企业关注那些性能

关注点	性能
服务器利用率	资源利用率
能支持的最大用户	系统容量
能支持的最大并发用户	并发用户数
是不是可以更换硬件提高性能	可扩展性
能不能持续运行长时间不宕机	稳定性

开发人员关注那些性能？

关注点	性能
架构设计是否合理	系统架构
数据库设计	数据库
代码逻辑	代码
线程、异步、同步、队列	实现技术
资源配置	稳定性

5、感悟

性能测试的理解：
通过工具找出或获取系统在不同工况下的性能指标
通过接口实现，后端服务器的性能测试。
找出系统指标值出来，
可参考的指标值， 找出，基准测试，
可比的参照物，
第一次做性能测试，第二次做性能测试，有了参照物（第一次得到的指标值）
并发用户数变大 ：性能会变好
性能测试，需要多个指标来评定，不能单看某个值。
TPS服务器每秒处理的事务数变大=性能变好
接口响应时间变大性能变差
服务器资源利用率变大=性能变差
性能测试++=输出结果==性能指标值（数值）
中小微企业，变差，查原因，性能分析与调优，
性能测试：多用户、并发、猜用户数不靠谱，看日活，（日活动量）
有什么办法，让并发用户数，按照一定的规律去递增，（负载测试）

稳定性测试（低并发测试和高并发测试）
压测：是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，是通过搭建与实际环境相似的测试环境，通过测试程序在同一时间内或某一段时间内，向系统发送预期数量的交易请求、测试系统在不同压力情况下的效率状况，以及系统可以承受的压力情况。

然后做针对性的测试与分析，找到影响系统性能的瓶颈，评估系统在实际使用环境下的效率情况，评价系统性能以及判断是否需要对应用系统进行优化处理或结构调整，并对系统资源进行优化

并发数
　　并发数是指在同一个时间点，同时请求服务的客户数量。

比如大家常说的：『 我的网站可以承受一万并发。 』在通常情况下指的是：如果同时有一万名用户访问网站，所有人都可以正常获得服务。而不会有超时或连接拒绝情况发生。

吞吐率
　　吞吐率指的是服务处理请求的效率，计算方式为 （ 总处理请求数 / 总耗时 ）。

HTTP 服务的吞吐率通常以 RPS（Requests Per Second 请求数每秒）作为单位。吞吐量越高，代表服务处理效率就越高。换句话说就是网站的性能越高。

注意：吞吐率和并发数是两个完全独立的概念。拿银行柜台来举个例子，并发数指同时有多少人往银行柜台涌来。吞吐率则指银行柜台在一段时间内可以服务多少个人。

但是在性能测试中，二者之间通常会呈现出一种关联关系。当并发数增大时，吞吐率通常也会随之上升（ 多用户发挥出并行处理优势） 。但在并发数超过某个边界值后，吞吐率则会下降 （用户过多，花在上下文切换的开销急剧增大，又或者内存消耗过多）。

响应时间
　　响应时间指的是用户从发出请求到接收完响应之间的总耗时，它由网络传输耗时、服务处理耗时等多个部分组成。通常以毫秒（ms）作为单位。

与并发数的关系：一般来说，随着并发数增大，单个用户的响应时间通常会随之增加。这很好理解，餐馆吃饭的人越多，单个顾客等待的时间就越长。

与吞吐率的关系：更高的吞吐率通常意味着更低的响应时间。因为吞吐率是以 单位时间 内的请求处理能力来计算的。

平均响应时间与百分位响应时间
　　平均响应时间指的是所有请求平均花费的时间，如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms。那么平均响应时间为 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。

百分位数（ Percentile - Wikipedia ）是一个统计学名词。以响应时间为例， 99% 的百分位响应时间 ，指的是 99% 的请求响应时间，都处在这个值以下。

拿上面的响应时间来说，其整体平均响应时间虽然为 2.98ms，但 99% 的百分位响应时间却是 100ms。

相对于平均响应时间来说，百分位响应时间通常更能反映服务的整体效率。现实世界中用的较多的是 98% 的百分位响应时间，比如 GitHub System Status 中就有一条 98TH PERC. WEB RESPONSE TIME 曲线。
平均响应时间： 所有请求的平均响应时间，取的平均值
95%percentile ： 统计学术语，如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为：一组n个观测值按数值大小排列。如，处于p%位置的值称第p百分位数。

例如有100个请求， 每个请求的响应时间分别是 1-100 平均分布
平均响应时间： 1-100 的平均值，即 50.5
95% percentile ： 按从小到大排序，累计第95百分位，也就是 95 （即样本里95% 的数据都不高于这个值）