接口测试 关于自动化接口测试平台的想法和实现

徐旻 · 2018年01月25日 · 最后由 隔壁老牛 回复于 2020年01月03日 · 264 次阅读

关于自动化接口测试平台的想法和实现

本来加入论坛已经过 1 年了,在看了接口测试的很多优质文章并且总结以后,设计了一套自己心目的中的接口测试平台。在此和大家分享一下。

流程

接口测试的根源就是从接口文档开始的,接口文档中的参数贯穿了整个接口测试测生命周期。
现在大多数公司的接口文档管理,开发 debug 接口,测试编写执行接口测试用例都是各自独立出来的。
比如:
接口文档管理:jira,wiki,swagger 等
开发 debug:postman 等
接口测试用例:各种自制框架

在这种架构下,各个环节都是分开孤立的。有的时候会出现很多问题
比如开发的接口文档完成后,由于各种原因,开发把参数修改了一下,忘记了修改文档,那么测试拿着错误的文档怎么测试都是错误。
既然我刚才说了接口文档中的参数是贯穿了整个接口测试生命周期,并且如果有改动,需要在尽可能快的情况下和使用参数的使用方进行同步。那么该如何实现呢?
答案很简单:不管研发开发时候 debug 用的,还是测试在测试用的这些参数全部从开发文档上获取就可以了。

方案

既然有了答案,那就来设计方案吧。
接口文档管理:如果对现有的接口文档管理系统很满意的同学,可以从接口文档管理系统的数据库里直接拿到接口的参数,如果是 swagger 的话,只要拿到 swagger-json,解析一下也可以拿到接口的参数。比如我,我觉得公司的接口文档管理很差,我自己设计一个简单的页面专门用来做接口文档管理。
接口 debug 页面:所有的参数都是从文档来的,如果文档写错了,就不能调试接口。
测试用例页面:所有的参数都是从文档来的,测试主要精力就是在 case 的设计上。

平台

平台必定成为一个趋势,而且如果把接口文档管理,接口 debug 页面,测试用例页面放在一个平台上,使用起来是高效的。在推动落地上,平台也更加容易被大家接收。

工具

我用了以下的工具
web 框架:django(为什么不选 flash,因为我懒,很多功能都是做好的)
web 页面:bootstrap3
python 库:requsets 等等
测试框架:pytest
报告框架:allure
持续集成:jenkins

现实

代码就不贴了,由于基本上都是一边 google 一边写的,属于非常不优美的实现。

接口文档管理页面和 debug 页面

这个是一个完整的文档管理流程,最后还用 debug 页面调试了下。
现在考虑用 tree 的形式来管理文档也许更加方便,等有空会考虑优化。
debug 页面,我是倾向做的和 postman 尽量一致,这样开发可以很容易的过度到在这个页面上进行调试。
为什么希望开发在页面上调试?
很多文档写的内容,测试就算开了文档以后也不容易立刻了解,有的时候还是需要和开发去沟通的。
当测试看到了开发调试的内容后,有些问题就不需要去问开发了,一看就懂了。
也可以把开发调试的历史数据保存到数据库里,以后要调试的时候,直接把历史拿出来点一下就可以了。

测试用例管理页面


我个人比较喜欢这种 case 的管理方式,相对来说比较直观。
现在可以上传 4 中脚本,分别是 setup,teawdown,header,normal。
原理很简单:
setup_script = importlib.import_module(script_name)
request_dict = setup_script.run(params=eval(self.test_obj.TestParams), bodys=eval(self.test_obj.TestBodys))
self.request_dict = case_request.update_case_request_dict(request_dict)

根据 script 的名字导入脚本,然后执行脚本,执行脚本的参数就是 case 里我们已经输入好的 Params 或者 Bodys。

然后来看我写的一个 setup 脚本:
import time

def run(**kwargs):
time.sleep(4)
print("kwargs %s" % kwargs)
return {"city1": "北京", "city2": "天津"}

case 运行的时候都是运行脚本中的 run 函数,比如我这个 setup 函数,在执行的时候,先执行 sleep4 秒,然后把 city1:北京 这对 key-value,city2:天津这对 key-value 放到运行 case 的时候全局字典 params 中,那么在其他需要调用全局字典的时候,把参数的类型设置成 params,然后把 key 写上,那么 case 执行的时候就可以使用 key 对应的 value。

那么这种用法最常用的场景就是根据参数获取 token。我们可以拿到参数的值,那么脚本只要把这些参数的值拿去做处理,然后返回一队 key-value: token:计算出来的 token。 然后在设定的时候设置下就可以了。

以前有一段时间我觉得 no code 编写 case 是很好的事情,这样能让更多的测试人员参加到 case 的编写中。
但是 no code 还是很难解决 case 的强壮性 。所以要写出好的自动化测试用例,必须是有一定 code 基础的。
这个框架中,可以做到 no code 写 case,可以根据需要添加 python 脚本,让 case 更加灵活。

