0


玩转Apifox之一个测试推动团队选择apifox的几点原因

一次现网验证失误

前一晚版本更新,现网验证至凌晨三点,不到七点,产品经理的电话就来了:“y哥,昨晚现网生成accesstoken的接口没验证吗?刚刚项目经理打电话说第三方投诉获取不到accesstoken了,得赶紧来定位原因补一个紧急版本,开发我已经通知过了”,听到这话我疑惑道:“怎么会呢,我昨晚验证的时候都拿过好几次,亲眼看过没问题的,都能正常使用的哇,这不应该吧”,说罢离开亲密接触了三小时不到的床赶到公司,在电梯碰到了负责该接口的开发,问道:“怎么回事啊,x哥,我们这期需求没讲要改这个接口啊,你这期动了吗?而且昨晚我接口获取的accesstoken都能正常使用的。”彼时他也是一脸疲态,说:”我根据架构的建议优化了一下级数格式,但是这个也不应该出问题啊"。顿时我心觉不妙,:”怎么没看到你告知测试呢?而且也没看到正式需求啊”,“昨晚不是还验证了能拿到正确的accesstoken嘛,我看小优化问题,没更新进共享文档”,他回答道。随即一起进了昨晚奋战的会议室,看着开发使用postman编辑好一会后一调接口,好家伙,原来是data嵌套了多一层目录,-data里面藏data,属于是老母猪戴bra,一套又一套了。解决后总结版本经验的时候就在想:

  1. 这种用肉眼对比接口返回参数的方式风险太大,jmeter和postman写断言的方式真不太方便,急需解决使用程序校验所有返回数据和断言的工具。使用Apifox实现如下:

图一 后置处理断言和变量提取
  1. 信息同步不及时导致测试都没接到需求的测试任务,共享的文档也得去维护才行,容易出现遗漏。对接口文档的修改实时同步团队内成员,使用Apifox实现如下:

图二 接口文档更新同步

令人抓狂的接口协调

“这期我们的主要任务是数据迁移”,相信只要听到产品在需求评审会上的这句话,每一个测试整个脑瓜子都是嗡嗡的,意味着接下来的版本绝对不好过。之前在这个项目里,开发团队用的是postman调试,而测试团队为了方便做性能测试用的jmeter,在如此的背景下一般在调试时会有这些经典语句:

  1. 我:怎么就不行,你把jmx文件发我,我对比一下
  2. 我:你的结构怎么这么乱啊,我找不到那个接口啊,你同一个接口写这么多干嘛
  3. 我:你的入参都和我不一样,肯定查不到啊
  4. 开发:刚刚运行的接口入参和返回截图我看看
  5. 前端:这个接口怎么出参不一样了啊,你是不是改了接口没改文档
  6. 后端:这个接口我还再改改,前端先自己mock数据试试吧
  7. 后端:我postman跑不了这样的,我过来看
  8. 产品:测试结果的截图看不全,重新发个来看看
  9. 产品:调用方的问题转给你了,你把接口脚本发我,我调一下看看 团队成员统一格式或平台进行分工合作,也是提高效率的一种方式,使用Apifox实现如下:

图三 团队内成员维护用例实现

日常拨测时的引用

对于领导要求团队内每个人每周都要求拨测不同模块,美其名曰为了让队内成员更熟悉系统整体的“合理”规定,除了徒增工作烦恼,没其他优势了,在本就不熟悉的模块进行拨测,即使是在有对方工具脚本的情况下,还需要花费很多的时间和精力才能完成任务,可能还存在着各种入参数据不一致,接口逻辑理解不一致,无法准确判断接口出参是否符合需求等问题,而且因为我都是上午一上班就开始,这对于一天的工作状态都是很大的影响,工作激情和效率大打折扣。但是现在只需每天点击一下自动化测试里面预设好的几个用例,平均每天五分钟时间得到报告,美滋滋。不吹不黑,使用Apifox确实解决了本人工作中产生烦恼的大部分问题,下图是某模块接口的自动化用例运行截图:

图四 查看自动化测试报告

可见团队成员如果能都在一个平台一个工作区的一个环境下维护同一份接口调试文档对团队工作效率的提升具有里程碑式的意义。

以上只是本人的一点真实感受,有感而发,感谢阅读!

标签: 测试工具

本文转载自: https://blog.csdn.net/weixin_44378802/article/details/125500104
版权归原作者 鲨鱼剑客84 所有, 如有侵权,请联系我们删除。

“玩转Apifox之一个测试推动团队选择apifox的几点原因”的评论:

还没有评论