如何进行场景设计？
根据之前我们所说的，基准性能场景是为了测试出单业务的最大容量，以便在混合容量场景中判断哪个业务对整体容量最有影响。
今天的场景设计需要说明两个前提条件：
1、这些业务都是实时的业务，不涉及批处理、大数据等业务。
2、因为本篇着重讲场景的设计和具体项目的操作，所以不加系统资源的分析，避免信息混乱。
在这个场景设计中，首先，我们要列出自己要测试的业务比例、业务目标 TPS 和响应时间指标。
在这个项目中，响应时间指标是统一的，就是不大于 100ms。
其实我们在做项目的时候，经常会这样制定一个统一的响应时间指标，这样做也不是完全因为懒，更多的是根本不知道如何定每个业务的时间。但我们性能测试人员要知道，这显然是不对的，因为业务不同，响应时间指标也应该不同，合理的做法是给出每个业务的响应时间指标。下面我们还会遇到响应时间定得不够细致的问题。
基准性能场景
有很多人做接口测试的时候，觉得接口的 TPS 真是高呀，于是就按照最高的 TPS 跟老板汇报。但我们一定要知道的是，接口的 TPS 再高，都无法说明容量场景的情况，除非这个服务只有这一个接口，并且也只为了测试服务，这时就不必有混合的情况了。
首先，我们要知道，每个业务在系统中的最大容量是多少。那么接下来，我们用上面的业务一个一个地做基准，看看结果如何。
业务 1
场景执行时长：17 分钟。
先看 Statistics。
很多人喜欢用这个表中的数据来做报告，特别是 90th pct、95th pct、99th pct。我不是说不能用，但是，我们要先知道这个场景是什么样，再来确定这些值是不是可以用。
从上图来看，TPS 达到 573.24，平均响应时间是 109.83ms，发送字节很少，这里都没统计到，接收字节 966.22KB/sec，这个值也非常低，最小响应时间 43ms，最大响应时间 694ms。
但是！这能说明什么呢？什么都说明不了呀。是好是坏？不知道呀。所以我们还需要看其他图。
我们先看一下线程图。
以每分钟 15 个用户的速度往上递增。
对应的响应时间图是下面这样的。
随着用户的增加，响应时间一直都在增加，显然瓶颈已经出现了。
我们再结合 Statistics 表格中几个和时间有关的值来想想一想，90th pct、95th pct、99th pct、平均响应时间还可以用吗？ Statistics 的平均响应时间是 109.83ms，但是你从响应时间图和线程图比对就可以看到，在不同的线程阶梯，响应时间是有很大差别的。所以 Statistics 中的响应时间都是针对整个场景来说的，然而在梯度加压的过程中，用 Statistics 中的数据是不合理的。
接着我们再来看下 TPS 图：
我们可以从 TPS 图上看到，最大 TPS 能达到 680 左右。我再啰嗦一句，请你不要再用所谓的”最大 TPS 拐点“这样的描述来说明 TPS 曲线。
性能的衰减是逐步的（也有突然的情况，那是非常明显的性能瓶颈了），在最大 TPS 出现之前，就已经可以判断瓶颈是否出现了。
结合上面四个图，我们就有了如下的判断：
- 场景是递增的。
- 压力线程上升到 55（第四个阶梯）时，TPS 达到上限 680 左右，但是明显的，性能在第三个阶梯就已经接近上限了。
- 在压力线程达到 55 时，响应时间达到 85ms 左右，这个值并不高。
除此之外，其他的似乎不需要我们再做什么判断了。
业务 2
Statistics 图：
线程数：
响应时间图：
TPS 图：
基于上面的四张图，我们可以看到：
- 这个单业务的最大 TPS 在 6000 以上。
- 响应时间变化比较小，基本上都在 10ms 以下，但也能明显看出在线程增加的过程中，响应时间也是在增加的。
这个业务由于 TPS 太高，响应时间太短，实在没啥可分析的。
业务 3
Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
- 最大 TPS 将近 5000。
- 响应时间随着用户的增加而增加，在达到 4500TPS 时，响应时间在 6.5ms 左右。
业务 4
Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
- 最大 TPS 超过了 300。
- 响应时间随着用户的增而增加，在达到 300TPS 时，响应时间在 70ms 左右。
业务 5
Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
- 最大 TPS 在 550 左右。
- 响应时间随着用户的增而增加，在达到 550TPS 时，响应时间在 55ms 左右。
业务6
Statistics：
线程数：
响应时间图：
TPS 图：
基于上面四张图，我们可以看到：
- 最大 TPS 超过了 2500。
- 响应时间随着用户的增加而增加，在达到 2500TPS 时，响应时间在 16ms 左右。
有了上面这些单业务的容量结果，我们就可以做一个表格了：
还记得我们前面提到响应时间都不能大于 100ms 吧。
通过测试结果我们可以看到，业务 1 已经接近这个指标了，也就是说这个业务如果在活动或促销期，有可能出现峰值最大 TPS 超过承受值的情况，超过了前面制定的响应时间指标。
有了这些基础数据之后，下面我们就可以设计容量场景了。
容量性能场景
我们希望得到的容量场景在本文的一开始就已经给出。下面我们通过设计线程来得到这个容量场景的结果。
你需要记住我们的重点：
- 场景不断。
- 控制比例。
我们这里只说一个容量性能场景，并且这个场景是峰值业务场景。如果在你的项目中，有特定的业务日，那就要根据业务日的业务比例，重新做一个针对性的场景。
在满足了最开始提到的业务比例之后，我们不断增加压力，得到如下结果。
Statistics：
线程数：
响应时间图：
总 TPS 图：
TPS 细分图：
从上面的结果可以看到，业务 4 和业务 5 的响应时间，随着业务的增加而增加，这显然在容量上会影响整体的性能。
在具体的项目中，这就是我们要分析调优的后续方向。
还有一点请你注意，并不是说，看到了性能瓶颈就一定要解决，事实上，只要业务指标可控，不调优仍然可以上线。这一点也是很多做性能测试的人会纠结的地方，感觉看到这种有衰减趋势的，就一定要把它给调平了。其实这是没有必要的。我们做性能是为了让系统能支持业务，即使性能衰减已经出现，性能瓶颈也在了，只要线上业务没有超出容量场景的范围，那就仍然可以上线。
我们再说回来，从总 TPS 图上看到，在容量测试中，我们仍然测试到了系统的上限。这是一个好事情，让我们可以判断出线上的系统配置应该是什么样的。
在达到了系统上限时，我们来看一个业务的比例
我们可以从上面的数据中看到，业务目标 TPS 已经达到，响应时间也没有超过指标。很好，这个容量就完全满足业务需求了。
但是，如果业务要扩展的话，有两个业务将会先受到影响，那就是业务 4 和业务 5，因为它们的测试 TPS 和最大 TPS 最为接近。这是在我们推算业务扩展之后，再做架构分析时要重点考虑的内容。如果是在实际的项目中，这里会标记一个业务扩展风险。
根据架构，性能测试组需要根据当前的测试状态整理架构的关键配置给线上系统做为参考，并且每个项目都会不一样，所以并不是固定的内容。
配置整理的范围包括架构中所有和性能相关的技术参数。如下所示：
下面我们就该说一下稳定性场景了。
稳定性场景的时间长度取决于系统上线后的运维周期。
在这个示例中，业务 + 运维部门联合给出了一个指标，那就是系统要稳定运行一周，支持 2000 万业务量。运维团队每周做全面系统的健康检查。当然谁没事也不用去重启系统，只要检查系统是否还在健康运行即可。大部分时候运维是等着系统警告的。
那么针对前面给出的容量结果，容量 TPS 能达到 3800（业务 1 到业务 6 的容量测试结果 TPS 总和）。所以稳定性场景时间应该是：20000000/3800 = 1.46 小时。
下面是两小时的稳定性场景运行情况，我在这里只做一下大概的说明。
Statistics：
线程数：
响应时间图：
TPS 细分图：
总 TPS 图：
从上面几张图可以看出，业务 2 和业务 3 对总 TPS 的动荡产生了影响，但系统并没有报错。
这种周期性的影响，你可以去分析具体的原因，由于本篇是场景篇，所以这里不写分析过程，直接给出原因，这种影响是参数化数据周期性使用所导致的，有些数据的关联记录数多，有些数据的关联记录数少，数据库中变化倒是不大，但由于 TPS 过高，表现出来得就比较明显了。
其他的业务都比较正常，也比较稳定，没有报错。
总体业务量达到 27299712，也达到了稳定性业务量级的要求。
这个系统用最大 TPS 能跑下来，业务一直很正常，稳定性目标能达到，为什么不能用最大 TPS 来跑呢？本来稳定性场景就是为了知道会不会由于长时间处理业务而引发潜在瓶颈（像内存泄露是个典型问题）。至于用多大的 TPS 来运行，又有什么关系？只要系统在正常处理，资源没有出现问题，也没有报错，那这个场景就是有效的，目标也是能达到的。