经验分享|关于自动化接口测试平台的想法和实现,这个方法最简单真实有效

目录

前言
平台
工具
现实
测试用例管理页面
报告
感受

前言

随着软件行业的快速发展,人们对软件的需求日趋增加,软件规模不断变大.随着软件规模和复杂度的不断提高,相应的对软件测试要求也不断提高,传统的手工测试已无法满足不断扩大的测试工作,我们应该去学习相关行业最前沿的技术才能保证不那么早被行业淘汰。
经验分享|关于自动化接口测试平台的想法和实现,这个方法最简单真实有效
文章图片


点击链接进群免费领取资料:321255410【备注777】
很满意的同学,可以从接口文档管理系统的数据库里直接拿到接口的参数,如果是 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。
经验分享|关于自动化接口测试平台的想法和实现,这个方法最简单真实有效
文章图片

?点击链接进群免费领取资料:321255410【备注777】 ?
然后来看我写的一个 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。
其实可以做的事情还有太多太多,根据实际的工作情况去做才是最有效的。要做一个泛用的框架真的需要很多精力,还是尽力做一个能用就好的。工作有了效率,才有可能拿到更多资源去学习和构建更多的好的工具。
接口测试还是需要好的思路,很多方面,比如测试数据的部署,测试用例的强壮。

衷心感谢每一个认真阅读我文章的人如果我的文章对你有用的话请你帮忙点个关注吧
?点击链接进群免费领取资料:321255410【备注777】 ?
经验分享|关于自动化接口测试平台的想法和实现,这个方法最简单真实有效
文章图片

【经验分享|关于自动化接口测试平台的想法和实现,这个方法最简单真实有效】

    推荐阅读