性能测试全流程-CSDN博客

本文链接：https://blog.csdn.net/weixin_49026134/article/details/145845875

性能测试的概念

为什么要学习性能测试

满足 $\color{red}{真实的业务场景（活动场景）}$ 、支持 $\color{red}{大量的用户}$ 。满足 $\color{red}{商用}$ 要求，如：电商双11活动、微信日常在线用户数。

性能测试的概念

性能：就是软件质量属性中的" $\color{red}{效率}$ "特性。
效率特性包含：
$\color{red}{时间}$ 特性：表示系统处理用户请求的响应时间。
$\color{red}{资源}$ 特性：表示系统运行过程中，系统资源的消耗情况。

性能测试的概念：使用 $\color{red}{自动化工具}$ ，模拟 $\color{red}{不同的场景}$ ，对 $\color{red}{软件各项性能指标}$ 进行测试和评估的过程。
在这里插入图片描述

性能测试的目的：

评估 $\color{red}{当前系统能力}$ 。如：验收第三方提供的软件；获取关键的性能指标，与其他类似产品进行比较。
寻找性能瓶颈， $\color{red}{优化性能}$ 。如：12306订票bug。
评估软件是否能够满足 $\color{red}{未来的需要}$ 。如：双十一热度逐年升高。

性能测试与功能测试对比

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

正向（功能），例如：输入正确的用户名密码，登录成功
逆向（功能），例如：输入错误的用户名密码，登录失败给出提示

性能测试：验证软件系统是否满足 $\color{red}{业务需求场景}$ ，主要焦点是业务场景的满足 $\color{red}{（时间、资源）}$ ；

例如：100w人使用正确的用户名密码登录，1s内能登录成功，——时间
同时服务器的CPU使用率低于70%，内存使用率低于60％等。——资源

关系：
一般项目中， $\color{red}{先功能测试}$ 通过后， $\color{red}{再进行性能测试}$ 。

性能测试的策略

基准测试

为什么要进行基准测试?

单用户性能不达标，有必要进行多用户性能测试吗？
影响性能的因素有很多（如：服务器配置、资源、代码效率），如何判断谁在导致性能变好/变坏？

什么是基准测试？
狭义上讲：就是 $\color{red}{单用户测试}$ 。测试环境确定后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标。
在这里插入图片描述
广义上讲：是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的 $\color{red}{性能基准线}$ ，当系统的 $\color{red}{软硬件环境发生变化}$ 之后再进行一次基准测试以 $\color{red}{确定变化对性能的影响}$ 。
在这里插入图片描述
基准测试数据的用途？

基准测试不会单独存在。
为多用户并发测试和综合场景测试等提供参考依据。

负载测试

为什么要进行负载测试？
电商系统平时可以正常运行，双11时能保证也可以正常运行吗？一 $\color{red}{用户量大}$
什么是负载测试？
通过 $\color{red}{逐步增加系统负载}$ ，确定在 $\color{red}{满足系统的性能指标情况下}$ ，找出系统所能够承受的 $\color{red}{最大负载量（最优并发用户数）}$ 的测试。
负载测试的作用？
系统 $\color{red}{最大负载量}$ 达到 $\color{red}{用户要求}$ 时，系统才能正式上线使用。

在这里插入图片描述

稳定性测试

为什么要进行稳定性测试？
电商系统能抗住双11时的考验，能保证长时间运行不出问题吗？
什么是稳定性测试？
在服务器 $\color{red}{稳定运行（用户正常的业务负载下）}$ 的情况下进行 $\color{red}{长时间测试（1天-1周等）}$ ，并最终保证服务器能满足线上业务需求。
稳定运行时的负载量设置为多少？
例如：前面电梯案例中，实际测试的最大负载为：13人

场景1：如果甲方要求用户正常的负载人数为15人，稳定运行的负载量为多少？先优化使得负载人数达到15人后再进行负载量15的稳定性测试。
场景2：如第甲方要求用户正常的负载人数力10人，稳定运行的负载量为多少？用户要求的10即可。

稳定性测试的作用？
系统 $\color{red}{在用户要求的业务负载下}$ 运行达到 $\color{red}{规定的时间}$ 时，系统才能正式上线使用。

并发测试

