和用户加载方式对应，用户终止方式是场景执行完成后的用户退出方式。一般使用的是“同时退出”和“每隔多少时间退出几个用户”这种方式。这里我们重点介绍一下“同时退出”这种方式。应用在持续一段时间的压力后如果突然压力全部释放了，那么这时的应用在理想情况下应该是怎样的？CPU资源应该从繁忙立即变为空闲，网络传输也大幅降低，磁盘IO降为0等等。不然，那就是有某种问题的存在了。这时候就需要分析导致资源不能释放的原因。

　　各种资源的监控方式

　　资源的监控方式也是我们场景设计时必须考虑的一个必要因素，在场景设计时就应该确定每个场景的资源监控策略。这些策略包括监控的对象、使用的监控工具或方法、监控数据采集频率等。监控对象一般是测试环境中所有操作系统资源使用（CPU、内存、磁盘IO、网络吞吐等）、数据库（TOP SQL、数据库锁等待与死锁、缓冲区命中率等）、JVM的运行情况（堆内存垃圾回收、线程状态、数据库连接池使用情况等）等。监控数据采集频率也会因场景执行的时间长度不同而进行适当调整，例如混合容量场景如果执行30分钟，那么采集频率可以为每5秒钟采集一次，共采集360次。但是，考虑到监控要提前启动，所以采集次数可以适当增加一些，这样可以确保整个监控区间大于场景执行区间，也就同时监控到了资源使用在压力发起前后的变化情况。对于执行时间较长的场景，我们就要适当调整采集间隔和采集次数，例如对于一个执行12小时的稳定性场景，我们可以每50秒采集一次，共采集1000次。

　　常见的场景类型

　　单交易基准

　　一般使用一个用户或一个线程，延时设置为0，对一个交易持续运行10分钟以上。该场景的主要目的是获取单个交易在无压力的情况下的基准响应时间及环境资源使用情况，作为其他场景的参考依据。

　　单交易负载

　　单交易负载的场景是为了找到单个交易的最优TPS，检测单交易在并发情况下是否存在性能瓶颈。这个最优是以什么为衡量标准呢？通常以应用或数据库等系统的CPU使用率不大于70%为标准。为什么是70%？不能更高了吗？通常在生产上运行的应用，如果CPU使用率长期处于高水平那是非常严重的问题，应用的节点随时都可能挂掉。对于生产环境各种资源的使用情况，开奖，通常运维部门都会有实时的监控，一般当摸个节点的CPU使用率超过50%时就会触发报警，如果长时间处于高负载状态，那么说明应用节点可用资源不足，就应该考虑进行节点扩充了。

　　当然，也并不是什么情况下都需要找到单交易的最优TPS，这要分情况来对待。对于被测应用提供的交易比较少的话，可以通过不断测试找到每个交易的最优TPS。但是，有的应用提供的交易比较多，这时如果每个交易的最优TPS都要找到，那就会需要较多的时间来进行测试。

　　单交易负载的场景具体该如何设计与执行呢？如果你想找出每个交易的最优TPS，可以从5个并发用户开始，执行几分钟后再增加5个用户，直到应用CPU使用率超过70%为止。场景的延时设置为0，场景执行前需开启相关监控。该场景用于获取单交易在并发情况下的响应时间与TPS，发现交易本身是否存在并发问题，应用是否会出现错误和异常，响应时间相对单交易基准是否有明显的提高，资源使用率是否在合理的承受范围之内等等。如果应用存在性能缺陷该场景即可发现。

　　当然，如果你不想测试出每个交易的最优TPS，那么单独对每个交易做一次5个并发的负载测试即可。

　　多交易混合负载

　　多交易混合负载的目的是为了找到应用的最优TPS，即应用CPU资源消耗在70%左右时的TPS（此时需确保数据库等其他被调用资源不成为瓶颈）。