【性能测试】基础知识篇-压力模型

常见压力模式

并发模式（即虚拟用户模式）和RPS模式（即Requests Per Second，每秒请求数，吞吐量模式）。

本文介绍这两种压力模式的区别，以便根据自身业务场景选择更合适的压力模式。

并发模式

“并发”是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。

应用场景

如果需要从客户端的角度出发，摸底业务系统各节点能同时承载的在线用户数，可以使用该模式设置目标并发。

使用说明

并发模式下，需要指定全场景的最大并发数，再设置各串联链路的并发权重。

串联链路内各API的响应速度不同（表现为响应时间不同），所以单位时间内API的并发数也会不同。API响应速度越快，单位时间内累积在API上的并发用户数越少。

假设，目前共有100个虚拟用户需要操作某个事务（即串联链路）。该串联链路中共有2个API，API 1的响应速度快而API 2响应速度慢。则更多的虚拟用户将会等待在API 2上，API 2则需要更多的线程资源来处理更多的虚拟用户请求。

RPS模式

RPS（Requests Per Second）是指每秒请求数。

应用场景

RPS模式即吞吐量模式，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力，免去从并发到RPS的繁琐转化，可快速实现压测。

使用说明

API接口（如电商加购物车、下单等）主要用TPS（Transaction Per Second, 每秒事务数）来衡量系统的吞吐能力，选择该模式可以直接按照预期的TPS设置RPS。如果希望检验“下单”接口是否能达到500 TPS的预期，那么设置RPS为500，每秒发送500个请求，可检验系统的吞吐能力。

该模式下，请求无法及时响应时可能会导致较高的并发，异常情况请及时停止。

该模式仅支持非自动递增进行压测，即您需在压测过程中手工调速。具体操作，请参见手动调速模式下调速。

同一链路中，后一个API的RPS值需小于等于前一个API的RPS值。

基于实际业务考虑，一般正常业务链路转化模型应该为漏斗形状。例如，正常业务链路为：查看首页-查看商品详情-加入购物车-下单-付款。那么通常情况下，查看首页的用户数会比查看商品详情的用户数多，查看商品详情的用户数也会比加入购物车的用户数多，以此类推，所以后一个API的RPS值需小于前一个API的值，这样就比较符合漏斗模型。

配置量级及数据

设置好压测模式后，还需要在施压配置页面设置压测起始量级与最大量级。

压测数值

每个API可以视为业务系统的一个节点，处理能力不同导致可承载的业务量也不一致。并发模式与RPS模式施压的方式不同，故压测数值上的设置也会不同。

说明 无论选取何种压测模式，各场景最大值的总和不可超过该账户下对应资源包的最大VU、RPS。

两种模型的区别

RPS（Requests Per Second）压力模型和并发用户模型都是性能测试中常用的模型，但它们的测试方法和指标略有不同。

并发用户模型是一种测试方法，它通过模拟多个并发用户同时访问系统，以测试系统在高并发情况下的性能表现。测试人员可以逐步增加并发用户数，直到达到系统的瓶颈为止。在并发用户模型中，主要关注的指标是并发用户数、响应时间、吞吐量、错误率等。

RPS压力模型也是一种测试方法，它通过模拟多个并发用户向系统发送请求，以测试系统在高并发情况下的性能表现。测试人员可以逐步增加请求量，直到达到系统的瓶颈为止。在RPS压力模型中，主要关注的指标是每秒钟处理的请求数（即RPS）、响应时间、吞吐量、错误率等。

因此，两种模型的区别在于，对于同样的并发用户数，RPS模型可能会产生更多的请求量，而并发用户模型则更强调每个用户并发请求的情况。此外，两种模型对于测试系统性能的关注点也略有不同，但都是测试系统在高并发情况下的性能表现，以便找到系统瓶颈并进行优化。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！