如果需要添加新的判断方法,只要在 judge 函数中添加需要的方法就可以了,会 python 的同学会觉得很简单。

报告

allure2 是我的最爱,主要就是用起来简单,和 jenkins 无缝结合。这个 testerhome 里介绍相关文章太多了,我就不介绍了。
case 的具体生成,我用的是把 sample.py 放到相对的 case 目录下,然后根据 case 名中的参数拿到数据中对应 case 的参数,然后执行。
只要修改 sample.py 中的内容,就可以跟踪你想要得到的所有数据。

感受

以上这些是我做的 demo。
其实可以做的事情还有太多太多,根据实际的工作情况去做才是最有效的。要做一个泛用的框架真的需要很多精力,还是尽力做一个能用就好的。工作有了效率,才有可能拿到更多资源去学习和构建更多的好的工具。

接口测试还是需要好的思路,很多方面,比如测试数据的部署,测试用例的强壮。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 15 条回复 时间 点赞
匿名 #1 · 2018年01月25日

厉害,值得学习一番

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

厉害

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

开源?

bill 回复

开源还是有点距离的,如果你要源码我可以给你,不过启动需要很多依赖,现在工作比较忙,暂时没有整理。
代码仓库在 https://github.com/lunamagic1978/platform3

报告中的 body 应该使用 ru.yandex.qatools.allure.model.Parameter
而不是使用 ru.yandex.qatools.allure.model.Attachment

bauul 回复

谢谢,allure 用的不熟练,见笑了。你的意见对我很重要,让我又增长知识了。

徐旻 回复

不用这么见外,互相学习啊👍

郭丽丽 [该话题已被删除] 中提及了此贴 02月03日 13:06

后台发接口?多几个人,一个发十几个接口,服务器岂不是压力很大吗?为什么不直接用 js 发呢,直接把结果传回后台就好了?

徐旻 #10 · 2018年02月05日 Author
Karaser 回复

我相信用 js 加 mysql 肯定是最简单,最效率的实现方法,但是本人的 js 技术真的是略通皮毛而已,很多时候要考虑到个人的技术栈,和实现效率,我选择是 python。 如果你 js 很强的话,这里有一个我个人很欣赏的框架,你可以去参考一下,就是论坛中开源项目的 Hitchhiker。我开始考虑对 Hitchhiker 进行一下改造,不过考虑学习成本和本人自己的工作量就放弃了。

不过用什么语言去实现都可以,我在本文说的是一种想法和思路,论坛中有很多优秀的接口测试框架,但是把接口文档中的参数直接引用到 case 中,我是没有看到过,所以我个人觉得我这个设计中核心不是很纯粹的接口测试,怎么把文档中的参数贯穿到整个接口测试的生命周期中才是我想表达的。
我们可以想一下,如果公司的接口文档采用的 swagger,那么当接口成型以后,我这里就已经把参数都放到 case 里了,这样不但大大的提高了效率,并且如果有错误,还是马上就可以发现的(用 debug 页面去调用一下)。 这种方式比拿到接口文档后,根据文档去写 case,应该是更加效率的。

关于服务器压力,就是因为考虑过服务器的压力,所以选用 django 框架,我相信一个成熟的框架肯定有解决方案的。(在上海沙龙的时候,析隆讲师也分享过,因为当 django 框架压力大的时候,他们公司是如何处理的)

徐旻 回复

你可以尝试玩一下前端框架,Angular、Vue 等,angular 用 typescript 替代了 js,虽然是超集但是弥补了 JS 面向对象的缺点。直接读取 swagger 来运行 case 我是不反对的。只是这种把所有压力汇集到服务器的方式,感觉总是会有一天让我有理由放弃。

前面那种方式很赞同,但是感觉在添加测试用例的时候,这种方式效率并不高,开发一般只考虑几种情况,写的用例少,但是测试犹豫覆盖率的问题,当考虑多种情况时,这种手动去添加用例饿,感觉还是比较麻烦,有没有想过根据数据类型,自动生成单个字段的测试数据,在通过正交表去组合,形成最后的测试数据(目前正在尝试写这个程序,也是用 pyth,对 python 懂的还有限,前端框架更薄弱,只能边摸索,边写)

徐旻 #13 · 2018年02月08日 Author
stone9159 回复

这个工具我在以前我做的 execl 作为数据存储的时候已经做好过了。只要一个递归算法即可。不过自动生成的 case 还是很冗余的,参数就算不多,如果把值的情况都考虑的话,case 的数量也是很客观的。
https://testerhome.com/topics/7260
这里有我和别人关于参数的讨论,你有兴趣可以去看一下。

仅楼主可见
simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 12月13日 06:44
simple [精彩盘点] TesterHome 社区 2018 年 度精华帖 中提及了此贴 01月07日 04:08

非常棒!顶一下!

怎么启动呢? manage.py 文件在哪里

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