14性能测试场景：如何理解业务模型？

业务模型计算过程针对这一天中的数据，我们将做出以下三个业务模型。通用业务场景模型。就是将这一天的所有业务数加在一起，再将各业务整天的交易量加在一起，计算各业务量的比例。
9 点钟的业务模型。将 9 点钟的业务比例直接拿出来用。16 点的业务模型。将 16 点钟的业务比例直接拿出来用。首先我们看一下通用业务模型。

做为最基础的业务比例，这个可以覆盖大部分的业务时间了。在通用的业务场景中，如果业务团队有给出明确的 TPS 指标，那就有依赖了。但是，如果没有给的话，也不要气馁。我们可以根据系统的运行时段，
计算平均值即可。因为我们这个系统是 24 小时系统，所以我用 24 小时来计算。得到如下值：TPS1=24∗360020000000=231也就是说通用场景中，TPS 不能低于 231。
接着我们看下 9 点的业务模型。计算方法和上面一样，最后得出比例。

我们可以从小时图中看到，9 点的业务量总和有 120 万左右。为了方便，这里我拿 120 万来计算。它的生产 TPS 就是：1,200,000 / 3600 = 333。显然，这个模型下做场景时就不能低于 333TPS。最后看一下 16 点的业务场景。

从小时图中，我们可以看到，16 点的业务量总和有 100 万左右。为了方便，这里我拿 100 万来计算。它的生产 TPS 就是：TPS3=36001,000,000=277显然，这个模型下做场景时就不能低于 277TPS。
但是请注意，像 9 点业务模型中的业务 11，占比达到 30.25%；而 16 点业务模型中只有 8.69%。虽然 TPS 差不多，但是业务比例差别大，这两种业务模型下，对系统资源的消耗会完全不一样。
最后我稍微说一下 TPS 的控制。有了这个计算过程，当我们把这些比例设计到场景中去的时候，一定要注意这些 TPS 的比例在运行过程中，不能发生大的变化。一旦压力发起后，由于各业务的响应时间随着压力的增加发生的变化量不同，就会导致运行过程中业务比例出现很大的偏差。我们做性能测试工程师的，都有过这样的经历。
通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。