测试工具：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.由于主动忽略了很多外部环境因素，最后得出的也应该只是一个大致结果
2.很多步骤我都一句带过，实际自己操作要多理解
3.这个方法完全是自己理解加上散乱的网上知识点所得出，必定有不合理的地方，非常欢迎不同的声音进行留言