接口业务用例的思考
有个问题思考很久，业务流程的自动化应该如何实现？是不是应该做十几个接口的业务测试？
咨询好些大佬，
A：看成果，有效果有时间都可以做。
B：业务流程的接口测试交给系统测试来做是不是会更好？
后者的话似乎有点让我自省~，我又反问他，那你这样说，接口的依赖你如何处理？
B：Mock解除依赖！
至此后，很久才明白。调用三方接口，Mock是个不错的选择
而大佬的话，是说用Mock解除所有的依赖问题，相应其实Mock后的数据都是假的数据，我不这样做，
但不反对这样的做法，因为有时前端在写代码时后端没有完成，也是通过Mock来解决的。而假数据就像在后端写死的验证码一样
其次，业务用例，投入与回报不一定成正比
所谓的集成测试，应看看重接口里的单元组合是否正确实现
只有接口调用时不得不解决所涉及的依赖问题，而形成接口之间的互相调用，这样构成的业务测试才是需要做的！
一条用例的自动化应该做什么！
看起来简单的问题，实际上做起来没那么容易
举个例子：
账号、密码注册，测试注册成功
1、检查数据库是否存在该账号，有sql删除，没有跳过
2、传入参数调用注册接口，断言响应
3、sql删除该账号
处理接口测试之间的前置后置，可以使用接口、数据库方法解决，也可以混合
如何优雅
花了很多时间探索后才发现pageobject
元素层 + page层+ case层的相互调用似乎是已是标准
如何使用python 优雅的实现考验那个曾经为之努力的ceshiren
步骤：
①一起从case开始吧！
这是获取会员列表的正向case
参数分别是：页码、页数、排序方式、是否排序
实现接口调用，参数传入、获取响应、结果断言
怎么样优雅这个问题，在于page里方法的实现
@pytest.mark.parametrize("case", ViplistData.case)
@assert_logger
deftest_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就生成对应的业务方法，这很美！