【原创】基于RBI的性能测试理念，通过jmeter快速定位接口最大并发用户数

测试工具：jmeter v_5.2

测试对象：某网站的物料获取接口，需登录后操作

测试目的：快速定位该接口最大并发用户数

思路&步骤：

1.模拟一个场景，某天临近下班，主管突然过来让你测下你们网站，一个获取物料接口的性能，撂下一句“找下它最大的并发数，然后扣扣上跟我说下”。你说你怎么办，要做的很严谨吗（把软件，硬件，网络环境，代码算法逻辑等因素都放进去），可以这么做，但场景设计的越是复杂，影响性能瓶颈的因素就越多，这样就越难找到自己想要的结果，等你测试完成，网站可能已经被用户踩塌了，所以引入RBI测试理念，突出快速。

2.按要求先网站登录，再调用物料获取接口，你把脚本整理出来了

注意，登录的线程组是“setup thread group”，获取物料的线程组是“Ultimate thread group”

前者是把登录作为测试前准备来看，后者是为了更好控制接口压力

正则表达式提取器，为了提取token用于后面接口的操作

BeanShell后置处理程序，为了实现跨线程组参数的传递

Http信息头管理器，为了存储获取到的token

固定定时器，为了进一步控制接口压力

聚合报告，为了用来获取关键的测试结果

3.脚本的框架有了，接下去你就要设计测试场景， “几秒起几个用户，持续操作多久，然后停止操作要花几秒”

start threads count：并发的用户数

Initial Delay，sec：延迟启动的时间

Startup Time，sec：启动线程的耗时

Hold Load For，sec：持续时间

Shutdown Time：关闭线程的耗时

1.先来个，0秒启动100个并发，持续一分钟，然后马上关闭全部线程，结果你发现，响应时间，吞吐量数据都不好看，说不定还有若干请求报错了。

原因猜测，压力太大，请求可能堵在客户机或者服务端，时间过长，就会超时报错

2.打算降压，30秒启动10个并发，持续一分钟，然后10秒关闭全部线程，结果你发现，响应时间很短，但吞吐量不高。

原因猜测，压力太小，服务端还没开始就结束了

3.再次优化，30秒启动50个并发，持续一分钟，然后10秒关闭全部线程，结果你发现，吞吐量有个持续走高的过程，会有浮动，且会出现一个峰值

原因猜测，客户机在不停给服务端施压，服务器处于逐渐满负荷运行的状态

4.现在你有了一个峰值的吞吐量，以及对应的响应时间，就能得出服务器最优状态下的最大并发用户数了，

吞吐量（此处的吞吐量假设等于TPS）X 平均响应时间 ≈ 最大并发数

注意事项：

1.由于主动忽略了很多外部环境因素，最后得出的也应该只是一个大致结果