前言
当前项目所使用的接口自动化，用的是之前写的unittest+ddt的。偶尔上BOSS看了一些招聘消息，就花了点时间学习pytest，然后写了这个接口自动化：pytest+allure。
思路
1、主体思路
采用数据驱动：
yaml文件管理测试用例，一个yaml文件最好对标一个接口，然后有不同情况的请求/判断数据
请求需要处理数据依赖的情况，因为用了requests.session()进行会话保持，所以排除cookies的依赖。需要处理的是其它参数的依赖，比如：支付请求的参数订单号的值，来自于确认订单的响应参数订单号的值。
解决方案：
1）依赖数据变量开头用orderid（一个请求中，不能出现多个同名依赖数据变量）
2）需要指定提取该变量的测试用例
3）需要指定需要提取的变量名，比如：
4）对应的测试用例，需要指定要提取的变量，以及值在response的位置，比如：
ps.variables指定的变量名需要和relevance中指定的变量一致，就比如上面，从login提取code_value和data_value，那么login.yaml提供该数据的请求中，relevance也需要指定code_value和data_value（暂时没处理如果有多个相同的情况，默认取一个）
测试用例的数据，通过@pytest.mark.parametrize("param, title", test_params)传递
param：每次请求的内容
title：该请求的标题
2、难点：
难点1：处理依赖数据；还是用上面的例子：支付请求的参数订单号的值，来自于确认订单的响应参数订单号的值。
1）在“支付请求”测试用例pay.yaml中，比如url上需要带上orderid，写成：http://www.xxx.com?orderid=$orderid
2）然后说明该参数值需要去“确认订单”测试用例order.yaml中去获取，所以用例pay.yaml中写上：
3）比如orderid需要取自一个正确下单的请求用例，那么就在“确认订单”测试用例order.yaml该请求用例中，写上：
逻辑解释：
1）处理yaml数据时，发现一个接口请求数据中有$开头的数据，则添加到一个list中，然后该list值会以dict{variables_data:[orderid]}的形式，组装在这个接口请求数据中（非全局）
2）同时，如果发现一个接口请求有步骤2的结构，则会处理成这样：variables: [{'login': ['orderid']}, {'xxx': ['xxx','xxx']}]
当发现一个接口请求数据，同时有variables_data和variables这两个值，那说明这个接口需要其它用例提供依赖数据值
3）根据variables: [{'login': ['orderid']}, {'xxx': ['xxx','xxx']}]，找到login.yaml这个测试用例文件，然后读取该文件内容和进行判断，看哪个用例中存在relevance: {'orderid': 'content.data.orderid'}，说明所想要获取的orderid的值，取自于这个用例请求response的content.data.orderid。那么就会发送这个请求，在响应中取值response.content.data.orderid。比如说如果orderid=10
4）接着把这个值，替换到http://www.xxx.com?orderid=$orderid中，也就是http://www.xxx.com?orderid=10。然后发送该请求
难点2：把yaml用例数据，解析成适用
@pytest.mark.parametrize()的数据格式
@pytest.mark.parametrize("param1, param2", params)，其中的params所需的数据结构需可迭代，比如[ [param1_1, param2_1], [param1_2, param2_2]... ]。那么每次获取传递来的就是里面的[param1_x, param2_x]
yaml读取的结构，自行百度；然后详细代码逻辑就不说明了。
代码目录结构
大体业务逻辑
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
