接口自動化測試用例如何設計
轉載請註明出處❤️
作者：測試蔡坨坨
原文鏈接：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去調用用戶信息查詢接口獲取一整套用戶信息數據。
對於接口自動化測試用例的設計，可能不同的人有不同的思路和想法，我們要做的就是取其精華，把一些好的思路和方法在具體項目中實踐，並形成一套自己的經驗總結。
