接口测试 接口自动化测试平台演进之路

虫师 for Klook测试团队 · August 01, 2019 · Last by Benjamin replied at November 27, 2019 · 8131 hits

接口自动化测试平台演进之路

我们在经历接口自动化平台化上面做了很多探索。

大体上经历了三个阶段,这三个阶段可以看做是三种接口自动化平台的类型类型。

接口自动化平台(第一版)

先上图:

关键技术是:django、bootstrap。

为什么做 测试平台化 首先 接口 ,因为接口好抽象啊! 测试一个接口的组成部分是相对固定的。

  • 地址:URL
  • 请求方法:GET/POST
  • 请求头:Header
  • 请求参数类型:form-data/json
  • 请求参数
  • 返回值
  • ...

大体上就是这些了,每一个选项我都搞一个输入框,然测试人员填写不就好了嘛!

可是,我们往深入深入了做就发现这种方式不足:

1、使用起来效率比较低了。要每个输入框的填写,创建个几十条用例就觉得麻烦了(当然可以提供一建复制功能)。

2、复杂的接口也不好实现,前置条件,删除的接口需要先通过SQL插入一条数据; 还有接口的依赖。 再比如接口的参数有加密字段等。

3、界面复杂,随着你功能的增加,界面上的选项会越来越多。

接口自动化平台(第二版)

先上图:



关键技术是:django、vue.js、pytest、request。

这一版的思路是,requests 那么简单强大,你平时怎么用requests库测试接口,依然这么写脚本就好了。完成之后把脚本上传到接口测试平台。你可以在线调试,创建任务执行。

这个时候,接口平台的作用有点像Jenkins,最重要的功能时运行和统计结果。

  • 优点:

代码的自由度最高,你想怎么写都想,参数化,加密,结果口依赖,都可以非常简单的实现。

  • 缺点:

1、测试只喜欢用postman
2、上传脚本挺麻烦的,当时一个脚本还必须和一个接口强关联。

接口自动化平台(第三版)

先上图:

关键技术是:django、vue.js、request。

如果你用过 HttpRunner 的话,你就明白这一版的设计思路。把第一版上面的各种输入框做了简化,或者也可以看做是把 HttpRunner 做到了Web页面上,大体上分三部分:

  • 所有的接口测试信息用JSON格式填写

  • 断言的信息也用JSON格式

  • 右侧是接口的返回值(不要在意错误信息!)

优缺点嘛? 你们可以留言评判。

共收到 46 条回复 时间 点赞

先收藏,虫师作品值得学习

博客园跟了好久,终于来这了

TavisD 回复

写平台一部分是给这些人用的:
那些代码都看不懂,一写接口测试用例就不想写,说自己不会代码觉得麻烦,还不想学习
就想别人把饭盛好喂到嘴里的那些人

TavisD 回复

感觉第二版才是适合复杂逻辑使用的. 第三版看描述就是第一版的界面优化版.

虫师发帖,先点赞再说

原来群主在klook,之前买悉尼动物园门票还用过klook😀

偶像虫师的帖子,点赞

TavisD 回复

一是领导要求为了面子工程,二时服务那些基本没啥代码基础,只懂业务的测试人员,三是测试到了一定年限,总的弄点高大上不同于普通测试工作的东西出来吧。

终于等到你!

赞一个

虫师 #12 · August 02, 2019 作者
TavisD 回复

我怼过做填“写表格”自动化工具的人,鼓励大家通过代码做自动化,写代码多自由啊!可是,做工具和平台的人一定要假定一批,他们不懂代码,而且还必须要让他们做自动化的测试。然后,把自己放在一个 框架/平台 的制造者。实际情况是:

  • 谁愿意做平台的制造者?

  • 谁只愿意做平台的使用者?

我想稍微有点追求的测试都会选择前者吧!
😀 😀

虫师 回复

之前我也想过此类问题,框架还是平台?

