性能测试理论

学习目标

掌握性能测试理论

1. 为什么要进行性能测试

业务需求

电商双11活动/微信春晚抢红包/12306春运订票
当前服务器配置是否支持20000人同时使用
技术选型，如编程语言选择Java？Python？PHP？

招聘需求

面试：会性能测试吗？
招聘信息：要求会使用性能测试工具Jmeter、LoadRunner

2. 什么是性能

性能：就是软件质量属性中的“效率”特性

效率特性：

时间特性：指系统处理用户请求的响应时间
资源特性：指系统在运行过程中，系统资源的消耗情况

CPU
内存
磁盘IO（磁盘的写入Input和读取Output，简称IO）

2. 什么是性能测试

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

后台处理程序的性能（代码性能）
中间件、数据库、架构设计等是否存在瓶颈
服务器资源消耗（CPU、内存、磁盘、网络）

中间件：是提供系统软件和应用软件之间连接的软件。如：Tomcat、Apache...

3. 性能测试目的

评估当前系统能力

验收第三方提供的软件
获取关键的性能指标，与其他类似产品进行比较

寻找性能瓶颈，让开发进行优化性能
评估软件是否能够满足未来的需要

4. 性能测试与功能测试对比

焦点不一样:

功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）
性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、资源)

关系:

功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可减少的2个重要测试环节
般新项目中，先功能测试通过后，再进行性能测试。

5. 性能测试策略

基准测试
负载测试
稳定性测试
其他：并发测试、压力测试、容量测试等

5.1 基准测试

狭义上讲：也是单用户测试，测试环境确定以后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标。（进行基础的数据采集）
广义上讲：是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响

基准测试数据的用途：

为多用户并发测试和综合场景测试等性能分析提供参考依据
识别系统或环境的配置变更对性能响应带来的影响
为系统优化前后的性能提升/下降提供参考指标

5.2 负载测试

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

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

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

5.3 稳定性测试

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

5.4 其他测试策略

性能测试中，测试策略其实有很多种，但是掌握基础的用法后，其他不同名称的测试策略只是基础用法的一个变形用法

并发测试：并发测试是指在极短的时间内，发送多个请求，来验证服务器对并发的处理能力。如：抢红包、抢购、秒杀活动等。
压力测试：压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
容量测试：关注软件的极限压力下的各个极限参数值，例如：最大TPS，最大连接数，最大并发数，最多数据条数等

6. 性能测试指标介绍

响应时间

说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。
组成：响应时间 = 网络时间 + 应用程序处理时间

并发数

说明：并发测试的用户数
系统用户数：系统注册的总用户数据
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求
并发用户数：某一物理时刻同时向系统提交请求的用户数

吞吐量

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

从业务角度来看，吞吐量也可以用“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”来衡量
从网络角度来看，还可以用“字节数/小时”、“字节数/天”等来衡量网络的流量
从技术指标来看，可以用每秒事务数（TPS）和每秒查询数（QPS）来衡量服务器具体性能处理能力

点击数

说明：点击数是衡量Web服务器处理能力的一个重要指标
点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（图片、链接、框架等）向Web服务器发出的请求数量
通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力
注意：只有web项目才有此指标

错误率

说明：错误率指系统在负载情况下，失败业务的概率。错误率＝(失败业务数/业务总数)*100%
不同系统对错误率要求不同，但一般不超过千分之五
稳定性较好的系统，其错误率应该由超时引起，即为超时率

资源利用率

说明：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
建议CPU不高于80%(±5)
内存不高于80%
磁盘不高于90%
网络不高于80%

PV和UV

PV：网站的是页面浏览量或者点击量，页面被刷新一次就计算一次
UV：访问网站的一台电脑客户端为一个访客

6.1 TPS

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

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

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

6.2 QPS

说明：QPS(Query Per Second)每秒查询数

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

7. 性能测试流程

性能测试需求分析
性能测试计划及方案
性能测试用例
测试脚本编写/录制
建立测试环境
执行测试脚本
性能测试监控
性能分析和调优
性能测试报告总结

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

7.1 性能需求分析

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

熟悉被测系统

熟悉被测系统的业务功能
熟悉被测系统的技术架构

