一.介绍
之前学习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参数。