接口业务用例的思考
有个问题思考很久，业务流程的自动化应该如何实现？是不是应该做十几个接口的业务测试？
咨询好些大佬，
A：看成果，有效果有时间都可以做。
B：业务流程的接口测试交给系统测试来做是不是会更好？
后者的话似乎有点让我自省~，我又反问他，那你这样说，接口的依赖你如何处理？
B：Mock解除依赖！
至此后，很久才明白。调用三方接口，Mock是个不错的选择
而所谓的业务用例，投入与回报成正比
一条用例的自动化应该做什么！
看起来简单的问题，实际上做起来没那么容易
举个例子：
账号、密码注册，测试注册成功
1、检查数据库是否存在该账号，有sql删除，没有跳过
2、传入参数调用注册接口，断言响应
3、sql删除该账号
如何优雅
花了很多时间探索后才发现pageobject
元素层 + page层+ case层的相互调用似乎是已是标准
如何使用python 优雅的实现考验那个曾经为之努力的ceshiren -> 代码始于颜值终于才华
步骤：
①一起从case开始吧！
这是一条获取会员列表接口测试的正向用例，参数分别是：页码、页数、排序方式、是否正序
调用如此简单，1、调用会员page下的会员列表接口，2、传入所需参数 3、获取响应 4、响应断言
关键就在于调用的api如何实现
@pytest.mark.parametrize("case", ViplistData.case)
@assert_logger
def test_viplist(self, case):
"""B端会员列表"""
r = self.vip.viplist(pageindex=case[‘index‘], pagesize=case[‘size‘],
orderfield="createtime", ordertype=0)
assert r.success is Truez
②page层
什么是page？页面，页面下的功能点、方法，都归属这个页面
这样一来其实就对接口分了一下类，就比如会员下，有获取列表、新增会员、删除会员等
其实实现，无非就是传入数据给发送请求的方法而已
用了1个装饰器来重复造轮子，没错这很pythonic !
class Vip(WeShop_B):
def __init__(self):
self.apipath = YAML_DIR + r"\vip.yaml"
self.apiyaml = self.api_yaml(file=self.apipath)
@api
def viplist(self, pageindex, pagesize,
orderfield, ordertype) -> res:
"""
获取pc会员列表
:param pageindex: 当前页数 1
:param pagesize: 一页数量 10
:param orderfield: 排序字段 createtime
:param ordertype: 排序(0-正序，1-倒序)
:return:
"""
pass
def api(func):
@functools.wraps(func)
def magic(self, *args, **kwargs):
func(self, *args, **kwargs)
base_api: Base = self
method = func.__name__
base_api.params.update({name: vaule for name, vaule in zip(func.__code__.co_varnames[1:0], args)
if args is not None})
base_api.params.update(kwargs)
req = base_api.api_yaml(file=base_api.apipath)[method]
res = base_api.api_send(req)
写在最后：
元素层 1个yaml\json就要写 1个page。好像还是不够pythonic
正在朝着扫描yaml进行测试的路前进~
原文：https://www.cnblogs.com/zhayi/p/14705703.html