引言
與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在這個問題上提供的解決方案為：a.對於少量的測試資料，可在介面內填好測試資料集供介面每次呼叫；如果是大量的資料，才使用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做介面自動化測試的具體流程和思路就介紹到這裡，希望對大家有幫助。