一.介绍
之前学习robotframework的时候,知乎上有人推荐这个框架,高呼pytest大法好,正好最近要重构一个项目的服务端接口自动化测试框架。
学了一下,确实很好用,分享出来一个自己,希望有所帮助吧。
二.功能
+ 数据驱动
- 针对接口测试的特点(同一业务场景对某一功能接口各种参数请求校验接口的返回)Mongo基于文档存储,省去json序列化转换操作,测试类+测试方法映射到Mongo中一个集合,集合中每一条数据依次执行测试方法中的业务逻辑。例如,使用各种不同的组合数据登陆,或购买各种规格,数量的商品。
- 下图为项目中一组数据示例,利用pytest的pytest_generate_tests的hook 将数据库中的对应的集合的数据赋值data和scm。
data作为数据,scm作为返回的校验模板。
-
数据动态渲染
- 支持数据动态替换,如‘{{ DevToken }}’,替换变量,{% int %}替换为函数。
- {'tu': ['{{ val }}', {'newkey': '{{ val }}'}],
'key': {'str': '{% fake.pystr(max_chars=10) %}',
'phone': '{% fake.phone_number() %}',
'company': '{% fake.company() %}'}
}
------->
{'tu': [456, {'newkey': 456}],
'key': {'str': 'CxtMTqAhLY',
'phone': '13319170599',
'company': '精芯网络有限公司'}
}
-
Schema 模板使用
- 支持部分校验,只校验scm中有的key值
- 规则支持函数 例如
{
"data" : "{% str %}", #校验返回的data是个字符串对象
"traceID" : "{{ traceID }}", #校验traceID相等
"message" : "token错误", #校验返回的message
"code" : "00120112001",
"success" : false #校验布尔值等于false
}
-
优化配置文件,
-
将不同环境的配置信息保存到config文件,执行时通过不同的env参数(--env=online --env=test)加载不同的配置信息到不同的环境执行测试,如host地址,用户名密码,等
三.可维护性
这样分层组织的好处,提高了代码的复用,模块化之后,是测试逻辑更加突出。后期迭代有的接口参数如果有变动,只需要在project_lib中或者fixture中进行修改。testcase只关注业务逻辑。
testcase | 引用fixture组合出测试场景,针对特定接口功能的测试用例 |
scenario | 测试用例场景模块,根据不同粒度组合一些场景,如:测试订单的操作,商家登陆商家上架一个商品,用户添加商品提交订单生成一个订单。基于这个场景进行订单的取消,结算的测试。 |
fixture | Pytest中的类似xUnit的setUp和tearDown,配置scope=(session/class/function),使用起来更加灵活。 |
lib | 依产品线定制,添加接口公共参数,签名算法 特殊接口数据处理。 |
Req | 实现基本send方法,公共的数据渲染、返回校验,打印日志等方法 |
四.与jenkins结合
jenkins就没什么可说的了,安装一个Allure的插件。配置生成报告命令。
csdn这个破编辑页面真特么难用。就这样把不想写了,fuck。
五.代码
简单的demo上传到github。https://github.com/Be5yond/pytest_demo.git
---------------------------------------- 2018/10/27--------------------------------------------------
看到github有兄弟fork了这个项目,可能还是有点用的,更新一下吧。之前采用mongodb佐数据驱动是因为那个项目的开发设计的api参数嵌套太深,不好处理。结构比较好的接口一般都是格式差不多的,可以用excel来存储测试数据,看起来更加直观,映射方式也很简单,测试类对应一个excel文件,每一个方法对应一个sheet,sheet中的每一行就是一条testcase。
对于某些接口不需要关心的参数,在lib层使用DefaultData方法将默认参数填进去,避免测试数据文件中很多重复的数据。
像调用get_test发送请求parameter中会默认添加StartTIme,EndTime和Type参数。