按照测试模型中的交易比例及目标TPS，对每个交易分配不同的并发用户数量，设置不同的延时，同时进行加压，通过多个子场景的不断尝试最终测试出应用能够达到的最优TPS。这个场景比较复杂，一般需要经过多次的测试与调整才能到达测试模型的比例要求。经过单交易负载测试之后我们已经获取了每个交易的平均响应时间，那么由此值我们便可以设置我们的混合负载场景。假设，我们应用的测试指标TPS为100，单交易负载测试获取的各交易响应时间如下：下单0.4秒，查询0.2秒，退款0.5秒，那么要达到100TPS的压力，该如何设置场景？

计算每个交易的TPS

　　下单TPS=100*80%=80，查询TPS=100*19%=19，退款TPS=100*1%=1

确定每个交易的并发用户

　　目标TPS、响应时间、并发用户之间有这样一个关系：

　　目标TPS=并发用户/响应时间

　　如果一个交易响应时间是0.2秒，那一个用户时的TPS就是1/0.2=5。

　　在咱们这个实例中每个交易的并发用户计算如下：

　　下单交易并发用户数量=80*0.4=32

　　查询交易并发用户数量=19*0.2=3.8

　　退款交易并发用户数量=1*0.5=0.5

　　大家看到了，这里出现了非整数的情况，怎么办？对于这种情况我们要进行整数化处理。即我们一般取大于并最接近当前数的整数，3.8我们按4，0.5我们按1。整数化后对应的响应时间也应该发生变化，否则就无法实现目标TPS。整数化再次计算实际的响应时间：

　　查询交易调整后的响应时间=4/19=0.21

　　退款交易调整后的响应时间=1/1=1

　　于是场景设置如下，下单交易并发用户32个延时设置为0秒，查询交易并发用户4个延时设置0.01秒，退款交易并发用户1个延时设置0.5秒，场景运行时间10分钟以上。但是这个场景运行结果可能并不会完全符合我们的预期，因为并发用户相比单交易负载场景已经增加了很多，交易的响应时间很可能会出现明显的延长。比如下单交易的实际响应时间可能会延长到0.6秒，那么实际的TPS将明显下降。如果出现这种情况该如何处理呢？我们推荐使用区间型延时设置，将这个“区间时间”设置的比实际交易响应时间大一些，根据这个时间再计算对应的并发用户量。另外，建议大家建一个excel的表格，用于计算延时和并发用户的值，效果见下表2。

表2 场景设置工具表

　　表2中的列“延时设置”的值是使用公式自动计算出来的，公式为“=并发用户单元格编号/（目标TPS单元格编号*交易占比单元格编号）”。建立这个表之后我们只需手动修改两个列的值就可以方便地计算出每个场景下的每个交易的延时，这两个列就是“平均响应时间”和“并发用户数”。平均响应时间随着并发用户的增加必然会相应地增长，所以在表2中每个场景的平均响应时间数据都是上个场景的执行结果。这样我们每执行完成一个场景，然后就把响应时间的数据填写到下个场景中，然后再修改并发用户数量，并确保延时设置大于平均响应时间即可，如果在测试执行过程中出现平均响应时间大于延时设置时间时需要停止场景重新计算。

　　综上所述，多交易混合负载场景并不是一个场景，而是一系列混合场景的集合。还以上例来说，目标100TPS时我们分析监控结果发现系统各项资源利用率都不是太高，这说明应用还能够承受更大的压力。这就需要我们继续加大压力进行测试。我们可能的场景是150TPS、200TPS等等。那么如何确定我们的压力梯度呢？这就要看系统资源到底使用了多少，如果100TPS时发现系统各项资源使用率在50%左右，我们就可以估计应用的最优TPS应该能够达到150，那么我们下一个场景就是要按150TPS的目标压力去发压，相关的并发用户和延时根据上表进行调整即可。如果不能实现150TPS的压力，那么我们就要减少目标TPS再进行发压，直到测试获取到应用的最优TPS。

　　多交易混合容量

　　容量的意思就是应用能够达到的最大TPS。该场景是和多交易混合负载场景相关联的，即通过多交易混合负载找出应用承受的最优TPS后继续对应用进行加压，直到找到应用的最大TPS。混合容量场景的并发用户与延时调节方式和混合负载一样，在这里就不再赘述了。

　　大并发