性能测试笔记1

为什么要进行性能测试？（在真实项目商用时，需要大量的用户进行使用，因此需要模拟大量用户的使用场景 ）

1、业务需求

电商双 11 活动 / 微信春晚抢红包 /12306 春运订票

当前服务器配置是否支持 20000 人同时使用

技术选型，如编程语言选择 Java ？ Python ？ PHP ？

2、  招聘需求

面试：会性能测试吗？

招聘：要求会使用性能测试工具 Jmeter 、 LoadRunner

什么是性能？

时间：系统处理用户的响应时间

资源：系统运行中，资源消耗的情况

什么是性能测试？（时间与资源）

使用自动化工具，模拟不同的场景，对软件各项性能指标进行测试和评估的过程就是性能测试。

1. 后台处理程序的性能（代码性能）

2. 数据库、架构设计等是否存在瓶颈

3. 服务器资源消耗（ CPU 、内存、磁盘、网络）

性能测试目的

1. 评估当前系统能力

例如：验收第三方提供的软件

例如：获取关键的性能指标，与其他类似产品进行比较

2. 寻找性能瓶颈，优化性能

3. 评估软件是否能够满足未来的需要

区别：性能与功能测试

功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）；

性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足 ( 时间、资源 ) ；

一般项目中，先功能测试通过后，再进行性能测试。

性能测试策略包含：

1. 基准测试

2. 负载测试

3. 稳定性测试

4. 并发测试

5. 压力测试等

基准测试：（理解就是一个标准，当后续改变一下软硬件，看看对性能的变化 ）

狭义上讲：也是单用户测试（单用户循环多次得到的数据），测试环境确定以后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标。（进行基础的数据采集）

广义上讲：是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。

基准测试数据的用途：

1. 为多用户并发测试和综合场景测试等性能分析提供参考依据

2. 识别系统或环境的配置变更对性能响应带来的影响

3. 为系统优化前后的性能提升 / 下降提供参考指标

负载测试（如：双十一活动）

通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。

负载：指向服务器发送的请求数量，请求越多，负载越高

注意：负载测试关注的重点是逐步增加压力

作用： 系统最大负载量达到用户要求时，系统才能正式上线使用

稳定性测试:(短时间抗住，不代表长时间能抗住（轮胎） )

在服务器稳定运行（用户正常的场景下）的情况下进行长时间测试，并最终保证服务器能满足线上业务需求。时长一般为1 天、一周等。

并发测试（如：抢红包、抢购、秒杀活动）

并发测试是指在极短的时间内 （同一瞬间） ，发送多个请求，来验证服务器对并发的处理能力。

压力测试（软件实际使用时，用户量超过预期（系统的最大负载量），该如何反应？ ）

压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。

分为高负载下的长时间（如24 小时以上）的稳定性压力测试 和 极限负载情况下导致系统崩溃的破坏性压力测试。

第一种：极限负载情况下的破坏性压力测试（ C-D 区间）

第二种：高负载下的长时间稳定性压力测试（ B-C 区间）

性能测试的指标：响应时间，并发用户数，吞吐量，点击数，错误率，资源利用率等

为什么要学习性能测试的指标？一般我们衡量性能都是以好与坏的区分，所以可以通过某种操作来衡量性能的好与坏

响应时间

说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。（不包括页面的渲染所需要的时间）

组成：响应时间 = 网络时间 + 应用程序处理时间

并发用户数：

定义：同一时间向服务器发送请求的用户数

吞吐量

说明：吞吐量（ Throughput ）指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力

注意：

1. 从业务角度来看， “ 业务数 / 小时 ” 、 “ 业务数 / 天 ” 、 “ 访问人数 / 天 ” 、 “ 页面访问量 / 天 ” 来衡量

2. 从网络角度来看， “ 字节数 / 小时 ” 、 “ 字节数 / 天 ” 等来衡量网络的流量

3. 从技术指标来看，每秒事务数（ TPS ）和每秒查询数（ QPS ）来衡量服务器具体性能处理能力

TPS（Transactions Per Second） ，每秒事务数 ( 单位时间内系统处理的客户端请求的事务次数 )

计算： TPS = 并发数 / 平均响应时间

事务：就是业务请求，对应一个或者多个操作。如支付请求，包括服务器查询用户余额，支付安全校验等多个操作。 一个业务请 求发送给服务器后，最终会定位到服务器对应的业务请求的代码，既有可能是一段代码也有可能是多段代码。

QPS (Query Per Second)每秒查询数

应用：控制服务器每秒处理指定请求数（如：控制服务器达到每秒 60QPS ，服务器的性能各项性能指标是否正常）。

点击数 

点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（图片、链接、框架等）向 Web 服务器发出的请求数量。

错误率

指系统在负载情况下，失败业务的概率。

什么是负载？就是很多的用户，大量的请求一起发。在这种情况下，失败与成功的比例才是错误率。

随机bug是什么？它属于功能模块bug。只有bug都解决了，就是说包括这种随机的bug都解决了，才可能进行性能测试。否则不会做的。

资源利用率

指系统各种资源的使用情况，一般用 “ 资源的使用量 / 总的资源可用量 ×100%” 形成资源利用率的数据。

提示：通常，没有特殊需求的话（看要求）

1). 建议 CPU 不高于 80%(±5)

2). 内存不高于 80%

3). 磁盘不高于 90%

4). 网络不高于 80%

性能测试流程是什么？（其实跟功能测试流程大差不差）

1. 性能测试需求分析

2. 性能测试计划及方案

3. 性能测试用例

4. 测试脚本编写 / 录制

5. 建立测试环境

6. 执行测试脚本

7. 性能测试监控

8. 性能分析和调优

9. 性能测试报告总结

提示：使用不同的性能测试工具时，主要流程是不变的。

性能需求分析

性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果。

性能需求分析的目标：

1. 熟悉被测系统

熟悉被测系统的业务功能

熟悉被测系统的技术架构

2. 明确性能测试内容

从业务角度明确测试内容确定关键业务。即：用户使用频率较高的业务功能

从技术角度明确测试内容

如：通常逻辑复杂度较高的业务也是 CPU 密集运算较大的地方，考量服务器 CPU 在预定性能指标下是否达标

如：通常数据量较大的业务很占用系统内存，考量服务器内存在预定性能指标下是否达标

3. 明确性能测试策略

负载测试

稳定性测试

并发测试

4. 明确性能测试的指标

无明确需求指标 ：通过查找相关资料，和类似的系统对比，以及对未来流量的预估，确定性能测试需求的指标

有明确需求指标

例如，类似如下指标下订单业务并发20 个用户平均响应时间要小于等于3s ，事务成功率为100% ，CPU使用率小于等于 85%

只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在。

性能测试计划：

测试的目的和范围

测试人员和分工

测试时间安排

测试的方法

性能测试用例：

性能测试执行：

搭建性能环境

编写性能测试脚本

配置性能测试监控指标

执行脚本

性能测试分析和调优：

测试人员负责针对性能的测试结果进行分析是否存在 bug ，由开发人员进行问题分析和调优

注意：

在性能测试的回归过程中，可能需要进行多轮

性能测试报告：

性能测试的过程（ 需求覆盖情况，出现的问题 ）

性能测试的缺陷分析和调优

性能测试的结果

经验总结