看到這樣一個問題：介面自動化測試中，有必要把介面返回的每個欄位都進行斷言嗎？
無論是效能測試還是自動化測試中，要不要設定斷言，為什麼設定斷言，斷言的作用是什麼，如何設定斷言，都是新手容易踩坑犯錯的地方。
這篇文章，聊聊我對於斷言的理解，以及自動化測試如何斷言。
1、什麼是斷言？
先聊聊我對斷言的理解。
設計測試用例的方法相信大家都深諳於心，最基本的要素有場景、操作步驟、輸入和輸出值，目的是驗證測試用例對應的業務場景或功能是否如預期實現。
預期輸出值可能有一個也可能有多個，在功能測試場景中，我們可以透過介面返回或渲染的結果，與產品需求描述和UI設計進行對比，如果符合需求描述和UI設計，則判定該測試用例執行透過。
這裡的斷言方式，可以理解為人工透過對比來判斷測試結果的正確性。
在介面測試場景中，輸入不同的請求引數有不同的返回報文，常見的做法是透過抓包或者觀察response body中的返回值來判斷程式返回結果是否否和預期。
這裡的斷言方式，可以人工檢查也可以透過工具或者編寫程式碼設定斷言來對返回結果進行判斷。
所謂斷言，就是一種結果判斷的手段，即判斷結果是或否的方式。
2、為什麼設定斷言？
無論是研發崗還是測試崗位，都要對自己的工作結果進行判斷。
研發在本地開發完成後需要自測，判斷自己編寫的程式碼是否如需求描述一樣實現。測試同學需要對研發提交的程式碼程式進行各種驗證，判斷程式實現的功能是否符合需求描述和產品要求，以及是否滿足流轉到下一階段(驗收/釋出)的標準。
用比較專業的話來說就是准入準出標準，而斷言的作用就是儘可能透過機器(工具/程式碼)來進行判斷，避免人工檢查可能帶來的遺漏等問題。
以介面測試為例，一個好的斷言設計可以帶來如下幾點好處：
- 驗證介面返回資料是否符合預期，判斷功能實現是否正確。
- 自動化執行，提高測試效率和準確性，減少人為因素的影響。
- 當結果不符合預期時，可以幫助技術同學快速排查和定位問題。
3、一些設定斷言誤區
很多新手在剛開始進行介面測試或者自動化測試時，最容易犯的錯誤就是不設定斷言，或斷言的物件為HTTP狀態碼。為什麼不提倡和不建議大家用HTTP狀態碼來作為斷言物件呢？原因有如下幾點：
首先，HTTP請求本身是無狀態的，HTTP狀態碼只是表達了當前請求的處理情況，與業務正確與否無關。比如出現404狀態碼時，被請求服務本身可能沒問題，而是你的請求URL地址有誤。
其次，HTTP狀態碼只代表了當前請求自身的情況。比如200狀態碼，代表請求是通暢的，服務端接收了你的請求併成功返回了響應資料，但不代表業務是正確的(下單失敗的HTTP狀態碼也是200，但業務角度來說是失敗的)。
4、如何設定測試斷言？
以文章開頭的問題為例，從介面設計層面來看，設定斷言至少需要驗證如下幾點：
資料結構驗證：驗證介面請求返回的資料結構是否與介面定義一致。服務端在收到請求後，會按照事先定義好的資料結構來解析並處理資料。如果輸入的資料結構發生變化或者與事先定義的不一致，則會導致服務端丟擲異常。
關鍵數值驗證：根據業務場景不同，可以有目的性的驗證某些 key-value 的鍵值對結果是否符合預期，同時輔以查詢資料庫進行資料落庫確認的方式來綜合驗證。
舉例：假設業務場景是建立訂單，如果建立成功，則響應報文中除了HTTP狀態碼需要返回200之外，還需要設定業務狀態碼(success status=0)。同理，如果建立失敗，則業務狀態碼success status=1。
要做到這點，有兩個制約因素：1-測試同學對業務的熟悉程度；2-介面設計中需要事先對不同的業務場景結果定義不同的業務狀態碼。
其他型別驗證：如返回資料必填非必填，URL訪問許可權校驗(授權)等。
還有一些特殊情況，比如響應報文中的資料過多，則建議只對關鍵業務狀態相關的key-value進行斷言，其他資料則僅進行格式校驗即可。