性能测试场景的设计方法，2024年最新面试学习

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

参数准备

在做性能压测脚本时我们需要准备参数化数据，很多人觉得做性能测试几条数据就够，不需要大量数据做性能测试，这样就会导致压力与真实生存环境不一致，比如，几十条数据操作出千万级乃至亿级业务，这样压测出来的场景可信度就不好说。那么到底多少参数设置合理呢？

要回答这个问题需要确定参数化用在什么场景，因为场景不一样，参数化数据也不一样，假如不考虑场景情况下，100个线程，TPS 为800，系统运行1小时，数据类型、限制条件和数量计算方式如下：

假如把场景考虑进来我们就根据实际业务场景来分析用到什么样的数据，以便计算参数化数据量，这里的数据包括重复与不重复的数据，这里用我司统一登录做举例说明，对于登录业务需要两个参数一个是账号，一个是密码（这不考虑通过验证码登录）账号与密码必须可登录系统的否则不能完成后续业务操作，很显然不同人一定用不同账号登录。

➢ 场景一

我们在做脚本的时候，有多少线程就配置多少个用户，让每个线程用同一用户循环执行业务操作，但是这样的参数配置只能满足特定业务场景，比如早上登录后一直不退出，一直带着 token 操作业务，到下班退出系统，这样的场景我们有多少线程就需要准备多少用户数据。

➢ 场景二

对于一个电商系统按上面参数就不可取，因为一个账号不停购买商品这样的行为完全不符合真实场景，这时候我们应该怎么办呢？在这样的场景中，我们需要考虑TPS 和持续时间，用户数据计算方式参考：

➢ 场景三

假如一个线程可以循环使用固定参数，在这情况下我们需要根据实际业务判断，比如100 压力线程情况下，我们准备 1000 条数据，我们就可以让每个线程用不同的 10 条数据。这样的场景没固定条数限制，只能根据实践业务判断，但是在配置这个参数之前还需要考虑参数是什么类型，如果是可循环的数据，那么它在真实性能场景非常少，也就是说只使用一条或者几条测试数据真实场景基本没有。

参数化数据

知道参数用多少后，还需要解决参数化数据从什么地方获取，这一步目的是确保参数数据是有效的，一般我们参数化数据来源两个方向，一个是后台数据库存在的，一个是数据库不存在通过压力工具造出来的数据。

总之参数化数据来源需要确保数据的有效性，这些数据需要满足下面两个条件：

✓    满足生产环境数据分布

✓    满足性能场景中数据量的要求

对于一个系统来说，参数化数据是否合理，会直接影响压力测试结果是否有意义。如果压力工具使用的数据量少，那么那么应用服务器、缓存服务器、数据库服务器等都将使用少量的缓存来处理，导致不能把后端各类服务器的缓存占用到真实场景中应该有的大小，所以在这种状态之下是测试不出来真实场景下的压力。

对数据库连接的存储设备来说同样也有影响。如果数据量少，则相应的存储的 I/O 使用就少。参数取得过多，对系统的压力就会大；参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。

如果参数来源于数据库，我们通常要检查一下数据库中的数据直方图。对于直接从生产上拿的数据来说，数据的分布更为精准。但是对于一些在测试环境中造的数据，则一定要在造数据之后，检查下数据分布是否与生产一致。有上面准备后，就可以开始做基准测试，我们在做基准测试需要注意两个点：

我们在实施中什么时候基准场景结束呢？或者到压到什么情况下就可以结束基准场景呢？一般压测过程中接口调用系统资源使用率到达90%或者完全把系统资源使用完毕就可以停止基准场景，注意遇到性能问题需要调优确保资源充足使用，以达到 TPS 还有响应时间是最合理。

容量场景

对于容量场景来说就是把之前基准场景所有接口按一定比例组合起来一起执行，还有做容量场景的目的是要回答“线上容量最大能达到多少”的问题。这里有个问题就是接口与接口间的比例怎么定？在压力工具中又怎么配置？如果不能解决这些问题我们就没法做容量场景设计，可能有些同学就说，直接把接口全部放到一个场景按1倍、2倍、3倍等倍数直接跑就行，没有必要考虑每个接口比例，直接跑个最大值就行，但是这样场景与实际场景有差距，跑出来的场景脱离真实性，那么我们应该怎么设计呢？还有一个问题就是容量场景什么时候停止？

首先我们可以抽取生产日志，相信每个公司都有日志系统，如果没有日志系统可以使用 awk 命令去抽取日志，还可以使用 ELFK 来抽取日志，有上面数据后，就可以梳理业务逻辑。

我司可以通过 lambda 平台可以获取被压测日志，通过检索条件获取我们想要一段时间的接口数据：

如果没有这样的系统我们可以在 Nginx 日志中获取相关数据， 可以通过写 python 脚本处理也可以使用 shell 命令获取我们想要的数据，我们需要数据格式为：

这样我们就可以知道，每个时间段内每个请求的数量，也就可以得到相应的业务比例了。

如果是 ELFK 抽出生存日志大家可以自己安装一个这样的环境配置后，设置相关条件抽出上面数据对应关系的数据类型。

注意：如果出现某个请求的高并发时间点和其他的请求不在同一时间点，就一定要做多个场景来模拟，因为场景中的业务模型会发生变化。

假设我们通过上面步骤就能得出被压测接口的调用量与请求比例，也就可以拿某请求的数量除以总请求数得出每个接口的比例,这里使用一个表格做说明（注意里面数据是假设出来）：

这里总结下获取生产数据比例步骤：

请注意，上面的业务场景在实际的项目业务统计过程中可以有多个。这个思路可以解决任何性能场景和生产场景不一致的问题。有业务比例后接下来我们需要梳理业务场景，用场景覆盖业务比例，场景比例应该怎么设计呢，大家可以思考下，设计几个场景能覆盖上面接口业务比例，这里就不讲解，大家自己思考思考。

用 JMeter 里面，会用Throughput Timer来控制TPS。

关于 Throughput Controller  控制器怎么场景比例，大家可以查询资料就能解决。

有上面业务比例后，我们可以思考下容量场景在什么情况下结束呢？我们在做容量场景时需要确定一个目标，否则就没有结束时间点。大家是否还记得我们在业务比例分配的时候是按一个数据总量分配给每一个接口做比例，这个总量就是我们容量测试的目标。

稳定性场景

我们在前面提到，容量场景是为了看系统所能承受的最大容量，而稳定性场景主要看的是系统提供长时间服务时的性能稳定性，观察系统在长时间运行过程中出现的累积效应。因此，运行时长就是稳定性场景中非常重要的一个指标了。

这里需要明白稳定性运行时长不是固定的，它取决于业务系统的具体应用场景，那么应该怎么计算稳定性时间呢？这里提供一种计算执行时间计算方法。

假设你根据生产系统统计出，在之前的运维周期中，有6千万的业务容量，而在容量场景中得到的最大TPS有1000。那么，我们就可以通过下面这个公式来计算：

稳定性运行时长=6千万(业务累积量)÷1000(TPS)÷3600(秒)≈16(小时)。

不管是什么样的系统，要想运行稳定性场景，都得确定一个业务累积量（一时间业务总量），我们在执行的时候直接用最大TPS来运行，如果一个系统在最大TPS状态下正常运行，才能验证系统能否经得起考验。

异常场景

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
b （备注软件测试）**
[外链图片转存中…(img-ZYQr3S39-1713550783639)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！