接口测试 我们的接口自动化 (基于 robotframework 和 requestslib)

婷婷 · 2016年08月04日 · 最后由 浪迹天涯 回复于 2021年09月28日 · 2295 次阅读
本帖已被设为精华帖!
  • 陆续接触接口自动化也有点时间了,从最开始的以为拿 jmeter 发个请求就很牛逼(功能测试出身不要嘲笑俺~)到现在也可以自己规划和设计自动化测试觉得很容易也很不容易(废话可忽略...)
  • 第一次发帖主要想分享下我们的接口自动化是怎么做的,文件,用例,测试数据怎么管理,结果怎么验证,还有一些自己 yy 的东西,很多帖子也有写这些,但是感觉对如何做成一个项目而不是一个例子的描述还是很少的,因为自己以前也是做功能测试的每次看完总会想如果自己还在以前的水平看完了以后做一个例子是没问题,但是如何真正高效的应用到工作中去还是很困惑,例如那么多接口我要怎么放,每个接口的验证可能也都不一样,到底要验到什么程度,需要自己加写什么类型的关键字等,反正很多的困惑~希望这篇可以給还在摸索的小伙伴提供更多的信息和灵感~
  • 我们是基于 robotframework 做的接口自动化,使用的 requestslib 库,至于这些怎么安装,怎么写一个请求发送出去,我就不写了...自己搜下很多很多~选这个只是因为当初正好在学习这个工具,始终觉得工具够用就行,重要的是不要忘记写脚本的目的始终还是为了能发现已经存在的 bug 才好,下面进入正题

先看下我们的项目目录:

不要吐槽我取的名字...

KEYWORDS: 存放各种关键字
- Business_Keys: 按照产品分类存放需要测试的接口以供后面 test case 和创建流程类关键字来调用;
其中单个接口的关键字放在 api 文件夹下(接口参数完全可以根据用例自定义传入);
流程类的接口关键字放在 combo_api 下(部分是多个接口的组合,部分是某个参数较多的接口仅对外暴露少量的请求参数方便在 test case 中调用走个流程的,例如处理一个用户单子封成只需要传入用户 id 就好,其他参数都有默认值)
- NoBusiness_Keys: 和接口无关的关键字,主要调用到 lib 文件夹下自定义方法
各种断言关键字
数据转换关键字
需要查询数据库或者 redis 的关键字(例如:随机获取一个在线状态下的用户)
其他和业务无关的关键字(例如:获取一个随机的手机号码,获取当前日期,时间,生日等)

RESOURCE:存放资源文件

