什麼是 API
API 是應用程序編程接口（Application Programming Interface）的簡稱。從技術上講，API 是 應用系統、操作系統、開發庫等對一系列過程、函數的封裝，開發人員可以使用 API 編程對其它的 應用系統、操作系統、開發庫提供的功能進行調用。
如果以上對 API 的解釋比較難以理解的話，我們舉一個例子說明。假如你到了一個來到一個餐館，不巧的時服務員這個時候不在。你可以到餐桌上拿到菜單，然後直接像廚師點菜，廚師就會按照你的要求去做。但是有時也會存在你點的菜沒有原材料了。你就需要再次拿起菜單，再點一個其它菜。當有很多顧客都同時向廚師直接點菜時，廚師就要分出很大的精力去處理客戶的訂單，而不能專心做菜了。
另外我們這個世界有幾百種語言。如果廚師不能聽懂客戶的語言該怎麼辦？這是最好有一個專門能聽懂客戶點菜的服務員。服務員就是廚師的 API，他（她）接收顧客的請求，然後傳遞給廚師，最後把顧客點的菜從廚師那裏返回給顧客。服務員可以聽懂顧客和廚師雙方的語言。如果顧客點的菜後廚已經售罄，然後請顧客再選一個其它菜。這樣可以節省顧客直接詢問廚師的往返時間，顧客的體驗也好多了。以上服務員服務顧客的這個過程也就是 API 的作用。
如上面的圖所描述的那樣，顧客向服務員提出訂單，服務員的作用就時 API ，他（她）接收到訂單轉發給廚師，廚師這是就是後臺的服務程序。服務程序處理完請求後把結果返回給顧客。像上面例子，廚師就是服務器應用，他從服務員（API）那裏獲得服務請求，處理請求（烹煮食物），然後把處理完成的結果（美味菜餚）返回給 API (服務員)。至於 調用 API 需要傳入的不同參數，可以認爲是顧客對菜餚不同口味的要求，例如多放辣椒、放自然、放咖喱、多加鹽等。這些參數可以讓服務器應用（廚師）採用不同的處理方式來處理請求。
API （應用程序接口）從客戶終端設備中獲得請求，然後把請請求發送給遠程服務器，服務器處理完成後，API 從服務器獲得處理結果，把處理結果再傳回給客戶終端。在現在的 IT 架構中，API 到處可見，被大量應用。API 根據使用要求，傳入不同的參數後，從服務器端獲得相應的處理結果。例如航班查詢中，根據對航班的出發港、到達港、起飛時間等要求，可以查詢出不同的航班、不同的票價等信息。作爲客戶端開發人員，通過 API 處理複雜且難以處理的請求，變得和容易，只要按照 API 的調用要求，正確的傳入請求參數即可。這也是 API 的好處，它讓 API 變得非常流行，隨處可見。
API 測試
我們上面介紹了 API ，也知道了 API 對當前世界中分佈式 IT 服務應用的重要性，因此 API 測試也隨之變的重要。
API 測試可以提高服務應用的代碼質量，提前發現服務應用的問題，並及時修復。相對於傳統的 GUI 測試，API 測試可以底層的角度發現 GUI 測試不容易暴露的服務端問題，具有更短的問題反饋時間，更高效的解決問題的方式。
API 測試既可以使用手工測試，也可以使用自動化測試。在敏捷和 DevOps 更加流行的當下，持續測試已經成了被廣泛認可的方法。由於 GUI 的自動化存在不少的缺點，例如測試腳本經常由於 GUI 變動而導致失敗、測試執行效率低耗時長、測試人員等待時間長測試時節靠後需要開發提供 GUI 才能測試等。
在敏捷時代，測試應該前移，應該儘可能早地開始，應該進行更低層級的測試，例如 API 層、單元層。API 測試可以有開發人員執行，可以在 GUI 尚未開發的情況下進行。特別是在基於契約測試的情況下，API 甚至可以在服務端開發沒有完成的情況下進行。
軟件應用中的 API 在被正式部署前應該很好的測試，API 測試既是開發人員的工作，也是測試人員的工作。高質量的 API 對於應用程序很重要，它可以消除掉應用服務在被正式部署後可能出現的很多問題。基於此業界範圍內也開發出了很多 API 測試工具、框架等。Postman 就是其中比較著名的一個。
測試人員在 API 測試中的角色和職責
作爲 API 測試人員，應該對 API 有全面的知識體系，例如 Web 服務、REST、SOAP、微服務等。
API 測試需要的技能棧：
-
能夠使用 WEB 調用方法 GET、POST、PUT、DELETE等
-
能夠驗證請求響應 （RESPONSE）、錯誤代碼（ERROR CODE）等
-
JSON 格式、XML 格式的內容
-
能夠使用鑑權方法，例如 OAuth、 OAuth2、BASIC Authorization等
-
能夠做 WEB SERVICE 的性能、安全測試
-
能夠讀懂 API 說明文檔
-
能夠編寫 API 測試案例和場景測試案例
-
能夠編寫 SQL 驗證與 API 相關的數據庫數據
-
能夠熟練掌握 API 測試工具
SOAP UI、Postman、JMeter、RestAssured、Rest Sharp、Node modules等
API 測試與單元測試
很多測試人員把 API 測試和單元測試混在了一起，事實上它們是不同的，負責的範圍也不一樣。單元測試是基於類的測試或根類同一級別組件的測試。單元測試常常由開發人員負責，驗證類或模塊是否完成了它的設計功能。開發人員自測負責的類，發現缺陷後自行修改，直至達到設計要求。單元測試保證了麼一個類或者模塊的正確性，它們是軟件質量的基石。
相對於單元測試白盒測試，API 測試應該算是黑盒測試，測試功能連接服務程序對外提供的接口進行測試，而不會對外暴露內部的實現邏輯。API 測試需要對應的服務運行，通過 API 接口與服務器應用交互。
API 測試主要是測試系統架構中的業務邏輯，由集成測試團隊負責。測試人員通過調用指定版本的服務程序提供的接口進行測試。這樣單元測試主要由開發人員負責，在負責角色上有所區別。
API 測試也對單元進行測試，與單元測試所不同的是，單元測試是把被測單元與系統其它部分隔離出來進行測試，API 測試是把被測單元作爲系統相系聯繫的一部分進行測試。API 測試其實也是端到端的測試。當我們進行 API 測試時，跟 API 相關的模塊都會測試到。然而進行單元測試時，僅僅對被測模塊或類進行測試，被測試的模塊或類是與系統的其他部分隔離開的。
API 測試關注那些點
當我們用API工具進行測試時，往往會遇到很多報錯。這些報錯不僅有API報錯，也有軟件應用報錯，甚至是服務器錯誤。這使得軟件測試人員關注的範圍更廣，相關的知識和技能也更重要。軟件測試跟軟件開發一樣遵循一定的順序和步驟。在軟件開發階段，測試人員可以編寫測試案例和測試腳本。開發人員也可以使用測試人員編寫的腳本來發現處於開發狀態的軟件應用的問題。在生產階段，測試人員可以改善和升級測試案例，讓測試案例兼容性更好，對軟件的測試質量更有幫助。
《Postman API 自動化測試與持續集成全棧攻略》 作者：杜鐵繩
吐司QA 測試管理與自動化技術社區
