软件测试 - 性能测试 （概念）（并发数、吞吐量、响应时间、TPS、QPS、基准测试、并发测试、负载测试、压力测试、稳定性测试）

一、性能测试

目标：能够对个人编写的项目进行接口的性能测试。

一般是功能测试完成之后，最后做性能测试。性能测试是一个很大的范围，在学习过程中很难直观感受到性能。

以购物软件为例：

1）购物过程中⻚⾯突然⽆法打开，刷新后可以重新打开

2）双⼗⼀期间⽆法进⼊商品⻚⾯

3）⻚⾯加载时间过⻓，需要消耗⽤⼾⼤量的等待时间

......

常⻅的性能问题：

查询数据时间过⻓，⽹速很慢，服务器⽆响应，查询数据很⻓时间才显⽰列表

二、常⻅性能测试指标

2.1 并发数

并发⽤⼾数。

从业务层⾯看，并发⽤⼾数指的是 实际使⽤系统的⽤⼾总数 。

从后端服务器层⾯看，指的是web服务器在⼀段时间内处理浏览器请求⽽建⽴的http连接数或⽣ 成的处理线程数。

案例：

        ⼀个已经投⼊运⾏的web系统，有5000名员⼯使⽤，最多同时有2500⼈使⽤，⽤⼾分别进⾏ 浏览⻚⾯、填写订单、提交订单、查询订单的操作。那么这个系统的业务并发⽤⼾数是2500，实际并发⽤⼾数是提交订单和查询订单操作的⽤⼾。

常见场景：

双十一购物

微博热搜

学校抢选修课

...

2.2 吞吐量

单位时间内处理的并发数 ，直接体现软件系统 负载承受能⼒ 。吞吐量越⾼，系统承受的并发越多，性能越好

案例：

        有AB两种场景。

        A场景，有100个并发⽤⼾，每个⽤⼾每隔1秒发出⼀个请求。

        B场景，有1000个并发⽤⼾，每个⽤⼾每隔10秒发送⼀个请求。

        A和B场景的吞吐量相同都是每秒100个请求。但是A场景思考时间短，所以A场景占⽤的系统资源更多。

2.3 响应时间

应⽤系统 从请求发出开始 ，到客⼾端接收 到最后⼀个字节数据 所消耗的时间。

对于web系统⽽⾔，系统响应时间包含前端展现时间和系统响应时间。

前端展现时间：⻚⾯渲染时间

系统响应时间：包含服务器、数据库、通讯⽹络等响应时间

 开发者工具能看到响应时间

并发⽤⼾、系统吞吐量、系统响应时间之间的关系

        x轴为并发数，y轴为每秒处理的事务数（吞吐量）

        当并发⽤⼾较少，系统吞吐量低，系统响应时间较短，我们认为系统处于 空闲区间（0-Ax ）。随着系统并发⽤⼾增加，系统吞吐量开始呈线性增⻓，系统性能进⼊了线性增⻓区间。

        

        吞吐量在某个点上达到了饱和点，也称之为 拐点（c），系统性能最好的时候 。在这之后⽤⼾请求不再被⽴即处理，响应时间随之变⻓，吞吐量也逐渐降低，系统性能进⼊了 过饱和区间（Cx-Dx） 。从拐点之后，随着并发数的增加，服务器压力逐渐增大，处理逐渐缓慢。

        系统性能的 拐点 通常是性能测试的 主要⽬的 。

2.4 事务

        ⼀个接⼝可以是⼀个事务，多个接⼝也可以是事务，⼀个流程可以是事务，事务代表⼀个完整的功能。

吞吐量的表现形式 TPS和QPS

2.4.1TPS：每秒处理事务数，⽤于衡量系统在⼀定时间内能够处理的事务数

计算公式： 总的事务数 / 总的运⾏时间

        举例1：某⼀系统1分钟处理1000个业务，那么TPS = 1000 / 60 = 16.7

        举例2：2022年最⾼的⼀天⼜10万笔交易，预测2023年TPS需要多少合格？认为每笔交易就是⼀个事 务，理论TPS = 100000 / 24*60*60 = 1.2（理想状态），然⽽实际上订单量会在某段时间内突然增 加，并不是平均到每个时间段内，因此

