開發修改了介面，測試應如何高效維護、更新介面用例

2022 年 4 月 12 日
筆記

不知道大家有沒有同感，做介面測試麻煩的不是測試本身，而是介面它會變,更麻煩的不是介面變了，而是它變了而你不知道。等到你測完，開發才悠悠跟你說——「那個介面我改了點東西，你再看一眼哈」。

我那是看一眼的工作量嗎？我得review一遍看影響到哪些介面，再根據影響到的介面，查看並修改對應的介面用例，調用鏈下游的用例，該改的改，改完再跑一次介面測試。

——這意味著已經做完的工作又要來推翻重來一遍，我本來已經幹完活兒悠哉摸魚了，現在得加班了，我那40米大刀已經舉起來你看到了沒？

吐槽歸吐槽，但人真的不是精密的機器沒法保證一直不出錯。即便我們組內「服務好下游，承接好上游，不拖後腿，不坑隊友」已經是共識了，在彼此工作量巨大的前提下，真的很難不會有溝通不及時、不到位的情況。何況即便即時通知了，變更仍舊會給測試帶來不少的返工工作量。

有沒有一種可能介面被改了測試能及時同步到數據，不用自己去扒拉新的介面文檔？
有沒有一種可能介面改了用例也能順便幫我一起改了，再順便告知我有哪些地方需要調整的我再精準調整？

大佬有了idea會自己造輪子，而我，我會找現成的輪子。比對了幾款中國外的介面測試和管理工具，目前最符合這個需求的是一款叫Apifox的國產介面調試、測試、文檔管理工具。

Apifox解決方案

捋一下當一個介面被改了，它被改動的地方可能有：

介面的入參和出參沒有變化，只是介面內部的實現邏輯變化了
介面的入參被修改了，這個請求參數可能是必填的也可能是非必填的
介面的返迴響應被改了

那麼對應的，測試需要捋清楚自己哪些地方需要返工：

1.修改了內部邏輯的介面，用例不需要改動，只需要重新執行一遍測試
2.介面的出參入參變化導致改介面的服務受影響，相關用例也需同步調整
3.各個介面間存在參數傳遞和調用關係，也可能受影響，用例需要排查調整

簡單來說就是捋清楚哪些介面收到影響了，再去修改對應的用例。這些工作原本需要我們手動排查的，其實可以直接利用Apifox去實現。

Apifox對此給出的解決方案是：

1.當開發那改動了介面之後，測試這邊一鍵同步，能直接同步到最新的介面文檔
2.設置介面用例與介面綁定，當介面的請求參數和響應參數發生變化，介面用例也會同步更新到最新的介面數據，不需要人工修改介面用例
3.一鍵回放介面用例，對比返回的結果，如果報錯或者返回的數據結構不對應，則告警；
4.介面設計時可以對返迴響應進行約束，用例設計時也可以對介面返回進行斷言，當介面響應發生變化，執行自動化介面測試會針對錯誤的地方給出提示。

以上都依託於Apifox的自動化測試功能，用Apifox怎麼做自動化測試，大家可以去官網搜一下相關教程，我重點會放在「介面變更」要怎麼處理這部分。

用Apifox怎麼處理介面變更

用Apifox處理介面變更主要依賴於它的兩大功能：
1.介面變更數據同步與介面用例自動更新

介面用例是在介面的基礎上，修改請求/響應欄位的值保存生成的。無論是介面的域名，路徑，方法，請求參數，響應參數被修改，介面用例也能夠一鍵步到最新的數據。 2.自動斷言功能 Apifox的自動斷言功能不需要寫腳本，對Python或js不熟悉也可以直接通過可視化介面填寫參數。在生成的介面用例中，選擇後置操作tab/斷言；填寫你要斷言的對象，提取響應里的目標參數，並設置判斷規則，校驗實際返回與期望返回是否與預期一致。提取參數時通過json path表達式提取的，具體規則可以看下這個使用文檔：//www.apifox.cn/help/reference/json-path/