明确性能测试内容

从业务角度明确测试内容：

① 确定关键业务。即：用户使用频率较高的业务功能

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

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

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

明确性能测试策略

负载测试
稳定性测试
并发测试

明确性能测试的指标

无明确需求指标

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

有明确需求指标，例如：

① 下订单业务并发20个用户

② 平均响应时间要小于等于3s

③ 事务成功率为100%

④ CPU使用率小于等于85%

7.2 性能测试计划及方案

说明：性能测试实施第一份文档，也是最重要的一份文档

项目背景
测试目的
测试范围
测试策略
风险控制
交付清单
进度与分工

7.3 性能测试用例

性能测试用例模板：

7.4 测试脚本编写或录制

说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。

建议自己编写脚本，录制的脚本缺乏实用性

7.5 建立测试环境

说明：在进行性能则试之前，需要先完成性能测试环境的搭建工作，测试环境一般包括硬件环境、软件环境、数据准备及网络环境

7.6 执行测试脚本

说明：先保证脚本调试通过之后，才能进入正式压测阶段。执行测试脚本时，要先进行性能运行场景的设置，再运行脚本

7.7 性能测试监控

性能监控就是监控服务器的各项性能指标。例如：监控CPU、内存、网络、TPS、磁盘IO等

7.8 性能分析和调优

说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈

调优人员(开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员)相关人员对系统进行调整
验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升

注意系统调优由易到难的先后顺序如下：

硬件问题
网络问题
应用服务器、数据库等配置问题
源代码、数据库脚本问题
系统构架问题

7.9 性能测试报告总结

性能测试总结要包含以下内容：

性能测试需求覆盖情况，测试过程回顾，及测试中出现的问题（如何去分析、调优、解决的）
性能测试过程中遇到各类风险是如何控制的; 目前是否还有其他的性能风险存在
经过该项目性能测试后，有那些经验和教训等内容

8. 常见的TPS算法

需求：按照需求所示，在2022年第32周，每天有4.13万的浏览量，那么总请求数，我们可以认为估算为4.13万（1次浏览都至少对应1个请求）

① 普通计算方法

计算公式：TPS= 总请求数 / 总时间

总请求数 = 4.13 万请求数 = 41300 请求数

总时间：由于不知道每个请求的具体时间，我们按照普通方法，我们可以按照一周的时间进行计算

总时间 = 1天 = 1 * 24 小时 = 24 * 3600 秒

套入公式可得：

TPS = 41300请求数/24*3600秒 = 0.48请求数/秒

结论：按照普通计算方法，我们在测试环境对相同的系统进行性能测试时，每秒能够发送0.48请求就可以满足线上的需要。

但大多数情况下，用户的访问不会那么平均地分散在每一个时间点，因此“0.48请求/秒”就显得没那么符合实际

② 二八原则计算方法

二八原则就是指80%的请求在20%的时间内完成

计算公式： TPS = 总请求数 80% / (总时间20%)

按照公式进行计算：

TPS = 41300 * 0.8请求数 / 24*3600*0.2秒 = 1.91 请求数/秒

结论：按照二八原则计算，在测试环境我们的TPS只要能达到1.91请求数每秒就能满足线上需要。二八原则的估算结果会比平均值的计算方法更能满足用户需求。

③ 按照业务数据进行计算

业务数据：有的公司会统计一定时间内的所有业务数据，我们可以根据这个业务数据曲线图，统计出最多请求的数量和时间比例。

先来看看趋势折线图：

直方图看数据和趋势：

要求一：计算模拟用户正常业务操作（稳定性测试）的并发量。

根据这些数据统计图，可以得出结论：

大部分订单在8点-24点之间，因此系统的有效工作时长为16个小时
从订单数量统计，8-24点之间的订单占一天总订单的98%左右（40474个）

再结合二八原则计算公式： TPS = 总请求数 80% / (总时间20%)

需要在测试环境模拟用户正常业务操作（稳定性测试）的并发量为：
TPS = 40474 * 0.8请求数 / 16*3600*0.2秒 = 2.81 请求数/秒

要求二：计算模拟用户峰值业务操作（压力测试）的并发量