根据 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