1）没有更详细的数据：根据 ⼆⼋定律 （80%的事务在20%的时间内完成）

        TPS = （100000 * 0.8） / （24*60*60*0.2） = 4.6

2）如果有详细的数据：5万笔交易在晚上的8~9点（1小时）完成的

        TPS = 50000 / （60*60） = 13.9

      实际还要参考往年业务的增⻓，假设每年业务增⻓30%，则TPS = （50000 + 50000*0.3） / （60*60） = 18

2.4.2 QPS： 每秒查询率

若⼀个事务中只有⼀个接⼝且是查询接⼝，则QPS = TPS

 2.5 资源利⽤率

通过查看系统占⽤的情况分析资源瓶颈。

服务器：CPU、内存、磁盘、⽹络等

三、性能测试关注点 

不同的⻆⾊看待性能测试的侧重点不同。

从客⼾端发起⼀个请求到客⼾端收到请求的整个过程中，各阶段都可能存在性能问题

后端处理请求的性能问题

服务器硬件资源（CPU、内存、磁盘）

中间件、⽹络、数据库、架构设计等是否存在瓶颈

        开发⼈员和测试⼈员并不需要关注全流程的性能问题。

        通过分析不同⻆⾊的侧重点，从⽽促进性能测试更好的开展。

 软件系统性能相关的⻆⾊主要有四种：

• 终端⽤⼾

        对于终端⽤⼾来说，表现为⽤⼾进⾏业务操作时的主观响应时间。⽤⼾重点关注从你提交请求到收到响应的时间，包括系统响应时间和前端展现时间。

• 系统运维⼈员

        系统运维⼈员除了关注单个请求的响应时间，更关注⼤量⽤⼾并发访问时对系统的影响，以及更⼤负载情况下的系统健康状态。从⽽执⾏系统的整体的策略。

 

1.关注全局利益最⼤化，对最⼤并发⽤⼾数和系统响应时间进⾏权衡取舍

2.系统并发处理时间、系统容量、数据库调优，以及⻓时间运⾏稳定性和可扩展性。

例如：当有以下两种⽅案时

        A⽅案：100万并发访问⽤⼾，登陆响应时间3秒

        B⽅案：500万并发访问⽤⼾，登陆响应时间8秒

这种情况下运维⼈员往往更更倾向于第⼆种

• 软件设计开发⼈员

        关注算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性等⽅⾯。

例如：对于算法，要保证⾼效，⽆内存泄漏；对于架构，要保证系统容量和性能可扩展。

• 性能测试⼈员

        ⼯作重点在于性能测试场景的设计、脚本的开发和执⾏，以及性能缺陷的排查和定位。

测试⼈员除了具有及其宽⼴的知识⾯，如系统架构，存储架构，⽹络架构等全局的知识，还要有⼤量知识积累，⽐如数据库SQL语句的执⾏计划调优、JVM垃圾回收、多线程常⽤问题等。

        可⻅性能测试的范围太⼤了，不同的⻆⾊对于性能有不同的处理⽅式

四、性能测试分类

4.1 基准测试

        基准测试(Benchmark Testing)⼜称 单⽤⼾测试 ，主要⽤于监测被测系统 在较低压⼒下的运⾏状况 并记录相关数据。当性能测试环境确定以后，通常选取业务模型中的重要业务做基准测试，对 被测系统施加⼀定压⼒，从⽽获取被测系统在单⽤⼾运⾏情况下的各项性能指标，为多⽤⼾并发测试和混合场景测试等提供参考依据。

例如：一个卖蔬菜水果的农商

        现在有一批货，运输到客户家，可能要3天。他不知道运输过程中，蔬果是否会坏掉。

就先在田里摘几个蔬果作为基准来测试，发现放5天左右不行了，那么送到客户那的时候，蔬果还是新鲜的。

4.2 并发测试

