性能场景之发起策略

过年过懒散了，写文章都不知道从哪里开始了。

今天打开电脑发现还有几个页面没关。并且是和性能场景设置相关的。

于是想想还是写点东西记录一下，以免以后忘掉了。

有很多时候，我都有这种感觉。刚看到一个东西的时候，想起来应该写点东西记录下一个知识点。但是又觉得过于常识了，就觉得不值得一写。

过了一段时间之后，又会碰到有人问同样的问题，想想还是写一下吧。

性能场景应该说是在性能测试中非常关键的一个环节。

但是在我培训过的学员及公司之中，还是发现有很多人并不是非常关注性能场景中的细节。

今天就只写一个地方，就是发起策略。发起策略多种，设置也是五花八门。比如说如下几种（用jmeter举例，其他工具仅配置方法不同）。

发起策略一：

在这个策略中共有100线程（在loadrunner中称为vuser），每30秒增加10个用户，且递增的时间间隔为6秒。也就是说，这30秒内的10个用户是以每次2个用户增加的；
每增加10个用户之后，持续60秒；
停止线程的时候是每秒停5个用户，直到停完为止。
场景在一开始启动时，并没有启动线程，也就是说在前6秒内是没有线程启动的，6秒后2个线程启动。

发起策略二：

在这个策略中，我们可以看到如下内容：

发起策略三：

这个策略是：

举这三个发起策略为例吧。因为比较典型。什么时候应该用什么样的发起策略呢？这才是关键的问题。

首先，要定义的是测试的目标。如果是在系统的最大容量并不清楚的情况下显然第一种发起策略最为合理，因为在压力逐渐增加的过程中，可以看到响应时间和tps之间的关系。

那么第三个发起策略和第一个又有什么区别呢？

之所以列出第三个策略是因为第一种使用的人非常少。而第三种相对比较多。目标和第一个是一样的。只是这个时候要把握好递增线程的幅度。

我建议的是在不清楚系统最大tps的情况下，最好使用第一种策略。因为使用第三种，可能需要反复试好几次。

第二种发起策略又有什么讲究呢？我碰到使用第二种策略的人是比较多的。并且大部分是不知道这种策略带来的结果是什么。

通常情况下，这种发起策略只用在秒杀、竞拍之类的场景中。有人说应该用集合点来实现这样的策略。请注意，如果不是在分析了具体场景之后，明确知道应该用多少的压力来做这样的场景，最好不要用集合点。

这里面要有个计算的过程才可以。

有人喜欢用第二种发起策略来实现100、200、300、400这样单个场景递增的方式。其实在实际的应用场景中，这是短暂出现的场景。所以这种方式仅是在测试峰值的那一刻，这种方式在实际的性能场景中其实不是那么有必要，应该说过于简化了本来的应用场景。

后面如果有比较好的实例，我再接着写这个话题。