极客时间中的《高性能实战》课程中，有不错的性能测试方案模板：
要注意的是，要写出每个场景的业务比例：
然后做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 来运行，只要覆盖
了运维周期之内的业务容量即可 。如
