可能有人會說，寫介面的自動化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陳述句，然后針對性的改動即可，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/271851.html
標籤：其他