接口測試爲什麼重要？
我相信你一定聽說過這樣一句話：“測試要儘早介入，測試進行得越早，軟件開發的成本就越低，就越能更好地保證軟件質量。”
但是如何儘早地進入測試，作爲軟件測試的你，是不是也沒辦法說得清楚呢？其實上面那句話中的“測試”，所指的並不是測試這個人，而是指包含了單元測試、接口測試、界面測試等一系列質量保障活動的測試工作。
說到單元測試、接口測試和界面測試，你是不是馬上就想到了“測試金字塔模型”呢？
在這個金字塔模型中，界面測試、接口測試和單元測試，每一個階段所佔面積的大小，代表了它們在測試過程中的投入和工作量佔比。
你可以看到，單元測試在測試過程中，佔據了絕大部分的比重，這表示單元測試需要你投入更多的時間和人力成本。但是，單元測試並非測試的本職工作，它屬於開發工程師的工作範籌。說到這你可能會問了：“如果開發工程師從來不寫單元測試怎麼辦？”畢竟大部分開發人員都不愛寫測試。
其實，我也會問自己這個問題。不可否認，開發工程師不只很少寫單元測試，更很少寫出好的單元測試代碼，很多時候，工期的壓力讓他們放棄了單元測試。但是，一個產品的交付質量更多時候卻是由測試來保障的，面對這一實際現狀，我們又該怎麼辦好呢？
提供兩種解決手段：一種是用一些智能化框架補充單元測試工作；另外一種，就是加大我們自己主導的接口測試的工作投入比重，來彌補單元測試的不足，這樣，上面那個金字塔模型就會逐漸演變成菱形模型。
那之所以出現從“金字塔模型”到“棱形模型”這種變化，並不是有人刻意提高測試在整個交付流程中的地位，這其實是隨着工作的不斷進行，逐漸形成的結果。
在質量保障過程中，我們的測試會不斷增大接口測試的測試深度和測試廣度，往下逐漸覆蓋一些公共接口的單元測試內容，往上則逐漸覆蓋應該由UI層保障的業務邏輯測試，這麼做的主要目的，就是爲了更好地完成質量保障工作，交付一個可靠的、高質量的項目。
所以，從接口測試這一環節開始，測試就變成了質量保障工作的主要推動者，接口測試也變得愈發重要。那它有什麼好處和優越性呢？我覺得可以從下面這3個角度來看：
-
接口測試更容易和其他自動化系統相結合； -
相對於界面測試，接口測試可以更早開始，也可以測試一些界面測試無法測試的範圍，因此它使“測試更早的投入”這句話變成現實； -
接口測試還可以保障系統的魯棒性，使得被測系統更健壯。
現在，我相信你已經意識到接口測試在質量保障中的重要地位了，那麼，你知道究竟什麼是接口嗎？接口測試又在測些什麼呢？我們又爲什麼要做接口測試呢？
下面我就逐一把這些講解給你。
接口是什麼？
如果你想要知道接口測試在測什麼，首先就要知道接口是什麼。
在這裏我不想告訴你書本上是怎麼定義接口的，從那些晦澀的語言中，你可能讀幾次都不能真正理解它的含義，我準備用一個實際生活中的例子，來告訴你接口究竟是什麼。
我相信你肯定去過麥當勞，那每次在你去麥當勞喫東西時，你是否細心觀察過它爲你準備訂單商品的過程呢？
如果你的訂單上有一個漢堡，工作人員會先找到漢堡的原材料如麪包片、肉餅和生菜等，按照規定步驟，將這些原材料組合成一個漢堡，然後送給你；如果你的訂單上有一份薯條，那麼工作人員會進入另外一個工作流程，先找到薯條原材料和炸薯條的鍋，把薯條炸好後，送到你面前。
那麼在上面的例子中，漢堡以及薯條的原材料就是接口中必要的條件入參，也就是接口的特定輸入；製作漢堡或烹飪薯條的過程，就是接口內部的處理邏輯；送到你面前的漢堡和薯條，就是接口的處理結果和特定輸出，也就是返回參數。
所以我們可以看到，接口就是有特定輸入和特定輸出的一套邏輯處理單元，而它不用知道自身的內部實現邏輯，這也可以叫做接口的黑盒處理邏輯。
而從上面的例子你也可以看到，由於服務對象不同，接口又可以分爲兩種，一種是系統或服務的內部接口，一種是外部依賴接口。
-
內部接口
簡單來說，內部接口就是系統內部調用的接口。
在上面麥當勞的例子中，內部接口有兩個：
-
漢堡訂單。服務員在接到訂單後，輸入漢堡的原材料，將漢堡做好後，放到後廚和前臺之間的一箇中間儲存櫃裏，作爲輸出，爲下一個中間儲物櫃接口提供輸入參數。 -
中間儲物櫃。服務員從中間儲物櫃拿出漢堡，這就是這個內部接口的特定輸入，最後送到你面前的漢堡，就是這個內部接口的特定輸出。
那麼在軟件系統中，內部接口是怎麼一回事呢？
其實，你在網上購物時，要先登錄系統，然後將商品加入購物車，再接下來支付訂單。那麼，從添加商品到購物車，再到支付訂單，這一長串的流程之間，就是通過系統內部接口來完成的。
-
外部接口
剛剛說了內部接口，那什麼是外部接口呢？其實它是相對於內部接口而存在的一個概念，上面你在麥當勞點餐的場景就是一個外部接口，它又可以分爲兩部分：
-
出訂單前，你的點餐過程。這個外部接口特定的輸入是你在點餐時，告訴服務員你想點什麼，這也是你輸出給麥當勞的參數。 -
出訂單後，服務員送餐的過程。它的特定的輸出是服務員把漢堡送給你，這也是麥當勞返回給你的處理結果參數。
在系統上，外部接口又是怎麼回事呢？
你在購物後點擊付款時，頁面會跳轉到支付系統，等你完成支付流程後，再跳轉回訂單頁，在這樣的流程中，都會涉及系統對外的接口，還有，比如說付款工程的支付接口、配送過程的物流接口等等。
現在我來總結一下接口的本質，它其實就是一種契約，遵循這樣一種形式：在開發前期，我們約定接口會接收什麼數據；在處理完成後，它又會返回什麼數據。
如果調用方和被調用方都遵從了這種契約，那麼就可以達到共同開發的目的，開發完成後，聯調完成系統邏輯的前期預期，提高研發效能。
什麼是接口測試？
還是以麥當勞的漢堡爲例，接口測試，其實就是要驗證製作漢堡的過程是否正確。 這裏所說的“正確”其實有兩方面的意思：
-
一方面，是要驗證輸入了漢堡的原材料，經過製作漢堡的處理流程，最後交付給你的是一個漢堡； -
另外一方面，是要驗證在輸入的漢堡原材料不對或者不全的情況下，經過製作漢堡的處理流程後，不能給你交付一個漢堡。
你一定要注意， 這兩方面的驗證是都要進行的，對於一個測試來說，這兩種流程都是正向流程。只有理解了這個思維，你才能把自己從客戶思維里拉出來，形成測試思維。
我相信你在工作中，已經接觸過各式各樣的接口了，比如說HTTP協議的接口、RESTful格式的接口、WebService的接口、RPC協議的接口等。其實無論是哪一種形式的接口，它們都是通過某一種傳輸協議，在Client端和Server端之間來完成數據傳遞的。
-
假如你現在測試的，是Web端的極客時間，那麼Client端就是瀏覽器，Server端就是Web服務，那麼瀏覽器和Web服務之間，就是通過HTTP協議傳輸的； -
如果你測試的，是移動端的極客時間，那麼Client端就是你的設備上安裝的極客時間應用，Server端就是RESTful格式的接口服務，那麼極客時間的應用和RESTful格式的接口服務，就是通過JSON格式的數據來傳遞的。
看到這，我想你也能理解了，接口測試其實就是模擬調用方，比如Client端，通過接口通信來檢測被測接口的正確性和容錯性。
但是請你放心，我現在所說的模擬調用方，並不是讓你開發一個瀏覽器或者極客時間的手機應用，而是讓你模擬這些客戶端上的前端邏輯，調用Server端提供的接口，你完全可以藉助一些工具或代碼來完成這項工作。
這些相關的工具或代碼技巧，也就是我設計這個專欄的主要思路。但我不想把這些工具一次都羅列給你，讓你馬上就失去興趣，這是由於兩個原因：
-
當你看到一個好幾頁的工具列表或者技術列表式時，你可能會覺得，自己需要翻越無數個高峯才能學會接口測試； -
另一方面我也覺得，在接口測試中，工具或代碼並不是它的核心內容，接口測試思維纔是你應該重點關注的問題。
所以，我會在做一些工作或者任務的過程中，把這些工具介紹給你，讓你知道哪些工具能夠解決哪些問題，用什麼樣的代碼可以解決什麼樣的問題。我也更希望你知道，工具和代碼並不是相互排斥的，而是相互依存和相互輔助的。
其實，接口測試和你以前最熟悉的業務測試一樣，都是關注輸入和預期是否一致，尤其是輸入數據中有一些非法輸入的時候，接口的處理和邏輯控制是否合理，這些都是通過返回值來判定的。
還有一些小概率邏輯的處理也是我們設計輸入的關注重點，比如一些代碼中的異常情況，我們也要想辦法，通過輸入參數來觸發這種邏輯分支，通過返回值來判定對應接口內部實現的處理邏輯是否合理、是否健壯。
這樣看來，接口測試對於你來說，也不是一個全新的工作內容，但它還有自身的特別之處的，比如說：
-
在測試手段上，接口測試算是技術驅動和業務驅動雙管齊下的工作（界面測試卻是業務驅動爲主的工作），因此，你需要藉助一定的工具來完成它。這個工具既有可能是成熟的工具，也有可能是你自己寫的代碼，因此，測試技術會在接口測試階段，變得和業務知識一樣重要。 -
在工作範圍上，接口測試影響的範圍會更廣一點，它會覆蓋一部分單元測試的內容，也會覆蓋一部分業務測試的內容，但是，無論是哪一部分的內容被它侵佔，相對應部分的工作投入其實都減少了。
總結
-
接口測試是通過設計輸入和預期輸出來完成測試驗證的，之前掌握的測試用例設計方法等測試基本功，在這裏還是有用武之地的； -
接口測試是一個技術知識和業務知識相結合的工作，可以更好地提升自己的技術實力；
雖然本文講得是接口測試方面，最後我還想強調一點，研發質量千萬不要指望測試同學把關，代碼質量是研發的尊嚴，做好全面的測試設計，寫好每一份測試用例，對你會是質的飛躍！