接口测试 根据 home 的接口测试文档 和自己的工作环境搭建的一套自动化接口测试框架,请老鸟前来指教。

徐旻 · 2017年02月17日 · 最后由 徐旻 回复于 2018年01月25日 · 626 次阅读

根据 home 里浏览了各种关于自动化接口的帖子和几位朋友在我当初写的自动化框架的答疑中的回复,本人搭建了一个自动化接口测试框架,并且马上就要被落实到项目上了。
本贴的目的不但是分享最近学习到的东西,跟重要的是想请有经验的老手来指点一下,有问题最好在最快的时间内发现,并且修正。

自动化接口测试框架
python + robotframework + execl + Jenkins

home 里有老手说过一句话,不要企图自己去写框架,用成熟的框架效率才是最好的。

开始设计框架的时候我是自己来写的,看了这位老手的话后,顿悟了。
除非是需要开发测试框架,不然拿来主义何尝不是件好事情,前提是拿来了也要你会用,能把别人的东西成功集成到你的设计中。这也是种本事。

选择 python,没有办法,只会点 python,直接用 python 写会效率点。
数据管理用的 execl,就是图这个数据管理只管简单,大家都容易上手。
断言用的是 robotframework,开始我设计自己写断言,但是在看了 home 里的帖子以后,努力找成熟的框架,最后选中了 robotframework。因为他有自己成熟的断言体系,还有报告生成系统,最重要的和 Jenkins 后期的 CI 也是很简单的事情。

自动化接口测试的框架搭建概念我就不说了,home 很多文章都有。
我觉得我这套框架的核心在于 python,只要你会用 python 写几行,在这个框架里放点自己设计的模块简直是易如反掌。
说句啊老实话,robotframework 在这里只是简单起到自动判断,生成报告,以及以后和 jenkins 的 CI 持续集成。

数据管理还是用的 execl,虽然我梦想中的框架应该是 db,但是鉴于时间短,工期紧,还是老老实实用 execl。

中心思想就是,把从 execl 中拿到的数据,封装成四个字典数据。
1.第一个字典放的是 request
2.第二个字典放的是 request_body
3.第三个字典放的是 judge_value
4.第四个字典放的是 set_judge

request 字典:有 host,url,method,protocol,headers 信息。
根据 host+url 组合成 request 路径
method+protocol 可以判断需要调用那种 request 方法,是 post+http,还是 get+https
本人现在暂时写了一种,就是 post+http。
如果请求的时候需要 headers,那么可以把属性写在 headers 当中。

request_body 字典:就和他的名字一样,放的就是 request_body。

judge_value:预期值,在 home 里很多文章都写到自动录制脚本,来作为回归测试的判定根据。但是,如果真的是做接口测试的话,领导觉得还是要从头开始做起,不做回归,就根据 api 文档进行自动化脚本编写。虽然我以前发表的文章中也有类似录制脚本的概念,在这次的框架中就没有编写。有需要的时候可以现写。
言归正传,预期就是测试人员或者开发人员自己判断的值,我们也把这些值封装成一个字典。

set_judge:这个字典我放了几个逻辑。
第一种,返回值的 json 的 value 是什么类型。因为从 execl 表格读取的数据类型是一致的,但是 json 中返回的值可能有很多种,到时候需要转换类型然后判断。所以加了这个逻辑,告诉返回值当中这个 json 的 value 的类型。
第二种,逻辑判断,这个思路是读了思寒的雪球的 http 测试框架中得到的灵感。有的时候我不需要精准判断,这个数据可能是几个数据中的任意一个,那么我可以加一个逻辑 in,然后给他一个 list。 判断的时候就是这个 json 的 value 是否在这个 list 中,如果正确就返回正确。逻辑可以随便加,反正 python 写东西很快的。想怎么加就怎么加,比如大于等于小于,在两个值之间。 或者等于某个 sql 语句的值。

有了四个字典,我们就开始写 robotframework 的脚本了。

