性能测试理论

一、 性能测试理论

面试时，需要将思想与工具分开，熟悉性能测试思想，能够使用jmeter工具进行性能测试

1. 性能初印象

1.1 什么是软件性能

软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性

1.2 什么是性能测试

• 指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
• 再好的性能都是有瓶颈的，比如淘宝双十一

1.3 什么时候做性能测试

• 接口测试在最前面做，性能测试在最后面做。性能测试是基于所有的功能问题都修改完之后，正常测试流程都走完之后，只要保证性能没问题就可上线时，在上线前的两三天做性能测试。
• 性能无法放在前面测，性能一定是基于功能完好的情况下测试的。接口跑不通，业务都测不起来时是测不了性能的。性能测试场景要和用户实际使用场景相同。
• 敏捷测试开发模型，前期评审很重要，测试要评审测试用例，开发也会评审开发架构，所以不太会出现测性能时发现开发架构存在很大的问题这种情况，在前期可以避免掉。

2. 不同群体眼中的性能

2.1 用户（软件的使用者）眼中的视角

2.2 开发眼中的视角

2.3 系统管理员（运维）眼中的视角

3. 测试眼中的性能是什么样的

3.1 官方解释

测试人员通常是作为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的，考虑的东西也需要全面，包括用户、开发、管理员等各个视角的性能。

3.2 实际性能测试

实际测试人员是无法判断开发层面的问题的，比如架构、代码等问题，测试一般都是站在用户的角度去看问题，模拟多用户等实际使用场景，只要性能测试达标，即可测试通过，不达标，则判断是运维还是开发的问题。

3.3 性能测试标准制定

性能测试的标准一般由产品和项目经理共同制定，以产品为主。软件上线是给用户使用的，用户使用量到底有多少，用户使用习惯是什么，都是市场人员及产品经理要去统计分析的。

3.4 性能测试关注点

测试人员在做性能测试时除了要关注表面的现象，比如响应时间，也需要关注本质，比如用户看不到的服务器资源利用率，架构设计是否合理，代码是否合理等。

3.5 性能测试定位方法

如果测出问题，测试人员需要能够判断是开发的问题还是运维的问题，判断方法如下：

性能测试时同时监控物理资源，如果性能不达标时，发现服务器的CPU达到100%，或者内存特别高，带宽持满，则一定是运维问题。运维调试后CPU使用不要太高（不超过85%，最好是50%~70%左右），如果运维优化资源后，性能还是不达标，就是开发问题，需要开发进行优化。

3.6 在软件行业，运维所处的角色是什么

有普通运维和高级运维，各种系统问题、硬件问题、软件装不上、连公司内网这些杂活，一般会交给一个人去做。其他人最核心的任务就是维护所有线上的环境，线上环境一定是交由运维负责的，包括所有的版本要上线，开发要发新包，全部要过运维之手。资源配置，负载均衡，所有对外的，提供线上支持的，提供底层的这种服务器层面的（环境部署、环境搭建、项目发布），都是运维来做。

二、 性能测试的维度和类型

1. 基准测试（10%~20%）

概念：在给系统施加较低压力时，查看系统的运行状况并记录相关数据作为基础参考
假如要求只要100个人使用就能满足性能要求，则我们可以先用10到20个人测试一下。用10%~20%测出来会得到一组数据，可作为基准数据，当做后续测试的参考值。

2. 负载测试（找出系统瓶颈或性能最优点）

• 是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。
• 通常是耗时最久的，因为需要不断的往上增加，增加到安全临界值（寻找最佳性能点），而不是超载值。如果在增加过程中，突然出现性能开始下降，说明某个资源已经超过瓶颈，这时就应往回在那个点附近测试，直到找到性能最佳点。

3. 压力测试（150%）

• 压力测试时评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力

• 测试超过系统能力时软件能够差到什么地步，是速度变慢、系统崩溃还是卡死

• 当性能不好时，期望系统超负荷之后将一些任务挂起，比如允许20000人排队，第20001个人请求时直接提示“当前排队人数太多，请稍后再试”，将请求拦截下来，而不是任由发展，最后系统崩溃。这是压力测试的意义。

• 举例：考研成绩查询网站，成绩查询时，总有一部分人查不到成绩，但是系统不会崩溃，系统能够保证一直会有人能够查到结果。性能确实有问题，但可以不修改，因为查询考研成绩使用场景不多，一年也就一次。

4. 稳定性测试（40%~60%）

在给系统加载一定业务压力（中上游压力）的情况下，使系统持续运行一段时间，以此检测系统是否稳定。模拟绝大多数常态的使用。

5. 并发测试

• 测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。

• 死锁：在程序里面都有锁的机制，为了避免并发操作带来的一些隐患，锁是有钥匙的，如果要访问这个系统是需要验证开锁的，在大家都有钥匙时，一起把钥匙插入一个钥匙孔里，此时需要触发锁的机制，避免崩溃。这个锁会保护自己，将程序锁起来，外界无法再访问。需要人工来解锁才能再次恢复正常。

