对异步处理的http接口进行性能测试！

小码哥说测试

于 2024-05-23 15:11:40 发布

阅读量719

点赞数 19

分类专栏：自动化测试技术分享软件测试文章标签： http 网络协议测试工具单元测试集成测试 selenium 自动化测试

本文链接：https://blog.csdn.net/jiangjunsss/article/details/139148517

版权

技术分享同时被 3 个专栏收录

1868 篇文章 73 订阅

订阅专栏

自动化测试

1624 篇文章 64 订阅

订阅专栏

软件测试

1521 篇文章 56 订阅

订阅专栏

最近来了新的领导，测试的内容和范畴都变大了，工作内容涉及到APP，线上出现了由于性能引起的bug，不得不进行压测，只能不断的学习了。害，想做一条咸鱼都那么难，找了很多关于接口性能测试的资料，领导一直强调异步接口不好做压测

仔细研究了一下，觉得这篇帖子写得不错，就拿出来分享，如果雷同纯属巧合

以前对接口做性能测试，接口都是同步处理的，请求之后等待响应结果就知道处理结果了，这样只要看这个接口是否异常，如果无异常无报错记录这个接口的响应时间、TPS等性能指标进行分析就可以了，最近在工作中遇到了异步处理的接口，逻辑是只要你请求参数全部合法，即返回成功。

通俗理解一下同步和异步的差别，举个小例子：

同步就是你妈喊你吃饭，你说等一下，然后你妈妈就一直在旁边等着你，专门等着你，等你做完了，一起去吃饭；

异步就是你妈喊你吃饭，你说等一下我忙完了就过去，你妈就走了，该干啥干啥去了，你忙完了，直接过去吃饭。

那么问题来了，这种接口如果还像以前一样单纯的看接口的响应时间，就没有任何意义了，那么如何判断接口的性能呢？

先来描述一下被测系统：

这是一个专门负责发送消息的平台，包括短信消息和设备消息，大概架构如下：整个系统分为前端和后端，前端负责接收客户端的传参，把数据写入数据库并插入消息队列MQ；后端负责发送消息，队列MQ的消费，并更新数据库记录队列消息的消费时间及发送状态；接口全部为异步处理机制

下面以发送接口为例，简述整个测试过程：

制定测试方案

开始性能测试了，说明系统功能已经稳定，无遗留严重bug，此时需要对系统的需求做个调研分析，确定被测系统的性能测试方案，这里可以从需求出发，初步确定性能测试方案。确定测试场景为单接口场景，选取三个调用频率最高的接口来测试，和开发及运维等相关人员确定压测环境、服务器配置等数据，通过压力测试工具jmeter关注响应时间、每秒TPS及错误率，同时使用阿里云监控平台监控服务器内存和CPU使用情况。采用循序渐进增加线程数的方式得到接口的最大处理能力。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

确定测试数据

为了尽量模拟真实场景，需准备不小于并发数百分之20的数据作为压测数据。

压测数据写在excel中

ps：这里有个坑，因为消息系统是给用户发送短信及消息，一不小心可能导致消息发送到真实用户了。

此处有两个解决方案：

让开发处理手机号校验的代码，把代码注释，手机号使用不存在的数字组合即可
开发做挡板，屏蔽调用第三方发送接口

根据测试场景编写测试脚本

共三个接口，https协议post请求

调用接口无需token，因此只需要把入参拼接排序加密签名即可，入参处理方法可以用java写好打包放到jmeter的lib目录，在beanshell中import进来直接调用即可

执行测试

测试脚本调试通过，就可以执行测试了。

按照常规接口的测试方式：

就是从1个线程数开始，每次压测5分钟左右，压测过程中监控服务器cpu及内存占用情况，记录tps及响应时间，不断增加并发数，找到tps随并发数增大的拐点，即得出接口最大处理能力。

但是以上方式并不适用于这种异步的接口，那么如何处理呢？

此处通过查询数据库。当所有请求全部完毕了，查询数据库的发送信息表，检查请求时间字段和发送时间字段，请求时间字记录该请求的调用时间，发送时间字段是后端发送消息后回写到数据库的发送时间，故请求时间字段和发送时间字段的差就是这一个请求的完整的响应时间，可以算出所有请求的平均时间、90%时间，第一条开始请求的时间到最后一条发送成功的时间之差就为持续压测时间，进而通过请求数能够计算出TPS，达到测试目的。