看完这张图解,大家就理解为什么说 robotframework 不是这套框架中的主角了。因为他就是把我封装好的判断进行再一次判断,生成一个报告而已。

代码我会在文章最后发一个连接,有兴趣的朋友可以自己去研究。

我来给大家演示一下具体操作流程。
启动方式我做了两个,一种是命令行,一种是 ui。
运行 main_gui.py 可以启动 ui

第一步是设定工作路径。
我设计的目录结构是
project name
|__以接口名字命名的目录
| |
管理该接口的 execl 数据,robot 的脚本,robot 脚本运行的配置文件,报告目录
|
_以接口名字命名的目录
|
_管理该接口的 execl 数据,robot 的脚本,robot 脚本运行的配置文件,报告目录

图中的 yqq 就是 pj 名,sample 目录就是某个接口接下来需要的 work space。
点击创建按钮。在 sample 目录下有的 sample.xlsx 文件
打开是一个填写的范本左图,填写好内容可以参考右图。

然后进行初始化参数的操作

在原来 execl 中出现了 case 这个 sheet,然后填写期待值,数据类型,逻辑等等

然后一键生成 robot 脚本

最后一键运行 robot 脚本

一个接口目录下的基本文件


我知道这种报告很土,但是凑合用吧。能定位出来错误就可以了。

然后就是 Jenkins 的持续化集成,我自己还没有做,因为这套框架要在下周才会被投入正式工作,不过我看了网上的资料,要用 Jenkins 执行 robot 的文件还是相对来说比较简单的。公司里有人专门维护 Jenkins,这个到时候也不需要我操作,但是我会去学习一下的。设计框架的最后总要遇上 CI 的,Jenkins 是逃不掉的。但是 Jenkins 有 robot 的插件,到时候设置下任务就可以了。

关于最后的报告邮件,当然也是 Jenkins 搞定。这个请自己参考 Jenkins 的使用方法。

我设计的框架就这些,看完的老鸟希望你们给我指点指点,因为现在在等 api 的文档,有什么不足的地方,你们帮我指出来,那么我可以提前修改一下。

本框架的有点就是只要你会 python,自由度是相当大的。

很感谢 home 给我很多参考,home 很多文章我都读了很多遍,每读一次就会有多一点领悟,其实在这里就是要接触到很多先进的理念或者工具,把这些动作付诸在工作中。

代码在
https://git.coding.net/lunamagic/rf-api.git

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 22 条回复 时间 点赞

感觉 robotframework 浪费了,完全没发挥出来,本身可以不用 excel,直接数据驱动就好

#1 楼 @wuxixuxiaodong 是的,robotframework 看了 1 个星期,基本上就是用来做报告的,这点的确是我的不足之处。用 execl 主要就是为了直观的做数据驱动。方便给测试人员生成测试用例。回头要去补充一下 robot 的知识。

#2 楼 @lunamagic 其实也挺好,适合不需要关注实现,只关注 excel 的人,我一般都直接一个接口一个 robot 文件,excel 的信息直接写成 vriables 的形式,不用界面写 robot,手写 robot 更快

一直在说 home,home 是谁,没这个用户啊

匿名 #5 · 2017年02月18日

写过一个跟你差不多的,用的是 java+testng

#4 楼 @michael_wang home 就是 testerhome 呀

#5 楼 @550498261 在工作中这样是否足够了?还有什么可以优化的或者有什么细节需要注意的

😂能用就好,不用太纠结

—— 来自 TesterHome 官方 安卓客户端

徐旻 #10 · 2017年02月18日 Author

#8 楼 @hu_qingen 我在这套框架中设计了逻辑判断虽然是基于思寒 在雪球 http 设计中提到的,但是也有一部分是在读了你的白名单的理念以后,把两个人的想法合并在一起。 现在的逻辑中应该是加了黑名单的概念,其实很简单。只要在 execl 中 logic_judge 那行对应的返回值的 json 值的 key 填写 black。然后在逻辑判断中加一个判断就可以实现黑名单了。反之如果要设计白名单的话,在 execl 里添加一个字段,黑白名单,这样就更加明了。 还有参数强度那篇文章读了 2 次,还是没有搞懂。惭愧惭愧,不知道能私下请教下吗?

