RESTFul API 測試全面介紹

什麼是 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、 OAuth二、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 測試管理與自動化技術社區