为什么要进行并发测试
电商系统能抗住双11时的考验，能保证在秒杀活动时不出问题吗？秒杀特点：时间短，请求量大。
什么是并发测试？
并发测试（绝对并发）：是指在 $\color{red}{极短的时间内}$ ，发送 $\color{red}{多个请求}$ ，来验证服务器对并发的处理能力。
并发测试的应用场景？
特定活动场景，如：抢红包、秒杀、抢购等。
最佳并发用户数VS最大并发用户数（如图）
最佳并发用户数： 系统资源利用率最高
最大并发用户数： 并发用户数的上限，一旦超过了，响应时间上升，TPS下降。
在这里插入图片描述

压力测试

为什么要进行压力测试？
1、软件实际使用时，用户量超过预期（系统最大负载量），该如何反应？
2、软件由于意外情况出现问题，多久能恢复？
什么是压力测试？
在强负载下的测试，查看系统在 $\color{red}{峰值情况下}$ 是否功能隐患、系统是否具有良好的 $\color{red}{容错能力}$ 和 $\color{red}{可恢复能力}$ 。
压力测试的场景？

$\color{red}{极限负载}$ 情况下的 $\color{red}{破坏性压力测试}$ （破坏性测试）：最大并发数
$\color{red}{高负载}$ 下的长时间的 $\color{red}{稳定性压力测试}$ ：最佳并发数

浪涌测试

容量测试

第一种：TPS容量
如：测试被测系统是否能够每秒处理1000个事务。
第二种：并发用户数容量
如：测试被测系统某一个功能是否能够支持1000个并发。
第三种：在线用户数
如：测试被测系统能否支持1000个用户使用。

性能测试的指标

为什么要学习性能测试的指标？
如何衡量功能？有/没有；肉眼可观察，可衡量
如何衡量性能？好/不好；个人感受，不容易量化，不好衡量
对性能测试结果进行 $\color{red}{量化衡量}$
性能测试的指标？
一些经过运算得出的结果，来量化衡量某种操作的性能好坏；比如：错误率 0.58%

响应时间

响应时间：指用户 $\color{red}{从客户端发起一个请求开始}$ ，到客户端接收到 $\color{red}{从服务器端返回的结果}$ ，整个过程所耗费的时间。包括： $\color{red}{服务器处理时间}$ ＋ $\color{red}{网络传输时间}$ 。（<=1.5s）
注意：

通过HTTP接口消息消意来测试
不包括发消息时前端页面的处理时间和收到消息后前端页面的渲染显示时间

并发数（量）

并发（用户）数：某一时刻 $\color{red}{同时}$ 向服务器 $\color{red}{发送请求}$ 的用户数。

淘宝系统案例—哪个是并发数？
场景1：淘宝商城，注册用户数有5亿。—系统用户数（系统注册的总用户数）；数据库用户表的数据条数，对性能无影响。
场景2：当前登录了淘宝商城的用户数为2000万。—在线用户数（某段时间内访问过系统的用户），这些不一定同时向系统在提交请求。
场景3：目前正在刷淘宝的用户数有500万。—并发用户数（某段时间內同时向系统提交请求），请求就会产生负载。

多线程

即虚拟用户，通过多线程技术去模拟海量用户发起请求，从而模拟海量并发场景。类似电脑CPU同时运行多件事情。
并发量与线程数量的关系：
（1）不是一个相等的关系
（2）一个线程向后端发起请求，一个线程在一秒钟可能发起很多的请求。
（3）理论上，一个线程能够模拟的并发量=1000毫秒/响应时间（号码）。因为有网络等各种延迟的存在，一秒钟发起了1000个请求，不代表服务器就会收到1000个请求。

吞吐量

吞吐量（Througbput）：指的是 $\color{red}{单位时间内}$ 处理的客户端 $\color{red}{请求数量}$ ，直接体现软件系统的性能承载能力。
吞吐量的单位有哪些？

从业务角度：业务数/天、访问人数/天、页面访问量/天
从网络角度：字节数/小时、字节数/ 天
从技术指标： $\color{red}{QPS（每秒请求数）、TPS（每秒事务数)}$

在这里插入图片描述
QPS(Query Per Second)每秒查询数：即控制服务器 $\color{red}{每秒}$ 处理的指定 $\color{red}{请求}$ 的数量。

TPS(Transaction Per Second)每秒事务数：即控制服务器 $\color{red}{每秒 }$ 处理的 $\color{red}{事务请求}$ 的数量。事务：即业务，页面上的一次操作，可能对应一个请求/多个请求。
在这里插入图片描述
QPS和TPS有什么关系？
事务，即业务。 $\color{red}{一个事务可以对应一个请求/多个请求}$

