介面自動化的工具現在有很多個選擇，本篇文章著重介紹YAPI的使用方法；

1、它首先是一個很好的介面維護的工具；

開發同學的介面文件可以在此工具上維護；

現在很多的文件的維護都是多人協同維護了，例如jira、石墨等。相對於postman更傾向於本地化，YAPI更能提現協同合作的優勢。

開發同學可以根據各自的分工來分別維護自己所負責模組的介面；

而組長有分配的許可權來給各個成員分配各個模組的檢視和編輯的許可權

在介面的編輯頁面可以整理自己介面的資訊，請求的引數以及返回的結構和資訊，各種備註等等；

開發的同學在維護完成介面後，測試同學就可以運用介面來進行介面的測試以及測試集合自動化測試的case編寫了。

2、單個介面測試時，更方便靈活，更易用；

瞭解呼叫介面各引數的含義，以及結合自己測試的業務的場景，呼叫介面就可以拿到自己的測試資料，這裡不做重要闡述。

在GET的後面可以配置你要測試的環境域名，測試環境或者生產環境的；

3、介面自動化測試，可以0程式碼基礎進行介面集合的測試；

上圖中，填寫好請求的引數之後點擊發送就可以呼叫介面了，在頁面的下面就可以檢視打印出返回的資料；點選儲存的話，這個case就被儲存在測試集合中了，一個測試集合中可以多次呼叫相同的介面，這個測試集合可以滿足你各種不同引數的case以及場景，並且可以跨模組來呼叫不同模組的介面滿足一個場景中呼叫多個介面；

這裡可以切換各種環境，點選開始測試就是自動執行集合中所有的case即介面。

執行集合用例時，會生成測試報告，這裡需要對集合中的每個case進行斷言的編寫，去驗證自己的測試點是否通過；

例如上面兩個case，首先可以驗證呼叫介面在服務端返回的狀態碼是否正確

上圖展示了用node語言去初步的斷言該介面返回的狀態為200；

然後斷言介面返回的資料狀態碼是正確的：100；

如果狀態碼不正確的話，那麼執行此集合的時候就會報錯，如下圖，會以歎號展示測試不通過，集合中的介面如果執行到與斷言結果不同的時候，那麼就直接返回錯誤了，後面的斷言也就不會繼續執行了；

case中返回的資料與斷言結果不一致：

還可以驗證介面返回的資料中從陣列，到物件，然後再到字串的驗證都是可以的，上圖中就有介面中訂單號一定不為空的斷言編寫；

根據拿到的介面可以做很多場景的自動化場景的測試：

校驗case中的例如使用者資訊是否正確，各種資料是否齊全；或者校驗返回的資料中一定沒有**，等等。

原文：https://blog.csdn.net/tiejian147/article/details/102643188