前言
当前项目所使用的接口自动化,用的是之前写的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),我们将立即处理