一个事务对应一个请求时：TPS = QPS
一个事务对应n个请求时： TPS = n * QPS

吞吐量和并发量的关系：
吞吐量小于或者等于并发量

点击数

点击数：指客户端向服务端发送请求时，所有的 $\color{red}{页面资源元素}$ （如：图片、链接、框架css、js等）的 $\color {red}{请求总数量}$ 。
注意：

只有web项目才有此指标
点击数是请求数，不是页面上的一次点击

错误率

错误率：指系统在 $\color{red}{负载情况}$ 下，失败业务的概率。错误率=（失败业务数/业务总数）*100%。
注意：

大多系统都会要求错误率 $\color{red}{无限接近于0（<=0.1\%）}$ 。
错误率是一个 $\color{red}{性能指标}$ ，是高负载下的失败业务的概率。
错误率不是功能上的 $\color{red}{随机bug}$ ，先解决随机bug才能进行性能测试。

降低错误率的方法：【限流】在系统面临高压力的时候，有时候允许把部分用户请求拒绝。
例如：双11秒杀抢东西，去支付宝——当前支付人数太多，请稍后。

资源利用率

资源使用率：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量x100%”形成资源利用率的数据。
常见资源指标：
（1） CPU使用率：不高于75%-85%
（2）内存（大小）使用率：不高于80%
（3）磁盘IO（速率）：不高于90%
（4）网络（速率）：不高于80%
在这里插入图片描述

性能测试的流程

为什么要学习性能测试的流程？

被分配了性能测试任务，需要按照什么样的步骤来推进？
使用不同的性能测试工具时，流程会不一样吗？

在这里插入图片描述

01 性能测试需求分析

在这里插入图片描述

02 性能测试计划和方案

测什么？
项目背景
测试目的
测试范围
谁来测？
讲度与分工
交付清单
怎么测
测试策略

03 性能测试用例

测试标题、测试步骤、预期结果、实际结果（系统指标、资源指标）
在这里插入图片描述

04 性能测试执行

在这里插入图片描述

05 性能分析和调优

说明： $\color {red}{性能测试分析人员}$ 经过对结果的分析以后，如果不符合性能需求，则会 $\color{red}{提出性能bug}$ ，然后由 $\color{red}{开发人员进行后续的调优}$ 。
提示：
调优：开发人员为主导，数据库管理员、系统管理员、网络管理员、性能测试分析人员配合进行。
验证：性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。

06 性能测试报告总结

测试报告是对性能测试工作的总结，为软件后续验收和交付打下基础。
测试报告的主要内容：
测试工作的经过回顾（测试过程记录）
缺陷分析和调优（问题分析）
风险评估（风险识别）
性能测试结果（测试结论）
测试工作总结与改进（经验教训）

结果分析：
系统正常运行，成功事务数达到99.96%；平均响应时间2.815s，符合要求。总事务数：12249个：事务成功通过数为：12245个；停止的事务数为：4个，停止原因：请求失败，事务还在执行的时候，场景时间到了，磁盘写入速度0.74mb/s，磁盘读取速度0.0008mb/s，IO数77.23/s，CPU利用率在10%左右，进程数<=4，符合要求。

测试分析及结论：
本次测试服务的目标是在系统稳定的基础上，按照性能测试的标准，分别对登陆、桌位、日常、酒水库存进行基准测试、负载测试和稳定性测试，详细分析如下：
1、测试分析：
通过基准测试结果分析：登陆、桌位、日常、酒水库存在1个用户下持续测试10分钟，事务通过率>99%(参照软件性能标准事务成功率满足95%)，平均事务响应时间<6s，已经满足软件使用的标准，达到系统性能要求；
通过负载测试结果分析：.….
通过稳定性测试结果分析：200用户持续10小时稳定性测试，RT<1s，TPS>=100，成功率>99.9%，资源利用率…，完全达到标准，已经满足软件使用的标准，稳定性测试已达到系统性能要求。
2、测试结论：
依据上述性能方面的测试和评估，该系统相当稳定，软件更能满足用户性能使用要求。
备注：依据性能标准，压测过程中出现的事务失败和事务停止，部分是服务器响应超时、压测机内存使用率较大、块大小缺失或无效（“传输编码：分块"），Jmeter软件本身原因等，但针对系统的使用没有影响，可以忽略不计。