轉載請註明出處❤️
作者：測試蔡坨坨
原文連結：caituotuo.top/bc90038a.html
你好，我是測試蔡坨坨。
說到自動化測試，或者說介面自動化測試，多數人的第一反應是該用什麼工具，比如：Python Requests、Java HttpClient、Apifox、MeterSphere、自研的自動化平臺等。大家似乎更關注的是哪個工具更優秀，甚至出現「 做平臺的 > 寫指令碼的 > 用工具的 」諸如此類的鄙視鏈，但卻很少有人去關注介面測試用例的設計問題。
在我看來，工具並沒有高低貴賤之分，只能說哪個更適合，適合當前的業務以及適合當前的團隊共同作業。
自動化測試的本質還是測試，自動化只是為了提高測試的效率，而測試的基礎是測試用例，因此我們不應該忽略介面自動化測試用例的設計問題。換言之，當你掌握了自動化測試用例的設計思想以及方法，無論用什麼工具，都能得心應手，因為工具的東西多練多操作肯定能學會，而思維認知的東西則需要在學習他人好的方法的基礎上自己琢磨領悟，並形成一套自己的經驗總結。
想象一下，迴歸測試的時候，成百上千的介面執行下來，沒有報錯，我們真的對系統放心嗎，我們又是怎樣衡量自動化指令碼是否合理的呢？
所以，今天就來聊聊介面自動化測試用例如何設計。
與介面功能測試相比，除了要明確需求和測試目標之外，介面測試還需要有針對性地去設計測試資料和介面的組合，確定介面資訊通常有兩條路徑，一是通過介面檔案獲取，二是通過介面抓包獲取。
開發人員一般不喜歡寫介面檔案，同時也討厭別人不寫介面檔案，就像程式設計師一般不喜歡寫註釋，同時也討厭不寫註釋的程式碼，所以測試人員想要獲取一份相對完善的介面檔案有時是比較麻煩的，這就需要驅動開發人員提供，這對於開發人員來說並不困難。
統一的介面檔案管理方式也是比較多的，比如：在wiki上建立一個介面檔案目錄空間專門用於維護介面資訊、系統後臺管理中有專門的介面檔案模組、在需求單子下面備註、使用apifox工具進行介面檔案的維護管理等。同時現在也有很多外掛或工具能夠幫助開發人員自動生成介面檔案，比如：swagger、apidoc、yapi。
作為測試人員需要關注介面檔案的有效性和及時性，包括：Request URL、Request Method、Content-Type、請求引數、響應結果、請求範例等。
如果沒有介面檔案，那就只能自己動手豐衣足食，通過抓包分析的方式來獲取介面資訊，常見的抓包工具比如：瀏覽器F12、Fiddler、Charles等，還可以把Fiddler抓到的介面匯出，通過工具轉成介面平臺可識別的指令碼，進而提高效率。
在獲取到介面資訊後，還需要與開發人員多進行交流，明確介面引數的含義和來源，以便於我們有針對性地進行用例的設計，有不明確的點應當直接找開發同學問清楚，而不應該自己過多的猜想，避免自己的猜想有誤造成後續用例設計的錯誤。在此階段，還需梳理介面的優先順序和重要程度，根據優先順序順序進行用例設計，在有限的時間內，做最大價值的事。
單介面測試主要驗證介面的請求地址、請求型別、請求格式、請求引數、許可權、返回值等為主，目的是保證介面能跑通，這類用例一般在介面設計完成後定稿，使用過程中可配合Mock服務完成用例編寫。
場景邏輯驗證是以使用者場景為基礎，驗證介面間的引數傳遞和業務流程是否能夠正常流轉，比如：使用者註冊介面 --> 使用者登入介面 --> 修改使用者資訊介面，使得業務流程形成閉環。
這個階段的用例複雜度較高，需要非常熟悉業務與介面之間的關係，同時也是介面測試的核心部分、最有價值的部分。
與介面功能測試類似，除了測試各種正常場景外，還需要驗證各種異常情況，主要驗證引數異常，比如：某個引數的型別是String，當你傳入其他型別時是否會報錯並給出提示；某個引數的長度限制200個字元，當超過200個字元時是否給出提示；某個引數是必填，當不傳為空時是否有非空判斷。還需要驗證邏輯異常等情況下介面是否能夠處理並給出友好的提示資訊、提示是否準確清晰以及返回的資訊是什麼。通常情況下，關注引數的異常場景會比較多，可以用等價類、邊界值等方法進行傳參的設計。
所有用例應該是非互動式的，能自動化就不要手動去獲取。最常見的就是token的獲取，獲取token的方法也有很多種，最常用的就是通過呼叫登入介面獲取返回值中的token，用於後續介面的鑑權，還有一些開放平臺介面，token有特定的生成規則，就可以將其寫成指令碼自動生成token，而不是每次執行測試用例之前，需要手動生成token再複製貼上到指令碼中，特別是分環境測試時就會很麻煩，而且token一般是有有效時間的，寫成自動化指令碼，每次都獲取都是最新的，就不用擔心token過期的問題了。
用例之間相互獨立，不能有依賴，需要在每一個用例裡處理好前置條件，而不是多個用例相互依賴。
用例測試應該是可以重複執行的，因此需要注意引數的生成方式。
黑箱測試的重點是輸入和輸出，其實整合後的介面測試也屬於黑箱測試，也許我們不需要關注內部的程式碼是如何實現的，更多的是關注請求引數和響應結果，因此在設計用例時，需要重點關注斷言的設計，好的斷言能夠幫助我們發現問題，沒有斷言的用例或者指令碼就是在耍流氓，完全沒有意義，如果沒有斷言，全部用例都是pass，那我們也無法真正對系統放心，無法確保一定沒有問題。
從介面層面上看，我們至少需要關注兩方面的驗證，一是資料結構驗證，二是核心數值驗證。
資料結構驗證就是校驗介面返回的資料結構是否與事先約定好的一致，呼叫方在處理資料時，肯定是按照事先約定好的資料結構來解析資料，如果資料結構發生了變化，那麼對呼叫方來說，無疑是災難性的事故，也就是說之前已經開發完成的程式在對接時就會出錯，導致需要重新開發。
核心數值的驗證需要根據不同的業務場景，有針對性地驗證某些鍵值是否與預期一致，同時可以結合資料庫查詢的方式來驗證，比如：使用者註冊介面呼叫成功後會返回一個使用者ID，此時就可以使用SELECT * FROM user_table WHERE user_id = "";以判斷是否真的註冊成功，這個比較依賴於測試人員對於業務的瞭解程度，根據實際情況靈活設計即可。
除此之外，還有一些額外的驗證點在需要的時候也可以進行校驗，比如：返回的URL是否能存取、涉及到資料流轉的、返回的資料是否真的有必要（避免返回資料量過大導致意外情況發生）。
通過新增合理的斷言，才能讓介面自動化用例有一定的業務價值，能夠真正幫助到團隊提升效率，這樣的測試結果才能讓人安心。
介面自動化測試中一個很重要的環境就是測試資料的準備，要想讓指令碼可以在多套環境中執行，那麼測試資料就不能寫得太死，需要根據具體環境去自動獲取一些資料值。
公共引數就是通過不同作用域或標識的區分，有一個專門的模組來處理一些公用資料的存放，比如：不同環境的賬號密碼，不同環境的URL等。
通過特定的API或資料庫SQL，事先生成一些所需的資料作為前置條件，然後存放到一個特定的集合中，需要的時候再從資料集合裡面取。
由於測試環境一般會有多套，為了方便環境的切換，我們不應該把太多的資料資訊寫死，而是通過填寫一些簡單的資訊，再呼叫基礎介面，自動生成一整套業務資料，比如：使用者資訊包含使用者名稱、手機號、郵箱、註冊時間等，此時我們不應該把這些資訊都寫死，而是通過使用者id去呼叫使用者資訊查詢介面獲取一整套使用者資訊資料。
對於介面自動化測試用例的設計，可能不同的人有不同的思路和想法，我們要做的就是取其精華，把一些好的思路和方法在具體專案中實踐，並形成一套自己的經驗總結。