api压测工具_ZAT掌门性能压测巡检系统实战和落地

项目背景

随着业务拓展，对于接口性能的要求也在上升，各部门也开始针对部分慢接口进行优化，从测试角度针对这些优化需求进行测试时不仅要保证对应接口的功能正常使用同时也要验证接口优化成果。在日常的开发工作中一些后台服务配置的改动也会对接口的性能产生影响，我们急需要一套性能压测巡检平台，对平时接口服务的技改，后端配置的优化进行持续的性能验证。

项目日常痛点

1.测试与开发都无法确定这次改动优化程度如何，与之前比较究竟提升多少性能。只能验证相关功能正常。

2.测试不清楚开发优化接口用了那些方法需要观察那些指标。

3.优化接口的改动与新增接口是否存在性能bug无法确定。

为了清楚的展示每次优化的成果，对新上线的接口检查是否存在性能bug。基于目前的zat自动化平台开发了性能压测功能。

ZAT性能压测巡检实现方法

1.ZAT性能巡检平台实现机制介绍

①平台后台使用jmeter执行自动化case本身就支持对于后端接口的性能压测，通过对平台的改造可以快速实现在平台上对于接口性能压测的功能。而不需要重新开发一套工具。

②性能压测使用的case可以直接复制自动化case，修改几个变量的配置可以直接用于性能压测。节省编写压测用例的时间，同时使用自动化用例还可以模拟用户使用场景。

③压测结果通过平台读取直接存入数据库，可以对多次性能压测数据比对，接口优化时也可以通过历史数据来比对是否有优化。

2.后期还需要解决的问题

Jmeter运行压测时占用系统资源多，同时目前针对uat环境进行压测大部分服务只有1台机器，为了放置多部门压测时对公共服务的调用影响到接口性能的数据。所以现在设置成同一时间只允许运行1个压测job。其他端可以看到当前那个组在压测状态和进度。

之后会采取2种修改改进这个问题：

①采取分布式压测，各组可以自己提供压测机器通过slave的方式分担压测压力。 ②等服务端接入docker后，通过各种策略将请求发送到对应容器。避免多个部门压测同时调用同一个公共服务导致影响到性能数据 ZAT性能压测巡检平台实现架构图

ZAT性能压测巡检平台流程图

目前zat自动化平台后端使用jmeter来执行case。基于原有功能在之前的基础上加入jmeter自身线程组与压测所需的csv数据文件的设置进行改造，实现了压测用例的生成，执行。通过对jtl文件中各性能数据的计算获取接口相应时间，吞吐量，95线，99线等数据，同时调用grafana接口获取压测时对应服务器的内存，cpu和负载数据。汇总收集到的数据存入数据库。用来跟历史数据或者之后的数据进行比对。

ZAT性能压测巡检平台的实现 ZAT性能压测巡检平台执行压测的流程如下

API信息设置

压测中需要关注对应的服务器的内存 CPU所以要在对应压测case所使用的API信息中增加对应的APPID与需要压测的IP地址

压测Case的生成落地

1.线程组设置

为了测试接口性能，需要模拟大量用户发送请求的场景所以在自动化case的基础上增加了对线程组数据的设置，通过这个设置可以模拟大量用户访问。

a.普通线程组(普通压测设置) 线程数代表起多少个线程发送请求； Ramp-up代表多少时间内发送完成； 循环次数代表每个进程循环发送多少次； 对应jmx模板实现代码如下：

 1{% if test_group.type ==  'normal' %}

b.梯度线程组(模拟梯度加压) 线程数代表总共起多少线程； 持续时间代表启动的线程总数达到最大值之后，再持续运行60秒； 初始进程代表设置最开始时启动多少个线程； 上升梯度与时间代表每隔多少时间启动多少进程，下降梯度与时间同 理 对应jmx模板实现如下：

 1{% if test_group.type ==  'step' %}

2.Csv文件设置(非必填)

考虑到许多接口的数据会存入redis，有时候使用固定的数据对接口进行压测时接口直接从redis读取数据无法模型正常用户流程，所以通过绑定csv文件去切换变量(账号，id等)模拟不同用户发送请求

Csv数据设置

CSV文件会上传到服务器抱错 并且生成压测用例时会绑定到对应计划中变量名对应jmeter从csv文件中取值时对应列的数据对应的参数名称用逗号分割

Csv存储代码实现

 1

Csv插件模板实现

 1{% if test_group.CsvPath !=  '' %}

3.Case选择用例列表自动筛选压测用例目录下的用例选择对应用例创建压测计划

压测执行

1.压测执行代码实现

1

2.压测执行前端展示

压测实时监控

压测完成后从对应服务器的grafana接口获取服务器信息实现实时监控

 1

压测时实时数据展示

压测时服务器性能数据实时展示

压测报告比对结果的实现

压测报告比对代码

 1fillColor: 

后端比对数据实现

 1

前端判断数据是否超过20%阈值修改颜色展示

通过结果的比对，我们可以非常清晰看到本轮技改或者优化配置，性能提升多少还是下降，也能方便的查看到各种资源池的比对。

另外，以每次压测的结果作为下一次比对性能基线，从而推动性能优化工作持续进行。

本文作者

韩盛，7年测试经验，擅长性能测试，自动化测试。熟悉java, python。现任职掌门1对1测试开发工程师。

刘万红，多年互联网大厂测试经历，现任职掌门1对1研发部测试经理 擅长接口/性能/自动化等各种测试平台开发。