其实没有硬性的选择,要看面向的对象:
假如是土豪公司,招各个都是有技术傍身的人,用框架写代码,各种测试场景想怎么飞怎么飞;
如果是穷公司,考虑各种人力成本,只有极少数会点代码,其他全是手工测试,难道还指望那几个人敲代码去维护庞大的用例场景?
血的教训告诉自己,少数人牛逼没有用,没有一个团队的支持,再怎么厉害也是白费

虫师出品,必属精品

虫师 #15 · August 02, 2019 作者
kong 回复

如果是把你空降到一个功能测试为主的团队。 你其实可以选择做一个平台去解决他们的问题,也可以选择找出几个懂些代码来培养写框架来结束。

首先,我不认为接口是适合每个测试的,或者每个测试都必须要参与到接口测试中的,我觉得不懂一些接口实现逻辑的话也 很难设计好接口测试用例

做平台面临的挑战更多,如果做的没有postman 强大,测试不会用。如果做的特别强大,那么一定很难用!哈哈!

当然,每个公司的情况是不一样!

TavisD 回复

等你发现测试框架无法满足你的时候,你就会想写一个工具来满足你的要求了,写完工具会想何不共享一下?这就做成了一个平台。

白嫖怪,已就位。坐等各位大佬分享

虫师 回复

大佬不可能不知道什么叫开源吧 重复造轮子费时费力。现在论坛里谁分享个啥子平台出来,下面评论多是各种反应跟自己的好像差不多,大同小异的。结果导向的事情大家为什么要走那么多弯路呢

API方面:

  • 1.要有单个API所有请求数据记录
  • 2.详细的请求和返回数据
  • 3.请求之前的数据加密和签名
  • 4.请求之后的清理
  • 5.请求结果抽取出来,放到下个API中使用
  • 6.多个API联合调试
  • 7.多个API组装成用例
  • 8.API的版本状态管理(成功,失败,未调试之类)
  • 9.多种断言模式
zyanycall 回复

你想法刚好相反,框架是最灵活的,在框架的基础上扩展是容易,如果框架都无法实现,工具和平台就更不能。工具和平台解决的是 不让你写代码做接口测试

虫师的文章自带BGM,欢迎!

原来大神也是在造轮子,真理解不了测试平台的价值在哪里,又有多少人愿意在web 上去录测试用例, IDE写测试用例代码更快
现在的现象是 很多人都想着去做测试平台什么的,到底团队需要什么,应该做成什么样子,能不能提高效率 这些都不考虑。很多做测试平台仅仅是为了学习

虫师 回复

一开始我也想着用框架,有参考过你那一套.《web接口开发与自动化测试》
最后了用FasterRunner.基础HttpRunner的web平台.
由于HttpRunner有debugtalk这个神器的存在,让平台灵活了很多.
主要是为了满足:

  • 和公司API平台对接,实现自动录入API.
  • 开发调试API
  • 多人同时使用
  • 面子工程,老大想弄平台
Eward 回复

没有动手的人永远在找缺点,你说它无厘头也好,骗骗没动手的人总是能有奇效,并且引发舆论也有独树一帜的快感。
真真实实动手完成了的人,又确实解决了团队的诸多问题,可能不完美,但是全方位收获颇多。
回头看看那些打嘴炮的人,还是保持安静偷偷发育比较好。

虫师大佬难得发一个帖子,撒花。不过其实我和上面很多同学是一样的看法,现在大部分的接口测试平台,最大的用处就是满足自己装逼的需求,实际效果其实并不好。如果要达成所谓<不让你写代码做接口测试>这个需求,做成一键式执行,所有内容都有测开搭好,功能测试只需要上平台选择要测试的内容(包括测试哪些接口,使用哪些body,而这些都已经预设好了),然后开始测试,这样才算是比较接近这个需求。

虫师 回复

呵呵了。你能说一个框架是你心目中完美的框架吗,它就没有缺点吗?
“如果框架都无法实现,工具和平台就更不能。” 为什么我不能改框架的源码来实现自己的需求呢?为什么我不能组合多个框架的优点来达到自己的目的呢?
框架总有缺点,而我做工具或者平台,就是组合各个框架的优点,让其合并在一起。相信各位做平台的也是这个目的。
“工具和平台解决的是 不让你写代码做接口测试 !” 就比如接口测试的断言部分吧,postman都是写脚本的形式来断言的,用我截图给你吗?是叫 Javascript ,

