性能测试场景：业务模型
性能场景种的业务模型是性能测试工作中非常重要的一部分。而在我们真实的项目中，业务模型跟线上的业务模型不一样的情况实在太多了。原因可能是多种多样的，这些原因大大降低了性能测试的价值。
有人说，就是因为这样才应该直接用生产流量的方式来嘛，这样就不用管业务模型了，直接就有生产的业务模型了。没错，只要你能通过生产流量扩大回放的方式实现压力部分，确实可以不用考虑业务场景了。但这么做的前提也必须是你的生产流量来源是可以覆盖想要测试的业务场景的。
回放的逻辑
上图就是回放的逻辑，如果你喜欢的话，还可以每个业务产品和基础架构的层面做接口的回放，甚至可以直接在数据库中回放SQL。而这些手段，都是为了模拟生产的业务模型。
这里我要批驳一个观点，就是有人觉得只有通过生产流量回放方式，才能真实的模拟了线上的流量。事实上，这个观点是偏颇的。前几天有个性能测试工程师问我一个流量回放过程中遇到的问题，谈到为什么要用流量回放。他说他们领导觉得这个最新潮最直接最正确，但实际上他得到的那段业务流量根本不能完全覆盖想测试的场景，最后折腾了一个月也是无功而返。
我知道，现在有很多人在各种场合说，可以直接在生产过程中，通过业务统计动态统计出业务场景，并实时实现到性能平台中去。这当然是一个很好的路子，但这个路子需要完整的技术实现，并且在不同的企业中，这种方式难就难在创建业务模型的统计算法，此外还要有高层领导支持，才能真正实现完整的逻辑。
所以在今天的文章中，我想写的是最朴素的逻辑。那就是从生产数据统计，怎么转化到具体的场景中的业务模型。明白了这个逻辑之后，不管你是用生产流量回放，还是用实时业务量停机，还是线下业务量统计，你会发现原理都一样。
这是一个真实的案例，我已经把所有的业务名都替换掉了，同时对业务量级也做了降级调整，但这并不影响描述获取业务场景的完整性。
原系统的量级如下图所示：
这里我降低10倍处理。
生产数据统计
首先我们从生产环境取出数据，粒度到秒级，取出所有业务的交易量数据。
业务量级按天统计的生成图如下：
为什么要取这一段时间的数据呢？答案很简单，因为这一段时间完整的体现了这个业务系统的峰值数据。从这样的业务数据中取业务量最高的一天，最大的业务量是2000万左右。
注意，我这里说的业务量最高的一天，并不是说我们的业务场景只从这一天产生，还有别的时间，虽然业务量不多，但是业务比例完全不同，这也是要取出来的场景，所以这个统计数据到业务模型的分析过程会比较细致。我们把这一天的逻辑说完后，你就会明白其他的场景获取方式。
接着，我们再以小时为单位统计出业务量比例。如下图所示：
从上图显然可以看出哪个小时的业务量最大，那就是9点.但是，你不要忘了，在16点的时候，明显蓝色表示的那个业务量是大于9点时的业务量的。这个也是要取出来的场景。
如果需要更细的数据，我们可以以分钟为单位看一下这个小时内的业务量分布。
如果你的业务有必要从分钟或者秒来看的话，就可以按分钟或秒来取场景比例。我们今天的这个案例中，取到小时就已经足够。因为我要的是业务模型，而不是生产TPS量级。
另外，既然说到了这里，我再把生产TPS量级的统计说一下。有了上面的分钟比例，就可以很容易统计出生产环境中每个业务的最大TPS了。这里得到的TPS将是最有效的测试是否通过的SLA指标。
下面我们再以小时为单位做百分比图。
为什么要做百分比图呢？因为这个比例才是我们在性能场景中设置的TPS比例，是最直接有效的比例。
业务模型计算过程
针对这一天种的数据，我们将做出以下三个业务模型。
- 通用业务场景模型。就是将这一天的所有业务数加在一起，再将各业务整天的交易量加在一起，计算各业务量的比例。
- 9点钟的业务模型。将9点钟的业务比例直接拿出来用。
- 16点的业务模型。将16点的业务比例直接拿出来用。
首先我们看一下通用模型。
我们将上面的0%的业务全部删掉，再计算一次百分比，得到测试场景中的业务比例。如下图所示：
作为最基础的业务比例，这个可以覆盖大部分的业务时间了。在通用的业务场景中，如果业务团队有给出明确的TPS指标，那就有依赖了。但是，如果没有给的话，也不要气馁。我们可以根据系统的运行时段，计算平均值即可。
因为我们这个系统24小时系统，所以我用24小时来计算。得到如下值：
TPS = 20000000 / 24 / 60 / 60 = 231.48，也就是TPS不能低于231。
接着我们看下9点的业务模型。计算方法和上面一样，最后得出比例。
我们可以从小时图中看到，9点的业务量总和有120万左右。为了方便，这里我就用120万来计算。它的生产TPS就是：1200000 / 3600 = 333。显然，这个模型下做场景时就不能低于333TPS。
最后看一下16点的业务场景。
从小时图可以看到，16点的业务量总和有100万左右。这里我们就拿100万来计算。他的生产TPS就是：1000000 / 60 / 60 = 277 TPS 显然，这个模型下做场景就不能低于277 TPS。
但是请注意，像9点业务模型种的业务11，占比达到30.25%；而16点的业务模型中只有8.69%。虽然TPS差不多，但是业务比例误差大，这两种业务模型下，对系统资源的消耗会完全不一样。
TPS的控制。
有了这个计算过程，当我们把这写个比例涉及到场景中去的时候，一定要注意这些TPS的比例在运行过程中，不能发生太大变化。一旦压力发起后，由于各业务响应时间随着压力的增加发生变化量不同，就会导致运行过程中业务比例出现很大的偏差。
我们做性能测试工程师的，都有这样的经历。通常在LoadRunner里，会用pacing来控制TPS，而Jmeter，则会用Constant Throughput Timer来控制TPS。
总结
在这一篇中，我描述了业务模型的来源和计算过程。其实就是一些常规的求和平均计算的，只要判断出哪一段业务是我们需要的就可以了。
另外，我也强调了，不管用什么炫酷的手段来实现生产环境的流量模拟，最终目标是实现和线上比较接近的业务模型。不是说一定要用生产流量回放才是正确的，只有适合自己企业的手段才是最正确的。
问题
为什么业务比例对性能场景如此重要？以及如何在执行场景过程中控制TPS比例呢？
第一个问题我认为业务比例越趋近生产环境得到的性能数据越真实，生产流量的回放我理解的核心目的也是为了真实的覆盖所需要测试的性能场景，如果业务比例跟真实环境差距很大，那么得到的数据是没有意义的
第二个问题控制TPS比例需要根据线上的统计得到每个服务TPS的峰值及范围，不同的天数和时段TPS是不同的，需要根据线上的TPS的比例去测试系统的资源占用和性能指标，这样才能够真实的反应系统的性能情况，不论做系统当前性能测试还是未来系统的容量规划都是有意义的