測試人員如何提高API功能測試效率？

API，即：應用程式設計介面，就是軟體系統不同組成部分銜接的約定。由於近年來軟體的規模日益龐大，常常需要把複雜的系統劃分成小的組成部分，程式設計介面的設計十分重要。

程式設計的實踐中，程式設計介面的設計首先要使軟體系統的職責得到合理劃分。良好的介面設計可以降低系統各部分的相互依賴，提高組成單元的內聚性，降低組成單元間的耦合程度，從而提高系統的維護性和擴充套件性。

API測試是針對系統所提供的API做各方面的驗證。API的效能和安全測試根據測試策略的不同，會是一個可選測試項。這個可以作為兩個單獨的問題來討論。

API的功能測試類似於UI功能測試，都是在已知輸入內容和期望結果的前提下，使用這個功能/呼叫這個API並且驗證是否能返回期望的結果。不同的是API測試在返回結果被呈現給客戶前就完成了，從而對測試環境的依賴會比較小。

還記得曾經在課堂上學過的測試金字塔嗎？

簡單來講就是說越往上層走的測試，需要投入的成本會越高，而且會越難以維護。在這個結構下，因為UT已經覆蓋了絕大部分的程式碼，所以其上層的整合/API測試和UI測試可以去除重複測試的部分，從而量也會越來越少，並且會有不錯的覆蓋率。

所以理想中的自動化測試結構應該是： 大量的UT+適量的整合測試(或者API測試)+少量的UI測試。

☞ 測試覆蓋率。UT關注點是各個單元是否能夠完成期望工作，只覆蓋一個單元內部工作情況；整合/API測試關注點是各個模組/單元之間協同工作，它所覆蓋的場景也會比單元測試更多。而UI測試會更加關注e2e，模擬使用者行為，在所有的程式依賴環境準備完成後再進行操作。相比之下API測試不依賴環境，測試成本會比UI測試更低，而且覆蓋率比UT更高。

☞ 快速反饋。API測試速度比UI測試更快(因為無需介面載入/響應)，短時間內能跑很多用例。API測試也能精確的揭露是軟體中哪個元件除了問題，如果把你的API測試放到CI裡面，一旦程式碼修改破壞了現有的功能，就能夠快速反饋到團隊中。還可以把測試中發現的BUG也寫到API測試裡面，讓測試成為一堵牆，從而能更好的能保證產品質量。

☞ 可複用。API測試由於不需要瀏覽器、GUI等環境，所以可以更加靈活的在各個環境中複用。例如你可以在產品環境中、測試環境、研發環境中使用，你需要做的只是修改下測試資料而已。另外如果是在TDD模式下工作的話，API測試可能會在產品完成前就寫完了，後續的工作也會減少很多。

API功能測試的主要手段是使用工具/軟體呼叫待測API，然後驗證是否返回期望的output。這個output通常可能是:

♡ 返回成功或者失敗的status

♡ 是一段資料或者information

♡ 或者是跳轉到其他API

工具

市面上常見的API測試工具我知道的可以分成幾大類：

開源純程式碼類，比如基於nodeJS的 supertest；基於Java的 rest-assured等。這類工具易於學習，易於和CI整合，但是需要使用者有一定的編碼能力。商用工具，比如：SoapUI，功能強大操作簡單，還提供免費社群辦可以試用。各類外掛工具，比如Chrome外掛Postman，也有收費版可以用。工具的選擇見仁見智，根據不同的環境選擇不同的工具。

測試

在正式開始測試之前，你得先搞清楚幾個問題：

待測API的目的是什麼？誰是使用者？

待測API會在什麼環境下使用？

待測API在異常環境下會不會有非期望響應？

這個測試需要測什麼功能點？

各個功能點的測試優先順序？

如何定義期望返回的結果是成功還是失敗？

待測API會不會和其他系統有互動(修改程式碼後影響其他系統)？

這些問題會影響到你的測試結果是否符合客戶需求，或者說這些潛在的風險會影響到這個專案是否成功。如果你選的是必須得自己寫點兒程式碼的工具，那麼接下來得根據選擇的工具和專案程式碼，去setup測試環境，讓工具能夠成功跑起來。

設計測試框架

接著是設計你的測試框架，最好是要滿足可複用性強，高內聚低內聚什麼的原則，記得要有輸出測試報告的模組。

用例

上面你已經想好了需要測哪些功能點，針對這些點我們用腦圖之類的工具把需要測試的場景記錄下來。

指令碼

接著是指令碼設計和測試資料設計。指令碼和資料最好可以分開，這樣的話可以複用測試指令碼，用不同的測試資料輸入去獲取不同的期望結果。

驗證

驗證的過程大致包含下面這些：

檢查API是不是根據你輸入的資料返回期望的結果；驗證API是不是不返回結果或者返回異常結果；驗證API是不是正確觸發其他even；收否正確調了其他API；或驗證API是不是正確更新了資料等等。

最後，強烈推薦把測試整合到CI中去，加速異常反饋，建立強有力的質量體系。