• 举例：12306抢票，9点放票，同时抢票，对于服务器来说就是并发的压力。
  并发比较容易出问题，其他还好。

三、 性能测试常用指标

1. 响应时间

1.1 定义

从用户发送一个请求到用户接受到服务器返回的响应数据这段时间就是响应时间，即用户从点击到看到结果的时间就是响应时间

响应时间=呈现时间+网络传输时间+服务器端响应时间+应用延时时间

1.2 关键路径

下图为一次HTTP请求经过的路径：

（1） 请求以报文的方式经过网络（4G网、路由器等）发送到web服务器（比如在上海、深圳）进行处理
（2） 服务器判断请求要干什么，是否需要与数据库进行交换，如果需要操作数据库，再由网络转发到数据库进行处理
（3） 数据库返回值给web服务器
（4） web服务器拿到返回结果后稍作处理，组成json体返回给前端
（5） 前端拿到json体数据后，套到自己的前端模板里，展示给用户看。

1.3 响应时间和负载对应关系

实际曲线肯定是锯齿状

曲线图解析：

• 前期用户负载不断增加，响应时间几乎不变。等到用户负载达到一定数量时，响应时间开始急速增加。

• 与理发店模型相同，一个理发店有10个理发师，假设每个理发师给每个人理发时间相同，当同时来10个及其以下的人数要理发时，不需要等待，每个人理发时间都一样。同时来11个人时，有一个人就需要排队，这个人的等待时间就是前面10个人的2倍。同时来21个人时，第21个人等待时间就是前10个人的3倍。

• 图中拐点说明：响应时间突然增加，意味着系统的一种或多种资源利用达到的极限，通常可以利用拐点来进行性能测试分析与定位。此时的拐点就是性能最佳点。

2. 吞吐量

2.1 定义

单位时间内系统处理的客户端请求的数量，是判断程序处理能力的指标。

2.2 计算单位

 一般使用：请求数/秒
 也可以使用：页面数/秒
 业务角度：访问人数/天 或 访问量/天

2.3 计算方法

Throughput = (number of requests) / (total time)，即请求总数/花费的总时间，比如共100个请求，花费50秒，吞吐量就是每秒处理2个。

2.4 吞吐量-负载对应关系

理发店一共只来1个人，每个人理发只需要1分钟，则吞吐量为1个/1分钟。共来5个人，有10个理发师，5个人理好发共需要1分钟，则吞吐量是5个/分钟。有10个人时，吞吐量是10个/分钟。有11个人时，总花费时间为2分钟，则吞吐量为5.5个/分钟

3. 并发数

3.1 并发用户数

某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。比如有100个人，100个人都去测试注册接口，也可以50个人测试注册接口，50个人测试登录接口，只要保证是同时出发触发即可。

3.2 在线用户数（日活）

某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求

3.3 系统用户数

系统注册的总用户数据

3.4 三者之间的关系

系统用户数≥在线用户数≥并发用户数，等于的情况很难实现。

4. 资源利用率

4.1 定义

指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡量

4.2 需要关注的点

（1） CPU（按百分比看，不要超过80%~90%，超过则说明使用率过高）
电脑的核心，就像人的大脑，主要负责相关事情的判断以及实际处理的机制
（2） 内存（按百分比看，不要超过80%~90%）
大脑中的记忆块区，将眼睛、皮肤等收到的信息记录起来的地方，以供CPU进行判断。但是是临时的，访问速度快，如果关机或断电，这里的数据将会消失。所有的东西都会先加载到内存里，内存再做相应的处理。
（3） 磁盘IO
大脑中的记忆区块，将重要的数据保存起来（永久保存，关机或断电不会丢失，速度慢），以便将来再次使用这些数据
（4） 网络：带宽
发表文章，文章中有十几张照片，再加一些小视频。当点击发表时，需要进行网络传输。照片/视频会先上传到服务器中存起来，这样别人才能调用。此时需要用到带宽
（5） 查看电脑性能方法
进入任务管理器，选择性能-资源监视器，可查看CPU、内存、磁盘、网络使用具体情况

4.3 资源利用-负载对应关系

• 用户负载不断增加，资源利用率也逐步上升，最后达到一个平稳。
• 图中拐点说明：服务器某资源使用逐渐达到饱和，通常可以利用拐点来进行性能测试分析与定位。
• 曲线不下降的原因：当达到一定负载后，就会限速，比如百度网盘下东西，限速100kb/s，稳定。

5. 其它常用概念

5.1 PV

访问一个URL，产生一个PV（page view，页面访问量），每天每个网站的总PV量是形容一个网站规模的重要指标，按访问次数计算，累加制。一个用户访问10次，算10个访问量。

5.2 UV

作为一个独立的用户，访问站点的所有页面均算作一个UV（unique visitor，用户访问），按用户计算，一个用户访问多次，算1个UV。商家投放广告关注UV，比如打开腾讯视频时会有广告，关注的便是稳定用户使用量。