Web类的应用一般会有在线用户这样一个测试场景。这个场景主要的考察目标是在大量用户在线的情况下，系统是否会出现异常。在线用户即登录系统后并未执行任何操作的用户或执行操作后未退出的用户。脚本里设置一个足够长的思考时间，让用户反复执行“登录-在线-退出”这样的过程。一般这种场景模拟的用户数量较大。

　　最优并发用户

　　这个场景是为了找到应用的最优并发用户数量。最优并发用户数量是指应用达到最大TPS时的并发用户数量，这一点和最优TPS的定义是有区别的。通常在进行多交易混合容量场景执行过程中测试出应用最大TPS时的并发用户数量即为最优并发用户数量，故此场景可以和多交易混合容量场景合并执行。

　　最大并发用户

　　这个场景是为了找到应用能够承受的最大并发用户数量。最大并发用户数量是应用能够承受的并发用户的极限，直播，这时要求用户不会出现失败，交易响应时间不能超过指标的要求，应用不会出现异常、错误等非正常现象。在测试过程中，当我们测试到最大TPS后继续增加并发用户数量，直到出现应用异常，或出现并发用户失败，或交易响应时间超过测试指标要求等，这时的并发用户数量即为最大并发用户。

　　对于最优并发用户或最大并发用户的场景，一般测试web类的应用或有明确并发用户指标需求的应用时会设计这样的测试场景，而接口类的应用一般不考虑这两个场景。

　　梯度加压

　　所谓梯度是指开始使用较少的用户加压一段时间（几分钟即可），待TPS稳定后再继续往上加用户，如此循环，直到TPS不再增加为止。整个过程就像爬楼梯一样，所以称为“梯度”。

　　这种类型场景一般是为了“偷懒”而设计的。比如，在生产环境要测试一个交易的最大TPS能够到多少时，我们为了节省宝贵的测试时间，一般会使用梯度加压的场景策略。这时我们不知道被测环境能够达到什么样的吞吐量，也没有明确的测试指标，为了快速找到应用的最大TPS，使用梯度场景是最简单有效的。另外，梯度场景适合独立交易的应用（压测场景只有一个交易），因为独立交易不必考虑复杂的场景设置，使用梯度场景可以节省大量的测试执行时间。

　　感谢合众支付资深技术专家程超的推荐与审校。