昨天写的那个发起策略是对单个业务来说的。

每次在做项目和做培训的时候，我都说起过，要先做基准测试。

之前我看到有人把基准测试定义为脚本的基本验证。从概念上说，这种描述是完全错误的。这个问题可以留待后面再展开来说明。

对于多业务脚本混合的场景来说，每个业务脚本的设置就成了必然要考虑的事情。

所以在这之前需要的是对单个业务特点进行分析，分析到可以设置出符合真实业务场景为止。这一点非常关键，非常关键。 如果做不到和真实业务场景符合的话，性能测试分析优化的整个过程也仅是查查系统的代码问题、环境问题、配置问题、数据问题、架构问题等等。

有人说，这样已经足够了呀。

可是，性能项目的实施仅仅是为了找问题吗？即使找出问题，能让系统支撑得住真实业务场景吗？这个问题是大部分做性能测试的人不敢回答的。

所以场景设计的重要点在于可以把真实业务场景重现出来，进而分析系统容量是否满足业务要求。

混合场景在不同的工具中有不同的设置方法。

对于LoadRunner来说，在设计思路上，它对场景的设定是全局的。有种所有业务都由我掌控的感觉，就是很霸道的全局设置思路，每个业务脚本可自己发挥的空间。

我是很认可这种设计思路的，就是对整个场景要有明确的掌控感。

只是缺乏灵活性。

还好在LoadRunner中有Group可以弥补这个灵活性的欠缺。

对Jmeter来说，各个设置都是松散的，线程组的设置也都是单独的，想怎么玩怎么玩。

所以对混合的场景设置来说，Jmeter这样的工具才是对个人素质要求更高的。

像上图中所展示的，每个线程组可以有不同的发起、持续、停止策略。

不管工具上如何设置，最核心的内容还是如何把真实场景复现出来，而这一点是工具不可能告诉你的。不管是现在的云性能测试工具还是单独的性能测试工具，在这些内容的深化上都存在着很大的发展空间。

性能测试之所以人在其中的作用很大，也就是在这些灵活的部分。

之前我看到有些自研发的工具中给一个简单的脚本，即可以发出上万上亿的请求，并且称之为场景。那是非常片面的一种场景，或者说目标不是复现真实业务场景。

后面再写具体的业务场景到性能测试工具场景的转化过程。

在细节的控制中才见真功夫。

性能是一门艺术。