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

徐旻 · January 25, 2018 · Last by 此生不换 replied at June 17, 2019 · 6156 hits

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

本来加入论坛已经过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。
其实可以做的事情还有太多太多,根据实际的工作情况去做才是最有效的。要做一个泛用的框架真的需要很多精力,还是尽力做一个能用就好的。工作有了效率,才有可能拿到更多资源去学习和构建更多的好的工具。

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

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

厉害,值得学习一番

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

厉害

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

开源?

bill 回复

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

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

bauul 回复

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

徐旻 回复

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

郭丽丽 线下班第二期 Bash 教程 中提及了此贴 03 Feb 21:06

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

徐旻 #10 · February 05, 2018 作者
SheldonBean 回复

我相信用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 · February 08, 2018 作者
stone9159 回复

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

Author only
simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 13 Dec 14:44

非常棒!顶一下!

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up