性能测试方案中一个不错的模板

极客时间中的《高性能实战》课程中，有不错的性能测试方案模板：

 要注意的是，要写出每个场景的业务比例：


然后做4类场景的测试：

 

基准场景必须是容量场景的前奏 。具体怎么做呢？那就是

在基准场景中，我们也要通过递增连续的场景做到最大 TPS。也就是说在基准场景中，我

们要把单接口或单业务压到最大 TPS，

容量场景的最

大 TPS 是指最大的稳定 TPS。

然后来分析单接口或单业务的瓶颈点在哪里。
 

稳定性场景

在完成了容量场景之后，我们就要进入稳定性场景的阶段了。到现在为止，在性能的市场

中，还没有人能给出一个稳定性场景应该运行多长时间的确切结论。我们知道根据业务属

性不同，稳定性场景也有不同的设计思路，可是这样说起来未免有些空泛。所以，我在这

里给出一个稳定性场景的运行指导思路。

在稳定性场景中，我们只有两个关键点：

第一个关键点：稳定性场景的时长。

关于稳定性场景的时间，我经常看到网上有人说一般运行两小时、7*24 小时之类的话。可

是，什么叫“一般”，什么又叫“不一般”呢？作为从业十几年的老鸟，我从来没有按照

这样的逻辑执行过，也从来没有看到过这些运行时长的具体来源，只看到过很多以讹传讹

的文章。

在性能领域中，这样的例子实在太多了，现在我也见怪不怪，毕竟保持本心做正确事情最

为重要。下面我给你解释一下什么才是合理的稳定性场景时长。

我们知道，一个系统上线之后，运维人员肯定会做运维巡检，如果发现有问题就会去处

理。有的系统是有固定的运维周期，比如说会设定固定的 Job 来做归档之类的动作；有的 2021/4/2

系统是根据巡检的结果做相应的动作。

而稳定性要做的就是保证在运维周期之内业务可以正常。 所以，在性能的稳定性场景中，

我们要完全覆盖业务容量。比如说对于下面这张图：

在运维周期内，有 1 亿笔业务容量。根据上面容量场景中的测试结果，假设最大稳定 TPS

是 500，那稳定性场景的执行时长就是：

通过这样的计算，我们就能知道稳定性场景应该跑多长时间，这也是唯一合理的方式。

第二个关键点：用多大的 TPS 来执行。

对此，我看到网上有人提到，用最大 TPS 的 80% 来运行稳定性场景。这里我不禁要问

了，为什么？凭什么不能用最大的来运行呢？

记得我在做培训的时候，有过多次这样的讨论。有人说，之所以用最大 TPS 的 80%，是因

为在执行稳定性场景时不能给系统太大的压力，否则容易导致系统出现问题。

这种说法就奇怪了。既然容量场景都能得出最大的 TPS，为什么稳定性就不能用呢？如果

用最大的 TPS 执行稳定性场景会出现问题，那这些问题不正是我们希望测试出来的性能问

题吗？为什么要用低 TPS 来避免性能问题的出现呢？

所以，用最大 TPS 的 80% 来做稳定性场景是一个错误的思路。

在我的性能理念中， 在执行稳定性场景时，完全可以用最大的稳定 TPS 来运行，只要覆盖

了运维周期之内的业务容量即可 。如