接口業務用例的思考
有個問題思考很久，業務流程的自動化應該如何實現？是不是應該做十幾個接口的業務測試？
咨詢好些大佬，
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就生成對應的業務方法，這很美！