引言
與UI相比，接口一旦研發完成，通常變更或重構的頻率和幅度相對較小。因此做接口自動化的性價比更高，通常運用於迭代版本上線前的回歸測試中。
手工做接口測試，測試數據和參數都可以由測試人員手動填寫和更新。
因此我們在考慮將接口用例實現自動化的時候，主要思路就是在單個接口請求的測試用例已經完成的前提下，我們如何解決以下問題：
- 業務測試場景會調用不止一個接口，下一個接口的請求依賴於上一個接口的數據，需要解決接口依賴問題
- token等鑒權數據有過期時間，多個接口用到該參數，需要解決一次修改，多處生效的問題
- 一個接口要用到多個測試數據做覆蓋
- 批量測試下，需要知道某個接口返回的參數/數據是否符合預期
本文使用的自動化接口測試工具為Apifox,官網下載地址：www.apifox.cn 直接下載注冊安裝后即可使用。 接下來依次講解下上述問題如何使用apifox解決。
正文
一.接口傳參
舉一個常見的場景說明。查詢接口請求獲取數據的時候，需要帶一個access_token的參數，而access_token參數需要另外的鑒權接口獲取。因此需要鑒權接口將獲取到的token參數傳遞給查詢接口，查詢接口才能發起請求。
另一個常見的場景是，用戶需要先登陸，才能將選中的商品加入購物車。 這個接口順利發起請求依賴於上一個接口獲取數據。 手動測試的情況下，直接人工復制即可。
解決方案： 需要將上一個接口返回的數據進行識別提取出目標參數，保存為全局變量，下一個接口直接調用參數。
步驟： 1）在apifox的接口tab-后置操作tab，選擇提取變量
2）填寫變量名稱，變量類型和提取的表達式。提取表達式符合json path 語法。在本接口數據中由於返回數據只有一層，因此采用$.目標參數的方式提取。 如果有多層參數，可以點擊提取表達式旁邊的問號，查看詳細的json path語法。
獲取到的參數以變量的形式存儲，點擊接口tab右上角的設置圖標，可以查看到獲取到的環境變量的值。
接着就可以在下一個接口，以參數的方式調用：
二. 外部數據源
一些post數據給后台處理的接口，需要對上傳不同的數據來測試接口的返回和異常兼容，一個接口參數需要多次使用不同的數據。 手動情況下我們可以直接在參數里填數據，之后每次手動改。
但如果實現自動化的話，像上述的測試方式難以實現。 常用的解決方案是先編輯好csv文件，將測試數據一一寫好保存，最后傳入到接口請求參數中。
Apifox在這個問題上提供的解決方案為：
對於少量的測試數據，可在界面內填好測試數據集供接口每次調用；如果是大量的數據，才使用csv文件；更少量的數據則可以直接寫在全局變量中。
以全局變量的方式導入和上節講到的接口傳參類似，區別只在於測試數據不是從上一個接口獲取到而是的我們自己填進去的。 若是使用外部測試數據集，在測試管理tab>用例界面右側，有一個測試數據的開關項，打開即可導入測試數據。當然首先需要先把用例導入到測試步驟中來。
如圖所示，我已經將OCRtest（文本識別接口，功能為識別圖片上的文字）接口導入用例步驟中，啟用了外部測試數據，
接着點擊管理測試數據，跳轉到測試數據tab：
在這個界面開始 新建/導入測試數據。此處數據集名稱是給測試人員識別的，不會傳入到接口里，一個數據集（1行）代表該次運行中所有需要傳入的測試數據，列名作為接口參數，接口每次發起請求，會依次調用該列下的其中一個值。
運行時，每一條測試數據都會當成一條測試用例來運行。
在上面講到的“接口參數傳遞”和“傳入測試數據”兩個的思路是一樣的，依賴於apifox提供的參數化功能，上傳的數據參數以外部數據集的形式與接口分隔開來，將關鍵字段，不斷變化的數據抽取出來獨立於單個接口；
配置完成之后，接口每次運行都能夠自行生成，傳遞和導入關鍵數據，如果需要修改，只需要在一個地方，一個文件內批量修改就能夠全局生效。 這其中有軟件工程中的抽象和封裝思想，而接下來會講到的斷言是另一種思路。
三. 測試斷言
手工運行測試人員可以自行看接口請求是否成功，數據是否正常，但在自動化實踐中，我們則需要代碼幫我們判斷實際返回和期望返回是否匹配。
http響應文本是高度結構化的，因此我們的期望返回無非是header和body中的響應狀態碼，關鍵字段，和關鍵值應該為某個值。只需要判斷這些字段是否我們想要的即可。
斷言是專門用來驗證輸出與期望是否匹配的工具，在測試實踐中，我們一般通過比較實際輸出值和輸入值來校驗的，即我們要判斷返回數據“是否存在”“是否包含”“數據是否等於”“文本是否等於”。
因此判斷用例請求結果的實現方案可分為三個要素：判斷對象，校驗方法，校驗值與期待值。
思路明確了，接下來看如何用腳本/功能實現。Apifox的斷言功能面板（路徑：接口tab>運行>后置操作>斷言）的可斷言對象包括了響應數據中的JSON，html和xml，header，cookie，基本上可以滿足我們的要求。
校驗的方法為斷言對象的值是否符合測試人員規定的值范圍
被校驗的值可通過json path 表達式提取
那么像對狀態碼的判斷，某個確定返回值的校驗這個，可以直接使用apifox提供的功能面板進行操作就行了。如果測試人員想要更加靈活的斷言方式需要在后置操作里選擇自定義腳本。
對於不太熟悉腳本的測試人員，可以使用Apifox右側提供的代碼模板，點擊就會添加到左側的腳本編輯面板里，基本上只需要修改斷言的期望值就行了，難度不大。
如果是對單個接口做測試，斷言結果會直接在響應tab返回
如果是批量測試，在測試結果里會顯示斷言結果：
這樣我們構建接口自動化用例中的“結果判斷”的問題就解決了。
四. 環境切換
接口在測試服測試通過之后還需要一輪線上驗證，測試任務才算完成。
通常測試服和正式服的的區別只在於前置URL不同。為了讓線上驗證環節不耗費太多重復活動，我們這里可以在自動化項目開始構建的時候就先利用apifox提供的功能進行配置。 將項目里所有接口共用的http協議和域名配置到前置URL中，接口地址只填資源路徑和參數。
進行線上驗證時，將參數配置和數據配置同步更新/切換為線上數據配置之后，只需要在運行環境里切換環境，就可以進行線上驗證。
五. 批量測試
1.用例組織形式 apifox里，用例是以測試用例--用例組--測試套件的形式組織的。 一個測試用例可容納多個測試步驟，一個接口請求為一個步驟。 接口用例可直接從接口用例導入。如果設置和接口同步，那么接口一旦變更，測試用例這邊也會同步變更。
一個常規用例步驟如下，涉及多個接口，接口之間存在參數傳遞，多個接口完成一個業務場景的測試。
接口用例導入完畢之后，進行測試參數配置，點擊運行即可自動運行。
2.用例執行順序
在一條測試用例里，接口請求的順序由上到下依次執行，如果需要變更接口請求的步驟，只需要拖動接口移動到新的位置上去即可。
3.測試套件運行 一個接口用例完成一個業務場景/一個業務流程的測試，一個測試套件包含多條用例，可將相同模塊的用例集中到一起執行。這種用例組織模式和測試人員常用的用例管理軟件testlink的組織方式實質是一樣的。 這樣只要點擊運行，就可以一鍵完成一個業務模塊的接口測試。
測試完畢后會顯示用例測試結果，上方面板為整體執行情況，下方分條列出具體用例執行結果。 如果需要導出測試報告，點擊按鈕可一鍵生成html格式的文件。
總結
一.接口自動化的工具思維和測試思維
我們這個接口自動化項目的搭建和執行基本都是圍繞Apifox提供的功能進行的。和postman相比，用起來的感覺是特別順手，用例的組織和測試的思維模式基本上也是幾個大中廠都在用的，也符合國內測試組的工作流程，程，是工具來適應人，而不是人去適應工具，在理解門檻和思維切換這點上成本大大降低。
項目一路構建下來，基本都是功能界面的操作，幾乎沒有需要腳本的地方，對於不熟悉腳本的測試人員來說，可以用它來短時間快速完成測試任務。
如果大家不怎么熟悉那些英文測試術語，用起這個本土接口測試軟件，理解成本少點，可能效率會更加高一點。
二.貫穿整個接口自動化項目的三個基本思路：
a.單個接口的測試數據和變量參數化，接口測試結果進行斷言
b.單個接口用例以業務測試場景為框架搭建，接口依賴通過參數傳遞&接口執行順序解決
c.用例組織以業務模塊和業務流程、邏輯為框架組織成測試組和測試套件，方面后期迭代和更新維護
本文用APifox做接口自動化測試的具體流程和思路就介紹到這里，希望對大家有幫助。