一般情况下，为了方便我们统计TPS，建议一个脚本只包含一个完整的交易，不要把多个交易放到一个脚本中。因为，不同的交易其响应时间会不同，响应时间较长的交易会成为“瓶颈”。另外，我们设计测试场景时需要考虑不同交易的占比，如果多个交易存在同一个脚本里，场景的设计就无法实现。

　　上文提到的“被测交易”是我们压测的对象，也是应用的入口。当然，并不是被测应用的每个交易都需要进行压测，这要视具体情况而定。如果被测应用提供的交易非常多，我们可以考虑只选取占比比较大的交易进行压测，而占比较低的交易可以忽略。

　　并发用户数量或并发线程数量

　　并发用户和并发线程其实是同一个概念，只是在不同的性能测试工具中其叫法不同而已。在下文中我们统称“并发用户”。当然，这些用户是虚拟用户，是压力测试工具使用进程或线程来模拟真实用户请求的一种方式。并发用户是每个场景提供不同压力的直接来源，场景不同其需要的并发用户数量可能会不同。那么是什么因素决定一个场景要并发用户的多少呢？主要是被测交易的响应时间和场景的目标TPS。交易响应时间的快慢是决定并发用户数量的主要因素，例如一个应用的某个交易响应时间是50ms，如果要实现100TPS的目标，那么只需5个并发用户即可达到（目标TPS*交易平均响应时间=并发用户量）。如果响应时间是100ms，那么实现同样的TPS需要的并发用户就会多一倍。

　　加压策略

　　加压策略就是并发用户以什么样的“步调”开始对应用发起请求。常用的并发策略有同时加载、指定间隔时间的加载，梯度加载等方式。加压策略的不同主要是模拟生产环境不同的情况，下面分别做简单介绍。

　　同时加载方式是指所有并发用户在场景启动时同时发起交易请求而不包含任何等待，这样会对被测应用带来突然的压力，用于考察应用在突然加压下的表现是否符合预期。一般有用户突增的业务特点的应用会设计这样的场景，例如，某些抢购系统、铁路售票系统的按时放票功能等。当然，对于那些并发用户较少的场景也可以采用这种用户加载方式。而对于有些应用如果同时加载大量的并发用户可能会出现异常或超时，导致部分并发用户失败。

　　指定间隔时间的加载方式是我们最常用的，这是为了模拟生产的实际情况，一般生产系统接收用户请求都是逐渐增加的，到当日交易的高峰时段达到最大。在场景设计时，根据并发用户的多少可以设置适当的增加频率，一般是“多长时间增加多少用户”。例如，每一秒钟增加一个用户、每两秒增加5个用户等等。

　　梯度加压策略也是我们常用的一种用户加载方式，但是这种方式严格来说应该是一种梯度加压场景。该场景一般是预先设置几个并发用户的梯度，每个梯度执行几分钟，这样就可以通过一个场景的执行基本上找到应用的最大TPS。在下文场景类型中，我们会详细介绍这种场景。

　　运行时间

　　每个类型的场景其执行时间是不同的。表1为大家提供一个参考值。运行时间是不包含用户的加载时间和退出时间的，即全部用户都在执行的这段时间。

表1 各种典型场景运行时间设置

　　延时方式

　　延时是上一笔请求完成到下一笔请求发起之间的时间间隔。延时在场景中的作用就是为了精准控制TPS，或者降低当前并发用户数量下的压力。而精准控制TPS的目的就是考察应用在特定压力下是否存在性能问题。在某些性能测试工具中提供了三种延时设置方式：

第一种是上一次请求完成后立即发起下一次请求，也就是延时为0。

第二种是上一次请求完成后间隔指定的时间后再发起下次请求。

第三种是在指定时间内完成一次请求，即区间型的延时，这要求我们设置的这个时间要大于交易的响应时间，也就是说要保证交易响应时间在我设置的这个时间的区间内，否则就不能实现精准控制TPS的目标。在这个区间内，交易响应时间无论如何变化，只要不突破我的这个最大区间，那么TPS就是平稳的。

　　在实际的场景设置中，为了实现精准的TPS控制目标，我们选用第三种设置方式。通过不断地尝试与调整，最终能够达到目标TPS。

　　用户终止方式