#10 楼 @lunamagic 我的 QQ527777879,别说请教,一起沟通,在此基础上,你的检验可以增加 json schema,数据准备和数据清理是自动化的关键😄

—— 来自 TesterHome 官方 安卓客户端

测试用的数据就是 Excel 里固定的吗?

#11 楼 @hu_qingen 我知道可以用 json schema 对响应结果的类型进行自动化检查,请问一下能否用 json schema 进行值得检查呢

#13 楼 @Feyiz 像你说的,json schema 做类型结构检验,做值检验建议使用 assertJ,但如果用 Excel 做数据驱动,也可以采用多个 k-v 形式,以,或其他类型分割,遍历检验;像阿里云性能测试平台的返回值检验就是这种方式

—— 来自 TesterHome 官方 安卓客户端

徐旻 #15 · 2017年02月20日 Author

#14 楼 @hu_qingen 刚才去查看了下 json schema,果然是好东西。 我一开始做 json 解析的时候没有查到这个东西,所以就自己写了套递归,虽然也可以全遍历检查值,但是自己写的肯定没有已经分装好的包来的好用。
我的解析方式是自动递归把 key 做成一个表达式。 nodeList.[0].name 表示 response 的返回值中有 nodeList 这个 key,这个 key 下面包含了一个 list,然后拿出 list 中第一个元素,第一个元素中有 key 叫做 name。判断的时候会自动根据 nodeList.[0].name 这个表达式去找到对应的值然后和预期值 做比较。
@hu_qingen 不知道你说的 k-v 形式 是否就是我现在做的这个效果。

徐旻 #16 · 2017年02月20日 Author

#12 楼 @jingjing0506 你说的数据是那部分?能具体说一下嘛?

#15 楼 @lunamagic 😄我用的不是你这种方式,你这种也可以,我这边的方式是 a:123,b:568,g:[ 类似这种方式,以,分割遍历检查,遍历方式也很简单 string.countain 方式;我的考虑是能简单有效实现检验即可,也可以用正则方式😄

—— 来自 TesterHome 官方 安卓客户端

徐旻 #18 · 2017年02月20日 Author

#17 楼 @hu_qingen 刚才去学习了 assertJ ,哎 是 java 的断言神器 。和 python 么有关系。

#16 楼 @lunamagic 就是 Excel 中准备的测试数据

想说这种测试用例很难维护的。

首先第一步请把测试报告和 case 逻辑组织好一点,目标是达到:看报告时能一眼看出来是哪里 fail 和为什么 fail。

否则 case 数量一多,看报告的人要吐血。对,我就是那个看报告和不断吐槽其他人写的破 case 的人。就是上游写用例的人写得太粗糙,害我看 robot log 看得烦躁死。

一眼看不出哪里 fail,意味着要花力气分析。另外你的 robot case 就是一个线性脚本,看着晕。反映到 robot log 里,你的 log 里大部分东西都是测试人员不想看到的东西。

你完全可以使用 robot 的 template 功能来做数据驱动的 case,替代掉你的 excel。那个很丑的图形界面也可以用 pybot 命令行代替。

1.这个感觉没必要用 robotframework 了吧,只是报告的版上貌似很多其他的,而且 RF 报告把各个关键字都显示出来的,但一眼却不能轻松看到请求 url,请求体,响应报文等,不利于手动重试确认? 断言什么的也只是 RF 再封装了一下,可以说 RF 有的肯定 python 也有的
2.按上面的看来 RF 的 tag,suite 什么的貌似都没用上吧,用例多了层次会差点
3.excel 管理用例阅读性好,但是貌似限制了用例的复杂性,不过这个看需求,够了就是好了
4.赞分享

😁 能否给个联系方式

徐旻 #23 · 2018年01月25日 Author
FFFFFFFFFF 回复

这个是我的微信号 lunamagic1978

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