為什麼現在這麼流行介面測試了？

做功能測試的都有體會，無聊，天天重複點點點，用例就那些花樣，感覺自己就是試用的人，只是會設計一些常人不會去操作的“用例”，但往往很多的用例還不能實現，或者無法執行。

但是這些用例是真的不能實現麼？答案是NO!事實上，所謂的不能實現、無法執行，都只是技術不到位罷了。具體能不能做到，並不是一二三點簡單的說說。手工測試這個層次的不能，只不過是表面的介面無法操作而已；換個維度，在介面測試角度很多時候是可以做到的，而且可以達到對目標進行破壞式的行為，甚至達到安全測試的要求。只有想不到，沒有做不到。

雖然現在關注介面測試的人越來越多，但是真正深入瞭解的反而不多。有的是完全不懂，完全不懂是因為沒有接觸過，不知道情況。有的是懂一點卻總覺得很簡單，這些人會覺得，會一些流行的工具、簡單的程式碼就可以了，這種情況其實跟功能測試階段只會用滑鼠鍵盤一樣，是在幫開發除錯介面是否正常，並不算在測試。真正的介面測試，需要對業務資料、系統邏輯、資料傳輸等方面確保萬無一失，如異常資料、異常流程、越過客戶端的驗證規範等等，能發現問題才是王道。至於介面的自動化，是穩定後的一種便捷的迴歸測試模式。

介面測試的第一步就是要了解資料的流向、實現方式，這對只會功能測試點點點的人來說是最麻煩的，越級最大的。因為習慣從介面和業務去考慮問題了，忽略了系統實現層面的真實資料傳輸，現在的系統都是網際網路型別的，使用者在自己電腦操作必然會把資料傳輸到伺服器，這中間就會產生大量的介面呼叫操作，那麼測試也需要保證資料的正確性，可靠性，安全性，這就是介面測試，最流行、最廣泛的傳輸協議那就屬HTTP了。

那麼HTTP是怎麼樣的呢？

HTTP協議包含2大塊，請求（Request）、響應（Response），簡單說就是一發一收，甚至可以認為就是輸入和輸出的概念，請求中會包含連結、頭資訊、主體資料，響應會包含狀態碼、頭資訊、主體資料。這其中還包含了非常多的細節組成，這裡就不詳細講述了，以後有機會給大家介紹。

介面測試應該怎麼做？

如果對軟體測試、介面測試、自動化測試、效能測試、LR指令碼開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。

有人可能去問過一些做過的人，介面測試怎麼學起、怎麼做，基本得到的答案都會是，找個工具、參考下網上的程式碼，寫個請求就好了，檢查響應中的資料是不是你的預期，測試就完成了，具體引數參考你們的介面設計文件即可。

作為小白又懵逼了，工具不會用，那麼多框填什麼不知道，程式碼折騰了半天最終以看不懂的報錯結束了，再退一步，看了學習視訊，工具操作會了，基本的程式碼也會了，但是，拿到了介面文件測什麼呢？要是沒有介面文件又怎麼辦？

對於介面測試的學習大多數人其實面臨下面的這些問題：

1 沒有學習資源和物件，無頭蒼蠅

2 學是學了，只是跟著操作，專案不知道如何下手

3 只聽介面其聲，不知其理，會點程式碼但無從下手

4 完全不會程式碼，感覺很難退縮了

而且很多時候是上面所有問題一起發生，這就更難下手了，得想辦法逐個擊破才是。比如，工具是個好東西，能快速入手去專研介面測試；程式碼也是個好東西，能大量漲薪；但更紮根的底子如果不好，往往一起學習就會難上加難，最終一事無成。