File: 存放图片等文件,供图片上传这些接口使用
Properties: 叫配置好像有点不合适…其实就是放了被测接口公共参数的默认值,每次发送请求时候会将公共参数拼接起来
Schema: 接口返回值的基本结果对比开始我们自己写了方法,后面直接用了 jsonschema(http://json-schema.org/),这边就是存放模版的位置
Sql:給某些 test case 用来创建数据的 sql 脚本(数据好插入好删除,轻松不留痕)

RunTestSuite.bat: 为什么是 bat 呢。。因为我们放 windows 上跑的,这个主要是起测试脚本,然后调用一个 python 脚本生成一个统计的简易报告,robot framework 有高大上的报告,但是排错感觉并不方便,因此自己做了一个简易报告直接插入到邮件里面,主要就是返回了请求内容和返回值内容以及希望结果,一目了然有木有~(有点长图截不全)

结构大概就是这样~

如何添加一个用例

  • 每个接口都是一个 test suite,例如万能的首页,我们給他添加一个 test case 叫 “指定固定省市”
  • 用例内容无非是发起请求,拿到结果,做验证,对验证这快可能因为我自己做了 3 年多功能测试,所以对校验要全面这快比较执着,而不希望仅仅浮在表面,因此校验比较重,也正是因为一直本着俺要发现 bug 的目的做校验,因此对这快的关键字做了很多次优化,希望可以既满足我希望全面的需求,又要满足添加时快,方便的需求

我们的小规则:

  1. 对接口的参数尽量不要写死,能随机尽量随机(随机,或者随机从数据库取),我固执的觉得更容易发现问题哈
  2. 接口请求的地方会看到一个用户的帐号密码参数,可能大家觉得不理解,大部分接口如果需要用户 id 都是通过 token 来传(以前我们也这么干!),在实际写用例过程中发现,找 token 太麻烦,懒......但是帐号密码我记得很清楚(因为测试环境密码都一样的哈),因此我将接口下层调用的一个 postapi 的关键字优化了下(见下图),拿到帐号密码后去请求这个用户的 token,然后在拼接其他参数和公共参数,发起接口请求,这样妈妈就再也不用烦找 token 的事情了。。。缺点:如果登录接口挂了,其他接口都不能跑了,但是登录接口都挂了开发不是应该赶紧的修吗,不然都没法做功能测试了!

  • 对结果的验证这快够全面,最好的证明就是每个迭代的发现的 bug 数量~(不知道应该怎么写了,反正都是本着我手测接口咋验证的这个脚本就尽量覆盖那些点)

怎么跑?

  • 用例我们就区分了 2 类 tag,一类是希望一小时跑一次的(这些用例多是查询类接口,我们从数据库随机找数据出来跑的,因此希望多跑),还有一类就是一天跑一次,因为测试环境的发布权在我们手上所以对于发布这快我们都很清楚,因此就不需本着防火防盗防开发的目的频繁的跑了,大家根据自己需求来就好

怎么写?

  • 大部分公司的接口自动化脚本应该是在项目完结之后开始进行的吧,我们现在是接口文档出来就开始写,自动化和手测接口同步进行的,因此写的过程中也会提交 bug,基本上在进入封测前我们的用例可以全部写完,等到封测就可以运行起来了!不过这个还是要有人,现在项目多了我们基本是 1.5 个人在一段时间内全职加脚本

个人觉得这样子组织的优点是对返回结果的校验比较全面,添加用例比较快(在 combo api 中的关键字可以大幅度加快我们用例的添加速度),缺点是...个人觉得层次是不是多了点熟悉需要点时间,另外校验的关键字也封的比较重(原本需要好几步写出来的都给封成一步做完,这样就不如一步一步做起来好理解~)

好像写的也不是很清楚~大家随便看看吧也不知道能不能帮助到大家~

求工作~有老板收留吗...

共收到 31 条回复 时间 点赞

其实不太建议用 RF 做接口测试,接口测试更适用于数据驱动,但 RF 以关键字驱动为主,转数据驱动的话测试报告看起来很鸡肋,对同一接口做的请求脚本其实只需要一个,而不同的数据可形成不同的测试用例,而 RF 的话如果同一请求所有数据都写在同一用例的话,一个数据挂了整个用例都挂了,我当时也想用 RF 做的,毕竟 UI 自动化方面比较优秀,但数据驱动模型的话真心不直观,而且一般做接口测试可以升华到压力测试,RF 要额外用 pabot 跑并发,不方便,但楼主做得不错,学习了

#1 楼 @terrychow 我们是分开写的呀,一个 test case 是一个用例 不会导致全部挂掉呀 ,一个接口是一个 test suite 然后不同的参数组合不一样的结果验证,分 test case,怎么会全挂掉呢...我就是觉得那个界面操作起来不如自己写脚本快..但是可以給功能测试的同学用和学习我觉得也是不错的

#1 楼 @terrychow 你建议用? 关键字方便写业务的接口测试,另外数据的话 可以自动生成。

#3 楼 @yinyuting 是的,结合业务场景的话是可以的,我之前也是这么分开的一个用例一个数据脚本,结果一大堆用例😔 不好管理

#5 楼 @terrychow 就这样子的是吧,自己用下来的话 用例名字写清楚 如果是修改的话 找还是很快的,不知道有啥更好的方法呀,其实本质是我不喜欢在 rf 里面写用例,但是觉得这个对做功能测试的同学来说更容易接受,有时候也让他们写写优先级很低的模块~学习

#6 楼 @yinyuting 就是好入门,效率也是挺高的,只不过以后想扩展就不太好玩,我用 RF 做接口测试的时候都已经改过很多遍框架还满足不了我的需求,我甚至连测试报告都改了,后面就干脆自己写了

#7 楼 @terrychow 嗯,其实我们现在也就用到 requestslib 里面的 post 请求。。。其他好像也没怎么用,你说的意思是把比如一个登录接口的参数全都放在一个文件里面管理,然后一个用例把他们顺次调起来吗?这样用例看着是少了,但是对于结果的验证呢,现在我们的需求对于每个用例验证的东西可能都不一样,同一个接口可能有些情况需要查数据库,有些只需要看下返回的 message,这个没想明白要怎么弄。。。

思寒_seveniruby 将本帖设为了精华贴 08月04日 16:27

加精理由: 细节介绍了使用 RF 做接口测试的实践情况. 给别人提供了有用的参考.

我不太看好 RF 做接口. 不过够用的话也是可以的. RF 是个不错的框架. 也是自成体系的

有开源吗?

用的 excel

我们自动化也是用的这个框架

我觉得 RF 用来做接口挺好的,因为它是原生 Python 的,要二次开发非常方便,扩展性的话测试库统统自己写就是,我不喜欢用第三方库。
目前我也是用来做接口测试,所有的请求方法都是通过给的 json 文件动态生成然后直接当关键字调用,非常非常方便,不用再写一堆的请求方法。

婷婷 #18 · 2016年09月19日 Author

#17 楼 @elduh 嗯 嗯 我也觉得很方便的说这个其实就是包了个壳子而已,和你自己用 python 写是差不多的~

我们公司最近也在用 RF 做接口自动化。想请教您一下框架的事情,可以的话加我 Q455692629。谢谢

“json should be match jsonschema”
这是什么库的关键字吗?还是自己改造的?

婷婷 #21 · 2017年02月08日 Author

#20 楼 @risalin 自己写的

#11 楼 @seveniruby 接口测试一般用什么工具啊,RF 的瓶颈是什么呀,能给大致说说嘛,谢谢

#22 楼 @Pastel 暂时没觉得有什么瓶劲呀,唯一就是觉得 ride 在 mac 上不好用...😓

24楼 已删除

你好,请问 json should be match jsonschem 这个关键字是怎么实现

26楼 已删除
zzz 回复

“所有的请求方法都是通过给的 json 文件动态生成然后直接当关键字调用,非常非常方便,不用再写一堆的请求方法。” 这是怎么做的,能详细讲一下动态生成的过程吗

risalin 回复

秘技:Python 黑魔法之动态绑定方法到类,内建函数 setattr() 和 getattr()

婷婷 #29 · 2017年04月20日 Author
馬扎羅 回复

这个你百度下 jsonschem 就知道了

楼主好,请问 json should be match jsonschem 这个关键字的实现体,是你们自己实现的还是使用第三方工具,例如 Python jsonschema 中的 validate 方法?

jsonschem 这个方法好,我们公司也是用这个在做,但都是比较 json 键值返回的东西,data 里面的数据是动态的,没法真正的校验,jsonschem 就可以做到一些校验,给楼主点赞

terrychow 回复

rfs 有数据驱动功能,用例里使用 template

我觉得最终数据转源码,太丑了

RF 的使用人力成本太高了,低效

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册