一文2500字从0到1实现压测自动化！

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

我所在的业务线现在项目比较少了，所以最近一个月我都没有做业务测试，需求开发完后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请求来达到同样的效果