怎么了,你要告诉我postman不行,它不是一个成功的工具,是因为它让我写代码了,让我写了代码才能做接口测试了。那你的工具超过postman了吗?
不是说想怼你,你怼别人的时候最好想想自己说的是啥,你到底想清楚问题没有。

请教个问题,断言怎么做到灵活断言呢

我个人是比较喜欢用框架来实现测试用例的开发调试和运行,平台只做用例展示和结果展示。

最近在做框架的另一种尝试,灵感来自于 rest-assured,充分复用到 IDE 的语法提示和自动补全。
大致是这样的:

debugtalk 回复

支持,实现真正的自动化,平台的角色比重30%,自动化框架优化、用例编写占到70%
平台仅用于驱动和数据展示即可,重点还是用例规范和用例编写能力

debugtalk 回复

这样有一个问题,你把每个方法都返回整个对象正常情况下是很畅快的。
但是遇到一些特殊的验证,比如我需要对返回的body做一定的处理再进行equals的断言,这样就需要一个中间变量来转移。
或者你再增加一种assert的方法。
使用中间变量会打破你这种链式的书写方式,让代码变得非常凌乱。增加一种assert到后期你会有巨多的assert方法,语法提示选择的时候也是很灾难的。
另外,为了维持这种链式对象,你每个方法返回都受到了限制,扩展起来是不可能的。
就等同于一个json对象。

围观虫师😁

Karaser 回复

链式不是绝对的。采用链式能覆盖绝大多数场景,对于一些特殊场景,使用中间变量也可以接受的。

Karaser 回复

可以看看 rest-assured 。链式调用的校验阶段返回的对象,除了可以通过链式调用做断言,也可以取出任意返回值。

框架能满足80%场景的需求,剩余20%通过高成本一点的手段能满足,我觉得这就是一个挺不错的框架了。

PS:我司内部目前基于 rest-assured 推广接口测试已有超过1年时间,但实践中大家对于全链式调用的接受度不是太高,因为实际用例中 request 部分大多差异不大,但 response 校验部分差异较大。而全链式调用从头写到尾,会导致 request 部分重复度高。

目前优化后的用法是:
1、 request 部分封装成函数,返回一个 rest-assured 的可链式写断言或提取表达式的对象,供用例进一步使用。
2、一些通用类参数或统一加解密,做到 filter 中(类似于 spring 的 aop ),用例不需要为此额外写任何东西。

框架和平台,我觉得本身特点和定位不一样,各有优势,但两者可以并存共赢。debugtalk 提出的框架来实现测试用例的开发调试和运行,平台只做用例展示和结果展示,也是挺好的结合方式。

框架/工具:
优点:灵活度高、可以套各类设计模式、idea 自动生成+断点调试等,简单的说就是写用例很爽。
缺点:要有编程基础,要装运行环境。简单的说就是执行测试不那么爽。

平台:
优点:不用本地装任何东西,有个浏览器就行。非常便于推广到非测试团队使用(如开发点一下就执行测试),也便于数据收集统计。简单的说就是执行测试很爽。
缺点:GUI 交互的灵活度会低一些,业务复杂度高的用例写起来可能不那么方便。如果采用写代码类的方式,因为缺少断点调试和自动生成,效率也会降低。简单的说要做到写各类用例也爽不容易。不过如果是轻量级的接口测试(录制或导入接口文档生成 request ,校验主要验证返回码+少量返回值,涉及多接口调用的链路不多),这个问题估计也不大,甚至使用上学习成本比写代码低不少。

个人觉得这个事情没有绝对的对错,要根据实际情况来看。适合当前公司团队的才是最好的。至于那些说做平台只是为了装B的,说明他们在了解团队实际需求上没做好,只是按自己想法去做,而不是按大家的想法去做。这类情况可以参考的一种解决方法,就是让测试开发开始设计平台前,先到业务测试组轮岗1-2个月,熟悉业务测试的实际情况,以后也好相互交流沟通。

