根据 home 的接口测试文档 和自己的工作环境搭建的一套自动化接口测试框架。
根据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的脚本了。
https://testerhome.com/uploads/photo/2017/8dddae68f39a5971b34420e25cef3358.png%21large
看完这张图解，大家就理解为什么说robotframework不是这套框架中的主角了。因为他就是把我封装好的判断进行再一次判断，生成一个报告而已。
代码我会在文章最后发一个连接，有兴趣的朋友可以自己去研究。
我来给大家演示一下具体操作流程。
启动方式我做了两个，一种是命令行，一种是ui。
运行main_gui.py 可以启动ui
https://testerhome.com/uploads/photo/2017/094fee831236b0ff37e6d9ae7d2bfa1c.png%21large
第一步是设定工作路径。
我设计的目录结构是
project name
|__以接口名字命名的目录
| |管理该接口的execl数据，robot的脚本，robot脚本运行的配置文件，报告目录
|_以接口名字命名的目录
|_管理该接口的execl数据，robot的脚本，robot脚本运行的配置文件，报告目录图中的yqq就是pj名，sample目录就是某个接口接下来需要的work space。
点击创建按钮。在sample目录下有的sample.xlsx文件
打开是一个填写的范本左图，填写好内容可以参考右图。
https://testerhome.com/uploads/photo/2017/6ce80f0d23dc426300b04be8b1c3928f.png%21large
https://testerhome.com/uploads/photo/2017/81b2c18075e245a25b39ead91ec175da.png%21large
然后进行初始化参数的操作
https://testerhome.com/uploads/photo/2017/7fbd4a9c6a7716fe8586cb9a1c4d190f.png%21large
在原来execl中出现了case这个sheet，然后填写期待值，数据类型，逻辑等等
然后一键生成robot脚本
https://testerhome.com/uploads/photo/2017/c5b237c8764186c8ab40df5cf4212a8d.png%21large
最后一键运行robot脚本
https://testerhome.com/uploads/photo/2017/22b859f5b197b514747d107082e2ba01.png%21large
一个接口目录下的基本文件
https://testerhome.com/uploads/photo/2017/bd4c22e62947298c7c6dec9a840c3cd4.png%21large
https://testerhome.com/uploads/photo/2017/c4309921a36e9ae4b77bb2d9c7a6953c.png%21large
我知道这种报告很土，但是凑合用吧。能定位出来错误就可以了。然后就是Jenkins的持续化集成，我自己还没有做，因为这套框架要在下周才会被投入正式工作，不过我看了网上的资料，要用Jenkins执行robot的文件还是相对来说比较简单的。公司里有人专门维护Jenkins，这个到时候也不需要我操作，但是我会去学习一下的。设计框架的最后总要遇上CI的，Jenkins是逃不掉的。但是Jenkins有robot的插件，到时候设置下任务就可以了。
关于最后的报告邮件，当然也是Jenkins搞定。这个请自己参考Jenkins的使用方法。
我设计的框架就这些，看完的老鸟希望你们给我指点指点，因为现在在等api的文档，有什么不足的地方，你们帮我指出来，那么我可以提前修改一下。
本框架的有点就是只要你会python，自由度是相当大的。
很感谢home给我很多参考，home很多文章我都读了很多遍，每读一次就会有多一点领悟，其实在这里就是要接触到很多先进的理念或者工具，把这些动作付诸在工作中。
感觉robotframework浪费了，完全没发挥出来，本身可以不用excel，直接数据驱动就好 是的，robotframework 看了1个星期，基本上就是用来做报告的，这点的确是我的不足之处。用execl主要就是为了直观的做数据驱动。方便给测试人员生成测试用例。回头要去补充一下robot的知识。
页:
[1]
