用了这个API协作调试工具,忘记了postman

我如何接触到的 Apifox

今年三四月份的时候,公司已经上线的项目,发现有部分接口存在重复提交的情况,接口也没做好幂等,导致数据库落下了大量重复数据,于是我就开始优化接口,加了redis分布式锁和一些防重校验,好了,背景介绍完毕。

锁是加上了,但是吧,要想测试就需要模拟压测环境,这个时候如果完全依赖测试同事,很显然不是我的风格,本着宁可麻烦自己也不麻烦别人的原则(减少扯皮,节省时间),于是想要自己做并发测试,看一看锁有没有效果。

刚开始先想到了JMeter,毕竟也在测试那多多少少了解过,但是当我安装完准备使用的时候,发现配置很复杂,即使我叫来了测试同事,也很难讲的明白,于是乎我就在网上搜索的时候,发现了 Apifox。看了这款产品的定位:Postman + Swagger + Mock + JMeter。秒啊,立马安装一个。

开始使用时感觉比较好的功能

1、所有数据同步在云端,即使更换电脑,也可以通过浏览器使用(安装插件即可); 2、定义好API文档,就可以开始调试、Mock、自动化测试,非常方便; 3、区分测试环境,因为我的项目多而杂,定义多套环境,免去了频繁更改接口上下文的时间;

<img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3d02e8157a8944a4bd451693b8b5e059~tplv-k3u1fbpfcp-zoom-1.image" alt="" width="30%" />

4、API文档直接生成在线分享链接,方便了与其他同事共享信息,要比口述来的更加高效; 5、通过数据导入,可将项目的所有接口一次性加载进来,导入数据模型后,还可以根据数据结构直接生成接口入参;

<img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b841d0ff0f164aa18b1843538f73d6df~tplv-k3u1fbpfcp-zoom-1.image" alt="" width="30%" />

......

因为自动化测试的压测能力觉得这个工具很好

还是想说一说自动化测试的模块,测试用例可以直接从已有的接口文档导入,如果需要批量测试,可以通过导入csv文件批量导入测试数据,并且自动生成测试报告。

<img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d1e0263b38b04206b4fa7ebdbd0e348f~tplv-k3u1fbpfcp-zoom-1.image" alt="" width="30%" />

对于我需要的压测场景,只需要简单的配置循环次数、线程数、间隔停顿就可以实现,比如我需要测试同一时间的并发场景,只需要配置间隔停顿为0毫秒,就像这样:

<img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/486eeae9b2564215a1508cb71764d57f~tplv-k3u1fbpfcp-zoom-1.image" alt="" width="30%" />

这极大的节省了我的调试时间,使我在自测阶段就可以规避大部分的问题,最终提交给测试时就已经是一个完成度很高的接口。我顺便把这个工具推荐给了测试同事(顺便好秀了下操作),不会用的地方看一看官方提供的帮助文档,还是很容易上手的。

和之前工具的对比,以及对Apifox的建议

之前使用过几款API调试工具,Postman等,它们给我的感觉是大同小异的,可以满足基本的接口调试工作,但是并没有我觉得很亮眼的功能,当然也有可能是我还没有接触到比较高级的操作,但是吧,一款优秀的软件,首先上手门槛应该是低的,拥有很友好的界面,很详细的文档,以及和谐的沟通社区,这些我都在ApiFox上感受到了。

下载地址:www.apifox.cn

点赞
收藏

评论区

加载中...

相关推荐

Redis 做接口限流

Redis除了做缓存,还能干很多很多事情:分布式锁、限流、处理请求接口幂等性。。。太多太多了~今天想和小伙伴们聊聊用Redis处理接口限流,这也是最近的TienChin项目涉及到这个知识点了,我就拎出来和大家聊聊这个话题。1.准备工作首先我们创建一个SpringBoot工程,引入Web和Redis依赖,同时考虑到接口限流一般是通过

细数国产接口协作平台的六把武器!

1关于接口协作平台的畅想软件界发展至今,API(接口)的重要性日益凸显——不同的端,不同的模块都在通过API交互,不同角色的成员也都在围绕着接口展开工作。在这个前提下,一款集文档、接口调试、Mock、接口自动化测试一体的接口协作平台变得尤为必须。市面上优秀的接口调试工具如Postman、JMeter如雨后春笋般涌现,各大厂也在自研接口协作平台。那么问题来了

Go:分布式锁实现原理与最佳实践

分布式锁应用场景很多应用场景是需要系统保证幂等性的(如api服务或消息消费者),并发情况下或消息重复很容易造成系统重入,那么分布式锁是保障幂等的一个重要手段。另一方面,很多抢单场景或者叫交易撮合场景,如dd司机抢单或唯一商品抢拍等都需要用一把“全局锁”来解决并发造成的问题。在防止并发情况下造成库存超卖的场景,也常用分布式锁来解决。实现

SpringBoot 整合缓存Cacheable实战详细使用

前言我知道在接口api项目中,频繁的调用接口获取数据,查询数据库是非常耗费资源的,于是就有了缓存技术,可以把一些不常更新,或者经常使用的数据,缓存起来,然后下次再请求时候,就直接从缓存中获取,不需要再去查询数据,这样可以提供程序性能,增加用户体验,也节省服务资源浪费开销,在springboot帮你我们做好了整合,有对应的场景启动器start,我们之间引入使用

排查dubbo接口重复注销问题,我发现了一个巧妙的设计

背景我在公司内负责自研的dubbo注册中心相关工作,群里经常接到业务方反馈dubbo接口注销报错。经排查,确定是同一个接口调用了两次注销接口导致,由于我们的注册中心注销接口不能重复调用,调用第二次会因为实例已经注销而报实例找不到的错误。虽然这个报错仅会打印一条错误日志,不影响业务,但本着followthrough的精神,我决定还是一探究竟,更何况重复注销

ASP.NET WebApi服务接口如何防止重复请求实现HTTP幂等性

一、背景描述与课程介绍明人不说暗话,跟着阿笨一起玩WebApi。在我们平时开发项目中可能会出现下面这些情况;1)、由于用户误操作,多次点击网页表单提交按钮。由于网速等原因造成页面卡顿,用户重复刷新提交页面。黑客或恶意用户使用postman等工具重复恶意提交表单(攻击网站)。这些情况都会导致表单重复提交,造成数据重复