TavisD 回复

我现在也有同感,现在有一些帖子对于一些人的引导是有问题的。

测试平台应该是基于团队,基于项目流程等需求的产物,不是每个公司的必需品。
以接口测试平台为例,在做之前是否有对其他工具框架有深入的认识,是否能通过使用工具框架来快速解决问题,是否可以通过二次开发框架来解决问题,如果能解决问题为什么还要做平台。

我之前就受到这方面影响了,好多框架平台上来就分析其他工具框架的缺点,例如postman,不好用啊,不适合团队协作用啊,然后推广自己的轮子,但其实深入调研学习后发现大多数框架平台的实现就是postman的缩影,甚至还没postman做的好。比如:

  1. 测试环境的配置,postman支持全局变量配置
  2. 测试setup配置,postman支持pre-script脚本
  3. 测试断言,postman支持test,如果你不会写代码,postman提供了好多test模版点一下就能用,修改下参数,如果这点东西都不想学就别做接口测试了。
  4. 测试执行,postman支持collection集合执行,还可以设置执行次数,执行时间
  5. 调试的话,postman有postman console
  6. 团队协作的话,postman支持teamwork,可以使用team workspace,还支持collection分享,即使免费的一个月可以分享2000次,还可以导出
  7. 持续集成可以用Newman Jenkins啥的
  8. postman还支持mock数据

当然,学习实践一些新技术是每个人的自由,毕竟现在还多也有测试平台啊各种这样的需求,只是不希望一些刚刚接触测试或者接口测试的同学上来就被引导为做接口测试做个平台才行或怎样怎样,而不去深入学习了解本质以及一些开源工具框架的优点。

陈恒捷 回复

👍
”框架能满足80%场景的需求,剩余20%通过高成本一点的手段能满足,我觉得这就是一个挺不错的框架了。“
个人觉得这点平台也能做到

Karaser 回复

是的。个人觉得不用纠结用是框架还是平台,能简化这80%的场景的工作量,就产生价值了。

Author only

框架和平台各有好处,框架灵活便于调试,平台方便推广,数据存储和展示,直观方便,每个工具的受众不一样。
站在测试人员的角度上肯定都愿意做框架,因为可以从中学习写代码,提升自身技术能力;
但作为公司的角度,需要的是快速产出,如果每个测试都去学习写代码做自动化,那么公司的成本就变高了;平台的一个优点就是方便
功能测试人员去低门槛的录入接口自动化用例,为啥不让自动化测试人员或测试开发来编写呢?(功能测试人员对业务更为熟悉)。
如果公司还没有发展到需要平台的支撑,只需要简单的回归一下,那么框架的接口自动化更为方便,所以还是要看公司的取舍,
并不是谁对谁错。

watchdog 回复

是的,我现在也面临这问题

TavisD 回复

为了kpi

本人经验,平台好处两点,
一在框架中写脚本除了测试数据外其他基本是重复且无提升水平代码(框架封装的够好);
二是有些测试人员确实代码能力不够,自己写脚本容易出各种问题,平台免去了这些错误的重复发生。

摩拜虫师大佬

哈哈哈哈,测试平台仅供测试交流学习,如果不付出最基础的测试平台开发的辛苦的“邯郸学步”,那么又如能能体会一个高可用的平台诞生到底需要些什么呢?写多了做多了自然就懂了,以前做的事那些对,那些错。那些功能可高复用率。

写一个jar包工具,当初一开始只有简单GUI界面后面慢慢拓展为支持命令行、Java调用、Python调用,曾经走过才能体会这过程以后的路上会走的更好。学习需要一个高度专注。

一个测试小白的个人感言

Benjamin 回复

GUI界面只是方便小白使用加密解密数据,而后面拓展给愿意折腾的人去做扩展。最后的结果:手动操作也可,要自己去调框架写也行。Jmeter、Java、Python随意基础包的方法已封装好并维护了一套秘钥库。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up