可能有人會說，寫接口的自動化CASE多簡單了，寫個參數發送請求完事了，還要注意啥？
沒錯，相比起UI自動化的case，你要去寫各種定位器，接口自動化的case寫起來確實容易多了。這也是接口自動化
的一個優點，開發效率更快。
但是寫得快，不等於寫得好，本章就聊聊接口自動化case的那些事。
一、case要易於閱讀和維護
既然是寫自動化case，那也是在寫代碼，那么，代碼的可閱讀性就不可以忽視。除了python的代碼規范，還要注意
case的結構，能讓人一目了然。
其實跟我們手動用postman測試接口差不多，把每一步的事情寫寫清楚就好。
那測試接口通常有三個步驟：
- 傳入請求參數
- 發送請求到接口
- 判斷接口返回的結果是否符合預期
這樣一來，我們在接口的自動化case中也分三步走。
def test_query_activity_manual(init_activitiy_manual, del_activity):
'''查詢可參與的活動-手動開獎'''
payload = {
"winWay":0
}
r = requests.get(activity_url, params=payload, headers=HEADER)
result = r.json()
assert result["status"] == 0
assert result["data"]["content"][-1]["id"] == 10087
assert result["data"]["content"][-1]["winWay"] == 0
這樣寫的話，是不是比較清晰呢？誰都能看懂你的代碼，自己調試代碼的時候讀着也舒心。
二、case的穩定性
1、為什么有人寫的case經常報錯
比起上面說的易於閱讀維護，自動化case的穩定性才是最重要的。如果寫的測試case跑起來總是不穩定，容易報錯，
那么接口自動化這個事情就做的沒什么意義了，使用的人也會對你的框架失去信任。
我相信，大家在寫完一個case的時候一定是調試通過的，那么為什么這個case當時能跑，過幾天就跑不了呢？在我
觀察下來，很多時間都是由於“測試數據”引起的。自動化case依賴的測試數據不穩定，或許你的測試數據被別人無意中刪掉了，
又或者你別的case產生的測試數據影響到了你這條case的測試數據等等，都是比較常見的原因。
我在工作中發現有的人喜歡調用接口來生成自己想要的測試數據，就是說依賴另一個接口來產生測試數據。這種方式有着一個
很吸引人的優點，那就是你不用去深入了解被測接口的上下游數據關系，反正調用接口后，系統邏輯會去生成對應的數據。
沒錯，這一點很誘人，但是當這個產生數據的接口掛了，或者返回了錯誤數據時，你的case必然就會受到影響了。
另外，還有的人喜歡用上一個case產生的數據來給下一個case用，這同樣的道理，上一個接口要是報錯了，下一個也必然收到影響，
但是你能說受到影響的case沒跑成功是因為接口本身有bug嗎？
很顯然不能。
2、釜底抽薪，sql生成測試數據
說白了，上述2種情況都是由於生成測試數據的方式不穩定，會產生誤傷。那么我是怎么應對的呢？
思路很簡單，我直接用sql在測試環境里生成我要的測試數據，用完再刪掉不就好了。在工作中，我也確實是這樣做的，效果很穩。
另外，最近在解讀pytest官方文檔中的fixture模塊，深深感受到了fixture功能的強大，設計的巧妙。而且人家也強調了，要保持
測試case所處環境的干凈。
所以，我的case編寫原則就是：任意一個case，任何時候都可以運行，不受其他case的影響。
我通常把單個接口的case放在一個模塊里。比如說，有6個接口，我就會寫6個模塊，每個模塊里有着對於這個接口的所有場景的測試，
像參數校驗、不同傳參導致不同結果的場景(數據驅動)等。
對於這個6個接口的業務流測試，我會單獨的放一個模塊里，在這個模塊里，就只測業務流，證明他們幾個的業務邏輯是沒問題的，不會
再去關注其中單個接口的其他場景的測試。在業務流測試里，case之間的測試數據是要傳遞使用的。
3、上述2種方式的優缺點
姑且按照順序，把上面2種方式稱為方式1、方式2吧，其中方式2是我喜歡的方式。
先說方式1的優缺點：
- 優點：測試人員不需要關注數據庫層相關的邏輯關系，簡單省事。
- 缺點：過於依賴其他創建數據的接口，只要依賴接口有問題，case必然受影響。
再說方式2的：
- 優點：不受其他接口的影響，直接在數據庫插入測試數據，用完即刪，保證測試環境的干凈，測試數據不會影響到其他case。
- 缺點：測試人員需要清楚業務邏輯背后涉及到的表關系，因為很多接口涉及到的不止一張表，比較麻煩。
其實方式2的缺點比起方式1 ，我覺得也不能算嚴格意義的缺點吧，雖然你了解表之間關系以及寫sql麻煩了點，但是也是加深了
你對業務的理解，最重要的是case穩定了，這樣的接口自動化才有意義。
三、個人的一點實操分享
或許有人會認同我的方式了，但是又擔心自己寫sql寫不好，萬一出錯咋整？
對此，沒啥好辦法，只能保證都是正確的了。這里有2個建議，可以幫助你去寫好sql。
- 自己清楚表的邏輯關系最好，不清楚，請找對應的開發請教，並且記錄下來。
- 通過頁面或者接口手動創建數據，然后去數據庫里追蹤這條數據，通過數據庫工具，復制出sql語句，然后針對性的改動即可。