13丨性能测试场景：如何进行场景设计？

我们在前面屡次强调了场景的重要性，今天终于到了要把实际场景拿出来解析的时候了。

在本篇文章中，为了保证数据的连续性，我用之前的项目资料来作明确地说明。同时为了模糊关键业务信息，以及让场景的描述更通用性，我会把所有的业务名隐去。

根据之前我们所说的，基准性能场景是为了测试出单业务的最大容量，以便在混合容量场景中判断哪个业务对整体容量最有影响。

今天的场景设计需要说明两个前提条件：

这些业务都是实时的业务，不涉及批处理、大数据等业务。

因为本篇着重讲场景的设计和具体项目的操作，所以不加系统资源的分析，避免信息混乱。

在这个场景设计中，首先，我们要列出自己要测试的业务比例、业务目标 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 曲线，我在第 6 篇文章中也说过，性能的衰减是逐步的（也有突然的情况，那是非常明显的性能瓶颈了），在最大 TPS 出现之前，就已经可以判断瓶颈是否出现了。

结合上面四个图，我们就有了如下的判断：

场景是递增的。

压力线程上升到 55（第四个阶梯）时，TPS 达到上限 680 左右，但是明显的，性能在第三个阶梯就已经接近上限了，

在压力线程达到 55 时，响应时间达到 85ms 左右，这个值并不高。

除此之外，其他的似乎不需要我们再做什么判断了。

也许这时候你会想问，那么瓶颈在哪里呢？总有人看到现象就想知道结果。但是这一次呢，我不打算满足这样的好奇心，因为本篇只是为了讲场景的逻辑，而不是瓶颈的分析。哈哈。

业务 2

从业务 2 开始，我们不做啰嗦的数据解释了，只说明一下关键点。我们看图。

Statistics 图：