1、接口測試原理
接口測試，實際上是針對於接口做測試的。
那么接口是什么？
軟件開發，既要做前端，也要做后端，並且后端是整個業務的核心，用於處理業務請求，實現具體的功能；而前端只是提供一個頁面給用戶看結果以及提供頁面給用戶做輸入。所以整個業務的處理邏輯都在后端。而后端邏輯相對很復雜，所以在開發的時候，會由架構師確定接口，然后再針對這個接口實現其具體的功能。
接口也可以認為是我們要做多少事情，因為在技術層面，如果要實現登錄、注冊、增、刪、改、查等操作，就會先設計好一個模塊，說明具體實現哪些功能點，這個功能點應該有哪些輸入項，有哪些方法。
這個東西就是我們所謂的接口，在java里，接口里包含屬性名和方法，所有的方法都是抽象方法，只有方法名，而沒有這個方法的具體實現。也就是說：我知道這是一個登錄功能，但是登錄怎么實現，這完全是不知道的，需要開發人員具體去實現。那么作為我們的開發人員，他就會領到一個任務去實現這個接口。比如，實現登錄接口，注冊接口等。
我們可以認為，雖然他是在實現登錄接口、注冊接口。也就相當於我們根據這個接口去實現登錄功能，注冊功能。所以這個接口實際上也就是后台一個具體的功能。
那么什么又是接口測試？
實際上我們所說的接口測試就是開發人員把這個接口實現了，他需要去驗證這個接口的實現是否正確。
但是這是一個后台的功能，這個開發也是一個后台開發，他去驗證接口的時候，他不會想讓前端人員介入，因為讓前台人員介入的話會比較麻煩。那么他就需要一個工具來模擬前端界面。（前端其實就是提供一個窗口，既能讓用戶輸入數據，並且還可以查看結果。）
2、接口測試的實現
實際上我們做接口測試，還是“輸入—處理—輸出”這樣的模式。用戶輸入一串數據，然后讓這個接口或者讓這個后台功能來處理，然后檢查輸出結果跟期望是否一致。
這個其實也就是我們所說的黑盒測試。也是我們做測試的一個常規的思路。用戶輸入一串數據，然后讓系統去處理，然后我們再去檢查結果跟期望是否一致。功能測試是這么做的，接口測試實際上還是這么做。
但是相對功能測試而言，接口測試有一個比較明顯的區別，就是輸入不再是界面的，而是一個基於HTTP的請求；輸出也不再是界面，而是基於HTTP的響應。所以需要通過請求和響應分別來輸入我們的數據以及檢查我們的結果。
3、接口測試用例
其實接口測試和的功能測試是非常相似的，功能測試怎么做，接口測試還是怎么做。
功能測試用例，最核心的三個部分就是：輸入、操作步驟和預期結果。
接口測試用例，其實主要的也就是這么三個部分。
平時所說的測試用例設計方法，也就是對輸入項進行各種不同的取值，然后再做組合。拿登錄來說，登錄功能有用戶名和密碼，那用戶名，有正確的用戶名和錯誤的用戶名兩種情況，密碼有正確的密碼和錯誤的密碼兩種情況。用戶名和密碼在一起就會產生一些組合：
（1）用戶名正確，密碼正確；
（2）用戶名正確，密碼錯誤；
（3）用戶名錯誤，密碼的正確；
（4）用戶名錯誤；密碼錯誤。
輸入時，選擇不同的數據組合會產生不同的測試場景，每一個場景都需要執行一遍。
功能測試是這么去做的，但是接口測試沒有界面，也就沒有辦法輸入，怎么辦？
接口測試里有個東西叫參數，這個參數就對應了功能測試里的輸入項。所以，接口測試用例其實也就是對輸入參數，做一個划分然后再做組合，形成接口測試用例。
每一組測試用例執行后，肯定會得到不同的結果。比如正確的用戶名和正確的密碼，結果是登錄成功；錯誤的用戶名或錯誤的密碼，結果是登錄失敗。那么只要思考，如何將參數取值和測試結果應用在工具中，這個問題就解決了。
4、接口測試工具
接口測試工具有很多，比如soapUI，postman，jmeter等。
工具其實只是工具而已。
做接口測試一定要明白的一個前提：接口測試的流程。
第一步，設計操作步驟。
操作步驟就是請求，有一些請求是是單獨的，有些請求是多個請求前后有聯系的，這種情況就需要創建關聯，。那么我們需要了解請求的格式，規范以及如何做關聯。soapUI，postman，jmeter里，都有關聯。
第二步，設計數據用例。
建議將數據用例寫到Excel文檔里，然后讓工具讀取Excel。Excel里有幾組數據用例，就執行幾次。循環執行（自動化），就可以讓每一個用例被執行一次，那么每一個測試場景也就被運行到了。
第三步：斷言。
也就是提前將預期結果寫入到工具中，讓工具自動化判斷結果是否正確。不同的工具叫法不同，soapUI和Jmeter中叫做斷言，postman中叫做tests。
第四步：執行並檢查測試結果。
執行很簡單，對測試結果進行分析的話就需要了解協議。知道發出去了什么，返回了什么，才能夠知道，到底哪個環節出了問題。
5、HTTP協議
HTTP協議非常重要。清楚了HTTP協議，再去使用工具其實就很容易，按照上面四個步驟就行。
為什么是HTTP協議而不是其他協議？因為90%的系統都是HTTP協議的。
HTTP協議包含請求和響應
請求就是用戶的輸入，響應就是結果。我們通過請求去找參數，然后輸入不同的參數值，然后組合成請求，只要這個請求是合法的，那么就可以發出去，並且能夠被服務器接收。所以，首先要能夠判斷出來什么叫做合法請求。
那么就需要去了解HTTP協議的請求的組成，請求的規范，知道哪些請求項是我們所關心的，哪些請求項是我們一定要遵循的，哪些項是我們可以刪除的。
同理，要想檢查結果是否正確，就需要去了解響應。
HTTP請求包含兩個部分
請求頭和請求體，請求頭的第一行非常的重要，包含請求方法和URL。這兩個東西是非常核心的東西。請求方法有GET方法，POST方法，需要知道他們之間的區別，當然區別最明顯的就是GET請求沒有請求體，而POST請求有請求體。URL，相當於接口的入口。請求頭里有很多項，每一項最好能知道是什么意思，並且要知道哪些項是比較核心的，其實核心的東西不多。一個是content-type，一個是cookies。
備注：網上很多資料會把請求分為三部分，請求行、請求頭和請求體。這里的請求頭的第一行其實就是請求行了，下面的響應也是一樣
請求體包括參數，一般我們在測試的時候會修改請求體里的東西。
懂了上面這些，就知道該如何組裝HTTP請求了。
響應包含兩個部分
一個是響應頭，一個是響應體。響應頭里的第一行有響應的狀態碼和狀態信息，這個非常重要。面試時候一般會被問到：狀態碼有幾類？一般是有五類，1開頭（請求正在處理），2開頭（請求處理成功），3開頭（重定向），4開頭（客戶端錯誤），5開頭（服務器錯誤），這五類分別代表什么需要記住。一般5開頭的都是系統bug。
6、JMeter
其實哪個工具都可以，但是jmeter有兩個好處，第一個：它是中文版的，學習成本較低，postman和soapUI都是英文版的；第二個，jmeter既可以做接口測試，又可以做性能測試。
對應上面的四個步驟，如何用jmeter做接口測試？
1、 設計操作步驟：這里我們創建HTTP請求即可
添加——取樣器——HTTP請求
2、 設計數據用例：由於jmeter只支持CSV文件，所以設計測試用例時記得生成CSV格式的，將CSV導入到jmeter中（這部分在性能測試里面叫做jmeter的參數化）
添加——配置元件——CSV數據文件設置
3、 斷言，添加一個響應斷言即可（也可以加別的）
添加——斷言——響應斷言
4、 執行，添加一個結果樹
添加——監聽器——查看結果樹
7、抓包
一般情況下，做接口測試是有接口文檔的
但是如果沒有接口文檔我們怎么做接口測試？
這就需要抓包，請求我們是可以抓到的，響應如果抓不到，我們可以根據測試數據自己分析應該得到什么樣的結果
抓包工具推薦fiddler，兩個優勢：
1、簡單好用；
2、fiddler抓包后可以直接導出為jmeter腳本。
8、接口測試可以發現什么樣的Bug？
為什么要做接口測試？
基於兩個理由：
第一個：開發人員把這個接口或者把后台代碼開發好了，他會去做接口測試。開發人員自測完成后，我們測試人員可以對這個接口做一個全面的測試。
第二個：接口測試不會受到輸入界面的影響，那界面所做出的一些限制也就不存在了，我們直接測的就是后台這一塊兒，可以檢查后台有沒有做到相應的限制。
一個常見的問題，頁面的輸入框可能會有長度限制，比如限制只能輸入十個字符，但是后台並沒有做限制，這樣很容易會導致出現一些數據庫的異常，這樣的問題可能在功能測試里面沒辦法發現，但是接口測試可以。所以很多時候，接口測試，可以認為是功能測試的一種補充。它可以讓我們的測試做得更深入，更全面。深入淺出接口測試原理及步驟
1、接口測試原理
接口測試，實際上是針對於接口做測試的。
那么接口是什么？
軟件開發，既要做前端，也要做后端，並且后端是整個業務的核心，用於處理業務請求，實現具體的功能；而前端只是提供一個頁面給用戶看結果以及提供頁面給用戶做輸入。所以整個業務的處理邏輯都在后端。而后端邏輯相對很復雜，所以在開發的時候，會由架構師確定接口，然后再針對這個接口實現其具體的功能。
接口也可以認為是我們要做多少事情，因為在技術層面，如果要實現登錄、注冊、增、刪、改、查等操作，就會先設計好一個模塊，說明具體實現哪些功能點，這個功能點應該有哪些輸入項，有哪些方法。
這個東西就是我們所謂的接口，在java里，接口里包含屬性名和方法，所有的方法都是抽象方法，只有方法名，而沒有這個方法的具體實現。也就是說：我知道這是一個登錄功能，但是登錄怎么實現，這完全是不知道的，需要開發人員具體去實現。那么作為我們的開發人員，他就會領到一個任務去實現這個接口。比如，實現登錄接口，注冊接口等。
我們可以認為，雖然他是在實現登錄接口、注冊接口。也就相當於我們根據這個接口去實現登錄功能，注冊功能。所以這個接口實際上也就是后台一個具體的功能。
那么什么又是接口測試？
實際上我們所說的接口測試就是開發人員把這個接口實現了，他需要去驗證這個接口的實現是否正確。
但是這是一個后台的功能，這個開發也是一個后台開發，他去驗證接口的時候，他不會想讓前端人員介入，因為讓前台人員介入的話會比較麻煩。那么他就需要一個工具來模擬前端界面。（前端其實就是提供一個窗口，既能讓用戶輸入數據，並且還可以查看結果。）
2、接口測試的實現
實際上我們做接口測試，還是“輸入—處理—輸出”這樣的模式。用戶輸入一串數據，然后讓這個接口或者讓這個后台功能來處理，然后檢查輸出結果跟期望是否一致。
這個其實也就是我們所說的黑盒測試。也是我們做測試的一個常規的思路。用戶輸入一串數據，然后讓系統去處理，然后我們再去檢查結果跟期望是否一致。功能測試是這么做的，接口測試實際上還是這么做。
但是相對功能測試而言，接口測試有一個比較明顯的區別，就是輸入不再是界面的，而是一個基於HTTP的請求；輸出也不再是界面，而是基於HTTP的響應。所以需要通過請求和響應分別來輸入我們的數據以及檢查我們的結果。
3、接口測試用例
其實接口測試和的功能測試是非常相似的，功能測試怎么做，接口測試還是怎么做。
功能測試用例，最核心的三個部分就是：輸入、操作步驟和預期結果。
接口測試用例，其實主要的也就是這么三個部分。
平時所說的測試用例設計方法，也就是對輸入項進行各種不同的取值，然后再做組合。拿登錄來說，登錄功能有用戶名和密碼，那用戶名，有正確的用戶名和錯誤的用戶名兩種情況，密碼有正確的密碼和錯誤的密碼兩種情況。用戶名和密碼在一起就會產生一些組合：
（1）用戶名正確，密碼正確；
（2）用戶名正確，密碼錯誤；
（3）用戶名錯誤，密碼的正確；
（4）用戶名錯誤；密碼錯誤。
輸入時，選擇不同的數據組合會產生不同的測試場景，每一個場景都需要執行一遍。
功能測試是這么去做的，但是接口測試沒有界面，也就沒有辦法輸入，怎么辦？
接口測試里有個東西叫參數，這個參數就對應了功能測試里的輸入項。所以，接口測試用例其實也就是對輸入參數，做一個划分然后再做組合，形成接口測試用例。
每一組測試用例執行后，肯定會得到不同的結果。比如正確的用戶名和正確的密碼，結果是登錄成功；錯誤的用戶名或錯誤的密碼，結果是登錄失敗。那么只要思考，如何將參數取值和測試結果應用在工具中，這個問題就解決了。
4、接口測試工具
接口測試工具有很多，比如soapUI，postman，jmeter等。
工具其實只是工具而已。
做接口測試一定要明白的一個前提：接口測試的流程。
第一步，設計操作步驟。
操作步驟就是請求，有一些請求是是單獨的，有些請求是多個請求前后有聯系的，這種情況就需要創建關聯，。那么我們需要了解請求的格式，規范以及如何做關聯。soapUI，postman，jmeter里，都有關聯。
第二步，設計數據用例。
建議將數據用例寫到Excel文檔里，然后讓工具讀取Excel。Excel里有幾組數據用例，就執行幾次。循環執行（自動化），就可以讓每一個用例被執行一次，那么每一個測試場景也就被運行到了。
第三步：斷言。
也就是提前將預期結果寫入到工具中，讓工具自動化判斷結果是否正確。不同的工具叫法不同，soapUI和Jmeter中叫做斷言，postman中叫做tests。
第四步：執行並檢查測試結果。
執行很簡單，對測試結果進行分析的話就需要了解協議。知道發出去了什么，返回了什么，才能夠知道，到底哪個環節出了問題。
5、HTTP協議
HTTP協議非常重要。清楚了HTTP協議，再去使用工具其實就很容易，按照上面四個步驟就行。
為什么是HTTP協議而不是其他協議？因為90%的系統都是HTTP協議的。
HTTP協議包含請求和響應
請求就是用戶的輸入，響應就是結果。我們通過請求去找參數，然后輸入不同的參數值，然后組合成請求，只要這個請求是合法的，那么就可以發出去，並且能夠被服務器接收。所以，首先要能夠判斷出來什么叫做合法請求。
那么就需要去了解HTTP協議的請求的組成，請求的規范，知道哪些請求項是我們所關心的，哪些請求項是我們一定要遵循的，哪些項是我們可以刪除的。
同理，要想檢查結果是否正確，就需要去了解響應。
HTTP請求包含兩個部分
請求頭和請求體，請求頭的第一行非常的重要，包含請求方法和URL。這兩個東西是非常核心的東西。請求方法有GET方法，POST方法，需要知道他們之間的區別，當然區別最明顯的就是GET請求沒有請求體，而POST請求有請求體。URL，相當於接口的入口。請求頭里有很多項，每一項最好能知道是什么意思，並且要知道哪些項是比較核心的，其實核心的東西不多。一個是content-type，一個是cookies。
備注：網上很多資料會把請求分為三部分，請求行、請求頭和請求體。這里的請求頭的第一行其實就是請求行了，下面的響應也是一樣
請求體包括參數，一般我們在測試的時候會修改請求體里的東西。
懂了上面這些，就知道該如何組裝HTTP請求了。
響應包含兩個部分
一個是響應頭，一個是響應體。響應頭里的第一行有響應的狀態碼和狀態信息，這個非常重要。面試時候一般會被問到：狀態碼有幾類？一般是有五類，1開頭（請求正在處理），2開頭（請求處理成功），3開頭（重定向），4開頭（客戶端錯誤），5開頭（服務器錯誤），這五類分別代表什么需要記住。一般5開頭的都是系統bug。
6、JMeter
其實哪個工具都可以，但是jmeter有兩個好處，第一個：它是中文版的，學習成本較低，postman和soapUI都是英文版的；第二個，jmeter既可以做接口測試，又可以做性能測試。
對應上面的四個步驟，如何用jmeter做接口測試？
1、 設計操作步驟：這里我們創建HTTP請求即可
添加——取樣器——HTTP請求
2、 設計數據用例：由於jmeter只支持CSV文件，所以設計測試用例時記得生成CSV格式的，將CSV導入到jmeter中（這部分在性能測試里面叫做jmeter的參數化）
添加——配置元件——CSV數據文件設置
3、 斷言，添加一個響應斷言即可（也可以加別的）
添加——斷言——響應斷言
4、 執行，添加一個結果樹
添加——監聽器——查看結果樹
7、抓包
一般情況下，做接口測試是有接口文檔的
但是如果沒有接口文檔我們怎么做接口測試？
這就需要抓包，請求我們是可以抓到的，響應如果抓不到，我們可以根據測試數據自己分析應該得到什么樣的結果
抓包工具推薦fiddler，兩個優勢：
1、簡單好用；
2、fiddler抓包后可以直接導出為jmeter腳本。
8、接口測試可以發現什么樣的Bug？
為什么要做接口測試？
基於兩個理由：
第一個：開發人員把這個接口或者把后台代碼開發好了，他會去做接口測試。開發人員自測完成后，我們測試人員可以對這個接口做一個全面的測試。
第二個：接口測試不會受到輸入界面的影響，那界面所做出的一些限制也就不存在了，我們直接測的就是后台這一塊兒，可以檢查后台有沒有做到相應的限制。
一個常見的問題，頁面的輸入框可能會有長度限制，比如限制只能輸入十個字符，但是后台並沒有做限制，這樣很容易會導致出現一些數據庫的異常，這樣的問題可能在功能測試里面沒辦法發現，但是接口測試可以。所以很多時候，接口測試，可以認為是功能測試的一種補充。它可以讓我們的測試做得更深入，更全面。