為什麼要做介面自動化
相對於UI自動化而言，介面自動化具有更大的價值。
為了優化轉化路徑或者提升使用者體驗，APP/web介面的按鈕控制元件和佈局幾乎每個版本都會發生一次變化，導致自動化的程式碼頻繁變更，沒有起到減少工作量的效果。
而介面一旦研發完成，後期重構/大幅度修改的頻率則比較低.因而做介面自動化價效比還是很高的，對於迭代版本舊有功能的迴歸，beta測試，線上迴歸都能起到事半功倍的作用。
本文不詳細談單個介面的測試，我們來主要來分析一下基於業務場景的介面自動化怎麼做。
問題在哪裡
一個業務場景通常需要多個介面才能走完一個完整的業務流程，其中每個介面完成一個特定的功能步驟。例如微信的新增好友流程：
每個操作步驟裡都至少有一條介面請求。那麼我們把這個流程以介面請求的方式表現出來，如下：
我們想要完成這條介面用例，需要的操作有哪些？
1)輸入微信id，發出查詢請求
2)將獲取到的使用者資訊傳遞給“新增好友介面”，發起新增好友請求
3）將申請好友的使用者資訊傳給下發好友申請介面
4）將同意資訊傳給成為好友訊息介面
5）將拒絕資訊傳給拒絕訊息介面
概括起來有幾個需要解決的問題：測試資料傳入，介面依賴，介面間引數傳遞。
這也是介面測試自動化中會遇到的普遍問題，解決方案可以遷移到各類業務中去。接下來筆者將針對上述問題提出一些具體的解決方案
工具介紹 本文所用介面測試工具： Apifox Windows版
Postman作為介面測試工具，在業界的地位毋庸置疑，但Apifox作為一款本土的介面除錯、介面測試&測試管理軟體，優勢在於符合國內網際網路的測試模式和工作流程,用起來更順手些。
大部分功能均能由視覺化介面+控制元件操作完成，對於不懂程式碼、不會寫指令碼的測試人員，基本也可以無痛順利地完成介面自動化的任務。
因此本文講解自動化的時候會直接使用Apifox，大家如果需要跟著文章講解學習的，可以先去官網（www.apifox.cn ）下載註冊一個，軟體免費。
全靠引數化
手工測試的優點在於靈活可控，自動化則依賴我們預先設定好的步驟完成功能
介面間引數傳遞
像上述微信好友請求的例子，涉及到多個介面間的引數傳遞，下一個介面對依賴於上一個介面響應中的某個欄位，需要將它能準確提取並傳遞過來。
解決方案：提取上一個介面響應資料--引數化--下一個介面呼叫該引數。
這樣無論介面執行多少次，傳遞的引數怎麼變化，下個介面都能動態提取並呼叫。
Apifox上操作步驟如下：
1） 在要提取引數的介面的後置步驟裡，使用json path表示式提取目標響應欄位並命名，設定變數型別
2）該欄位會儲存到專案設定中，同一環境，同一專案裡的其他介面具有呼叫許可權。
執行一下上圖中的介面，可以看到該欄位已經被提取到變數設定中了。
3）在需要呼叫該變數作為引數的介面請求引數裡，以引數形式填入到對應空格中
看一下結果：
傳送該post請求，在介面>執行>實際請求tab>請求URL中可以看到，該引數已被成功呼叫
測試資料引數化
使用變數
某些測試資料（如登陸賬號密碼，使用者資訊等）會在不同的介面被反覆呼叫，這個時候可以將該測試資料引數化，與介面響應引數不同的是，響應引數是獲取自上一個介面的，而測試引數是我們直接寫進變數設定裡的。在Apifox裡的操作步驟如下：
1)在全域性變數中設定好測試資料變數名和值
2) 直接在介面請求引數中呼叫該測試資料- 使用測試資料集
當我們需要上傳不同的測試資料以校驗響應返回資料是否存在異常時，一個介面引數需要多個測試資料。這個我們放到後面測試管理的部分談。
測試斷言
既然是自動化測試，我們無法一一人工去校驗返回的response是否符合我們的要求，因此需要用指令碼/功能設定替人力完成這些工作。
我們主要校驗：
*1）介面請求是否成功，即返回的code是否符合預期
2）返回的介面資料裡的關鍵欄位、關鍵值是否符合預期*
在Apifox上，可以直接通過介面操作設定基本的斷言操作：
1) 在介面管理-後置操作 裡選擇斷言
2) 請求發出之後，如果返回值符合預期，則在返回處會提示斷言成功，失敗則給予錯誤提示。
如果需要靈活設定斷言，可以使用apifox裡的後置操作中的自定義指令碼功能，它也提供了程式碼模板功能，測試人員只需修改期待值即可。
對於單個介面，自動化的預備工作即將輸入資料和介面間的引數傳遞都引數化、不要寫死,方面後期資料修改和維護，以及使用測試斷言來代替人工檢查介面測試結果。
完成了這部分工作之後，我們接下來就可以把不同的介面組織到一條介面自動化用例裡，完成一個業務場景的測試。
接下來的工作我們在Apifox的測試管理tab完成。
測試管理
匯入測試用例
介面用例需要在測試單個介面的時候生成，這是在匯入測試用例之前需要完成的準備工作。在單個介面測試的時候選擇儲存為用例即可生成測試用例。
在測試管理tab，新建測試用例>匯入介面用例>選擇該測試場景所需用例>預設選擇繫結>確定匯入
匯入完畢後的用例如下，一個介面請求就是一個操作步驟，若干個步驟共同完成一個場景的測試。
介面執行順序
在上述用例中，介面請求的步驟是從上而下的，如果想要調整介面的執行順序，直接拖動介面到目標位置即可。
如果需要增加其他介面請求，則選擇新增步驟。
使用測試資料集
上文測試資料引數化那一節有提到過一個介面需要多條測試資料的事情，拿到這裡講主要是功能模組剛好在這邊，方便些。
在測試管理>用例的右側，可以看到測試資料這個功能
點選管理資料，可以進入測試資料tab管理新增外部測試資料。
接著在測試步驟>設定 頁面，將測試資料修改為測試資料集的變數名稱
點選下方的執行按鈕時，會彈出介面讓測試人員選擇要用的測試資料集，每個測試資料集都會當成一條測試用例來執行。
對應的會生成多個測試結果：
除了能夠直接填外，也可以匯入外部的CSV檔案，更加適合大資料量的測試場景。
測試引數配置
在用例的右側，有執行環境和儲存變數變化值等配置，可以根據專案的實際需要選用。
其中[間隔停頓]和[使用全域性cookie]在介面測試中應用頻率較高。
執行結果&測試報告
點選[執行]按鈕，執行成功會跳轉到執行結果頁面。還可以匯出測試報告。
測試套件
同一個模組的介面用例可以合併為一個測試套件來執行，在測試套件頁面，把單個介面用例直接新增進來，其他操作步驟和上文一致。
點選執行可以依次執行新增的用例。
總結
整體講解下來，感覺Apifox做介面自動化的優勢在於流程高度整合、低程式碼 、貼合國內測試團隊的工作模式和思維模式。
因此我們從單個介面測試，到業務流程的介面測試，到整個測試套件組裝，以及將它們自動化，一路下來，下一步的工作都是可以複用上一步的工作成果的，幾乎沒有被浪費的工作量。
另一個點是，我們用Apifox實現了自動化，但過程中幾乎沒有需要用到程式碼的地方，很多地方都被它直接做成了視覺化介面，我們選擇控制元件填資料就行了，這對程式碼基礎薄弱的測試人員確實是一大福音。
本次的《Apifox的介面自動化測試攻略》就講解到大家了，希望能對大家有幫助。