【分享】API功能測試怎樣作才能快捷高效！

# 前言
API，就是軟件系統不一樣組成部分銜接的約定。因爲近年來軟件的規模日益龐大，經常須要把複雜的系統劃分紅小的組成部分，編程接口的設計十分重要。
程序設計的實踐中，編程接口的設計首先要使軟件系統的職責獲得合理劃分。良好的接口設計能夠下降系統各部分的相互依賴，提升組成單元的內聚性，下降組成單元間的耦合程度，從而提升系統的維護性和擴展性。
換句話說，API也能夠看作程序/資源/組件的集成點。它的功能會跟UI有些相似，經過某些特定指令、參數等可讓後臺的一堆代碼運行起來，最後獲得想要的結果。不一樣的是它不提供可視的按鈕文本框之類的界面，而一般是由一個直接和底層代碼打交道的連接構成。

# API功能測試的概念
API測試是針對系統所提供的API作各方面的驗證。API的性能和安全測試根據測試策略的不一樣，會是一個可選測試項。這個能夠做爲兩個單獨的問題來討論。
API的功能測試相似於UI功能測試，都是在已知輸入內容和指望結果的前提下，使用這個功能/調用這個API而且驗證是否能返回指望的結果。不一樣的是API測試在返回結果被呈現給客戶前就完成了，從而對測試環境的依賴會比較小。

# 構建API測試的價值
測試覆蓋率。UT關注點是各個單元是否可以完成指望工做，只覆蓋一個單元內部工做狀況；集成/API測試關注點是各個模塊/單元之間協同工做，它所覆蓋的場景也會比單元測試更多。而UI測試會更加關注e2e，模擬用戶行爲，在全部的程序依賴環境準備完成後再進行操做。相比之下API測試不依賴環境，測試成本會比UI測試更低，並且覆蓋率比UT更高。
快速反饋。API測試速度比UI測試更快(由於無需界面加載/響應)，短期內能跑不少用例。API測試也能精確的揭露是軟件中哪一個組件除了問題，若是把你的API測試放到CI裏面，一旦代碼修改破壞了現有的功能，就可以快速反饋到團隊中。還能夠把測試中發現的BUG也寫到API測試裏面，讓測試成爲一堵牆，從而能更好的能保證產品質量。
可複用。API測試因爲不須要瀏覽器、GUI等環境，因此能夠更加靈活的在各個環境中複用。例如你能夠在產品環境中、測試環境、研發環境中使用，你須要作的只是修改下測試數據而已。另外若是是在TDD模式下工做的話，API測試可能會在產品完成前就寫完了，後續的工做也會減小不少。

# 爲何要作API功能測試——測試金字塔
還記得曾經在課堂上學過的測試金字塔嗎？
簡單來說就是說越往上層走的測試，須要投入的成本會越高，並且會越難以維護。在這個結構下，由於UT已經覆蓋了絕大部分的代碼，因此其上層的集成/API測試和UI測試能夠去除重複測試的部分，從而量也會愈來愈少，而且會有不錯的覆蓋率。
因此理想中的自動化測試結構應該是：大量的UT+適量的集成測試(或者API測試)+少許的UI測試。

# 工具
市面上常見的API測試工具我知道的能夠分紅幾大類：
開源純代碼類，好比基於nodeJS的supertest；基於Java的rest-assured等。這類工具易於學習，易於和CI集成，可是須要使用者有必定的編碼能力。
半商用工具，好比Eolinker，功能強大操做簡單，有高級功能收費版，免費版也足夠我的及中小團隊使用。
各種插件工具，好比Chrome插件Postman，也有收費版能夠用。
工具的選擇見仁見智，根據不一樣的環境選擇不一樣的工具。我進了如今的公司後用的是Eolinker

怎麼作API功能測試？
API功能測試的主要手段是使用工具/軟件調用待測API，而後驗證是否返回指望的output。這個output一般多是:
a.返回成功或者失敗的status
b. 是一段數據或者information
c. 或者是跳轉到其餘API

# 設計測試框架
接着是設計你的測試框架，最好是要知足可複用性強，高內聚低內聚什麼的原則，記得要有輸出測試報告的模塊。
a.用例
上面你已經想好了須要測哪些功能點，針對這些點咱們用腦圖之類的工具把須要測試的場景記錄下來。
b.腳本
接着是腳本設計和測試數據設計。腳本和數據最好能夠分開，這樣的話能夠複用測試腳本，用不一樣的測試數據輸入去獲取不一樣的指望結果。
c.驗證
驗證的過程大體包含下面這些：
檢查API是否是根據你輸入的數據返回指望的結果；驗證API是否是不返回結果或者返回異常結果；驗證API是否是正確觸發其餘even；收否正確調了其餘API；或驗證API是否是正確更新了數據等等。
完了就是輸出測試報告了，好的測試報告能夠幫助你輕鬆定位到出錯的地方，使修復流程更加順暢。
最後，強烈推薦把測試集成到CI中去，加速異常反饋，建立強有力的質量體系。

# 思惟
在正式開始測試以前，你得先搞清楚幾個問題：
a.待測API的目的是什麼？誰是使用者？
b.待測API會在什麼環境下使用？
c.待測API在異常環境下會不會有非指望響應？
d.這個測試須要測什麼功能點？
e.各個功能點的測試優先級？
f.如何定義指望返回的結果是成功仍是失敗？
g.待測API會不會和其餘系統有交互(修改代碼後影響其餘系統)？
雖然問題會影響到你的測試結果是否符合客戶需求，或者說這些潛在的風險會影響到這個項目是否成功。若是你選的是必須得本身寫點兒代碼的工具，那麼接下來得根據選擇的工具和項目代碼，去setup測試環境，讓工具可以成功跑起來。