并发测试(Concurrency Testing)⽤于评估被测系统的某些 特定操作同时发⽣ 时的性能表现.

        例如，被测系统被多个⽤⼾同时登录时的响应能⼒，或系统的某⼀功能被多个⽤⼾同时操作时的性能表现。通过并发测试，不仅可以获得被测系统在多⽤⼾并发操作时的性能指标，还可以发现被测系统在并发条件下可能发⽣的问题，如内存泄漏、线程锁、资源争⽤问题。

        例如，通过模拟多个⽤⼾同时访问某⼀条件数据，或模拟多个⽤⼾同时更新数据，可能会发现被测系统的数据库访问错误、写⼊错误等。⼏乎所有的性能测试都会涉及⼀些并发测试。但并发测试对并发时间要求⽐较苛刻，通常需借助专⻔的性能测试⼯具，采⽤多线程或多进程的⽅式来模拟多个虚拟⽤⼾的 并发性操作。

4.3 负载测试

        负载测试(Load Testing)是性能测试的⼀种测试类型，⽤于评估被测系统 在预期的不同负载下的⾏为 。

        负载测试关注系统处理不同负载的能⼒，这些负载可通过控制并发⽤⼾或者进程的数量来实现。进⾏负载测试时，通过对系统不断增加并发访问负载，监测系统性能的变化，直到系统的某项或多项性能指标达到安全临界值，最终确定在满⾜该安全临界值的性能指标下，系统所能承受的最⼤负载量。

        简⽽⾔之，负载测试是通过逐步加载的⽅式来确定系统的处理能⼒。负载测试类似于举重运动，通过不断给运动员增加重量，确定运动员在其⾝体状况保持正常的情况下所能 举起的最⼤重量。通过负载测试可以获取 系统能够达到的峰值指标 。

        例如，⼀个软件系统的响应时间要求不超过2秒，如果在这个前提下不断增加⽤⼾访问量，系统的响应时间就会变⻓。假设当访问量超过1万⼈时系统的响应时间超过2秒，那么就可以确定在系统响应时间不超过2秒的前提下，系统的最⼤负载量是1万⼈。

        负载测试可⽤于系统的性能验证、 性能诊断和性能调优等场景。

4.4 压⼒测试

        压⼒测试(Stress Testing)⽤于评估被测系统在高于预期、高于指定容量负载需求或低于最少需求 资源的条件下的⾏为。

        压⼒测试关注被测系统 处理超出预期或特定峰值负载的能⼒ ，也可以⽤于 评估系统在资源匮乏时的处理能⼒ ，⽐如在可⽤的计算能⼒、带宽和内存资源不⾜的条件下系统的表现。

        进⾏压⼒测试时通常采⽤逐步增加系统负载的⽅式，使系统某些资源达到饱和甚⾄失效，从⽽发现那些只有在⾼负载条件下才会出现的缺陷，如同步问题、内存泄漏等。

        通过对被测系统进⾏压⼒测试，也能找出被测系统的性能拐点，获得系统所能提供的最⼤服务级别（系统所能承受的最⼤压⼒），评估系统在峰值负载或超出最⼤负载情况下的处理能⼒。

        压⼒测试主要⽤于性能诊断、性能调优和容量规划等场景。

4.5 压力测试和负载测试的区别

压⼒测试和负载测试的区别?

        压⼒测试与负载测试不同。

         负载测试 是在保持性能指标要求的前提下测试系统能够承受的最⼤负载。

        压⼒测试 则是测试系统性能达到极限的状态。

        例如，软件系统要求的响应时间为2秒。进⾏负载测试时发现，当访问量达到1万时，系统响应时间不超过2秒，⽽当访问量超过1万时，系统响应时间则会超过2秒。

         负 载测试： 在满⾜系统响应时间指标的前提下，该系统能够承受的最⼤访问量是1万。

         压⼒测试 ：则可继续增加系统的访问量，并观察系统的性能变化。例如，当系统访问量增加到2万时，发现系统响应时间延迟到5秒，⽽当访问量增加到3万时，系统则崩溃，⽆法做出响应。由此可以确定系统能达到的极限访问量是3万

4.6 稳定性测试

        在负载测试的基础上，执⾏较⻓时间的测试以检查系统的稳定性。通常较⻓时间指3*24⼩时以上。

        例如：举重运动员，在举起杠铃后，需要保持一段时间，才能算作成功举起。

而放在实际业务中，稳定性测试就是系统持续稳定运行的时间。