大家好，我是小码哥，最近工作有点忙，一直在实现压测自动化的功能，今天来分享一下实现思路

我所在的业务线现在项目比较少了，所以最近一个月我都没有做业务测试，需求开发完后RD直接走免测就上线，无需QA介入测试

而Q3组里定了一个工作量很多的技术Topic，老板期望进一步实现端到端交付，从Server、FE、客户端单独进行功能测试，转变成只有客户端测试，通过测试客户端和嵌入在客户端上的前端页面来覆盖Server的业务逻辑，从而减轻整体QA的人力消耗，说白了就是降本增效

要想实现完整的端到端交付，意味着许多人工的工作，需要进行自动化，并且有合理的数据指标表明某环节达到通过标准（这里指准入标准，准出标准）

研发测试流程一般会经历如下阶段：需求发布评审-》交互设计评审-》开发技术评审-》测试用例设计评审-》需求准入-》需求测试-》需求准出-》上线/发版

准入标准指RD可以将改动的代码合入到代码库的标准（数据指标有可以卡单元测试增量代码行覆盖率等），准出标准指改动的代码可以上线或者发版的标准（数据指标有测试覆盖率等）

• 项目各阶段规范制定（含通过标准）

• 测试用例自动生成（分为两部分：给RD自测的准入测试用例，QA测试阶段要的测试用例）

• 测试环境自动部署（提测后根据提测分支自动部署测试环境）

• 压测自动化能力

本篇文章只谈压测自动化如何进行实现

日常压测步骤

洋子目前都在做服务端测试，日常测试工作主要就是接口测试，通过CR开发写的代码、后端日志、查数据库或者查Redis数据找Bug

虽然看开发的代码对于从来没有看过代码的同学来说比较困难，新手往往看不太懂复杂的代码逻辑，但在一个岗位已经快4年了，我发现后端写的代码大部分其实也是在CRUD，对于我来说也没有什么成长性了

所以我也在寻求工作的转变（当前我的业务测试经验已经很丰富，想着进一步提升自己的开发水平，也方便后续自己跳槽），正好我所在的业务线对于大项目都会涉及压测（就是常说的性能测试），压测相当耗费人力，要完成整个压测任务，通常需要执行下面几个步骤：

• 制定压测方案

• 准备压测数据，配置压测词表

• 执行压测前，发送压测风险通告

• 执行压测中，观察压测平台监控

• 完成一次压测任务，查看本次压测任务的报告，问题分析及调优

• RD修复压测问题后进行复压，完成整个项目的压测后，发送项目压测报告

制定压测方案

压测方案主要包含压测对象（如果是服务端的压测，一般就是对API接口进行压测），压测场景，压测数据，压测域名信息，接口参数，发压的目标QPS等

对于压测场景：一般指压测的方法，压测时候需要确定是单接口发压，还是链路级别发压，另外要确定都是读接口发压还是有写接口发压，对于读写接口混合压测，根据情况先压写接口生产数据，再压读接口（压测之前建议了解清楚业务逻辑，具体情况需要具体分析）

链路级别发压：一般指有关联性的接口按照一定的顺序进行发压，比如现在我进入了抖音直播间，进直播间依次调用了A，B，C三个接口，那么要压测这个进场链路，尽可能模拟真实场景，就要同时对A，B，C三个接口同时发压，如果只是单独压测A或B或C接口，就可能导致压测结果和实际结果不符

构造压测数据，配置压测词表

对于服务端的压测，压测数据一般指动态接口请求参数的数据压测数据（比如账号id信息，cookie等）一般可以提前准备存储在一个文件当中，在压测时解析文件，读取其中的动态参数替换到原本的接口请求参数

那么压测词表又是什么呢？

我们内部有个通用压测平台，配置好压测词表和压测场景基础信息（如压测域名）后就可以发压

压测词表：如果是压测HTTP协议的后端接口，压测所需的元数据,每一行代表一个请求,包含请求的 method、path、params、header、body等等

以上数据构造方式还是有一些不足，因为压测数据是人工通过写脚本的形式构造出来，跟线上的数据还是有差异，为了进一步模拟线上压测数据构造还可以根据采集线上Nginx日志文件把压测数据存入到数据仓库，构造压测词表时，从数仓中筛选出相应的数据，作为压测所需的词表文件，当然要想实现这些，需要有公司内部基建来支持

还有些同学是用Jmeter去压测，那么关于压测数据的构造，Jmeter支持压测动态参数化数据（支持配置CSV文件，用Csv Data配置元件来进行参数化），以及正则表达式解析多个数据，压测词表也可以通过配置HTTP请求来达到同样的效果

压测风险通告

在压测前，要发送压测风险通报，因为压测的接口如果有依赖的下游，在压测过程当中可能因为流量太大，影响到下游服务，可以拉一个压测群，把对应服务的负责人都拉进去，然后压测前发送压测风险通报

压测中观察监控&压测问题分析、调优

压测报告查看&发送

完成单次压测任务后，一般需要根据性能指标（实际QPS和目标QPS，服务可用性，错误码，平均响应时间等）结合后端日志做出判断是否有问题，发送对应压测报告

如何实现压测自动化

我们先根据上面的压测步骤总结下哪些地方需要人工执行，哪些虽然要人工执行但可以自动化，哪些要人工执行但自动化的成本相当高，先实现成本较低的部分

按照我们的老板的话，所有的人工操作都可以自动化，虽然听着有些激进，但还是有一定道理

根据压测的各个步骤来进行实现成本分析

• 制定压测方案（需要人工操作，自动化成本高）

• 准备压测数据，配置压测词表（需要人工操作，自动化成本高，压测配置平台暂无相关接口）

• 执行压测前，发送压测风险通告（自动化成本低，可用机器人在群聊自动触发）

• 执行压测中，观察压测平台监控（自动化成本低，观察监控可配置熔断策略，无需人工再观察）

• 完成一次压测任务，查看本次压测任务的报告，问题分析及调优（生成压测报告自动化成本低，问题分析需要人工操作）

• RD修复压测问题后进行复压，完成整个项目的压测后，发送项目压测报告（复压部分可以自动化为，复制此前的压测任务，降低配置成本）

我画了一张设计压测自动化的设计图，见下图

对于新增接口压测还是需要前置人工配置压测词表，如果有相关接口，还可以结合白盒分析技术自动化生成压测词表，实现压测全流程自动化

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。