介面測試主要用於外部系統與系統之間以及內部各個子系統之間的互動點，定義特定的互動點，然後通過這些互動點來，通過一些特殊的規則也就是協議，來進行資料之間的互動。

二、介面的型別

介面一般分為兩種：

　　1、程式內部的介面

　　程式內部的介面：方法與方法之間，模組與模組之間的互動，程式內部丟擲的介面，比如bbs系統，有登入模組、發帖模組等等，那你要發帖就必須先登入，那麼這兩個模組就得有互動，它就會丟擲一個介面，供內部系統進行呼叫。

　　2、系統對外的介面

　　系統對外的介面：比如你要從別的網站或伺服器上獲取資源或資訊，別人肯定不會把資料庫共享給你，他只能給你提供一個他們寫好的方法來獲取資料，你引用他提供的介面就能使用他寫好的方法，從而達到資料共享的目的。

比較常見的介面：

　　1、HTTP介面

　　2、WebService介面

　　http介面是走http協議，通過路徑來區分呼叫的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。　

　　WebService介面是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行呼叫，測試。

　　Json是一種通用的資料型別，所有的語言都認識它。（json的本質是字串，他與其他語言無關，只是可以經過稍稍加工可以轉換成其他語言的資料型別，比如可以轉換成Python中的字典，key-value的形式，可以轉換成JavaScript中的原生物件，可以轉換成java中的類物件等。）

三、介面的本質及工作原理

　　介面你可以簡單的理解他就是URL，工作原理就會說URL通過get或者post請求像伺服器傳送一些東西，然後得到一些相應的返回值，本質就是資料的傳輸與接收

四、什麼是介面測試

　　介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

五、為什麼要進行介面測試

　　1、越底層發現bug，它的修復成本越低。

　　2、前端隨便變，介面測好了，後端不用變，前後端是兩撥人開發的。

　　3、檢查系統的安全性、穩定性，前端傳參不可信，比如京東購物，前端價格不可能傳入-1元，但是通過介面可以傳入-1元。

　　4、如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，介面測試可以提供這種情況下的解決方案。

　　5、介面測試相對容易實現自動化持續整合，且相對UI自動化也比較穩定，可以減少人工迴歸測試人力成本與時間，縮短測試周期，支援後端快速發版需求。介面持續整合是為什麼能低成本高收益的根源。

　　6、現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端實在太容易）， 需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證。前後端傳輸、日誌列印等資訊是否加密傳輸也是需要驗證的，特別是涉及到使用者的隱私資訊，如身份證，銀行卡等。

六、如何進行介面測試

　　1、HTTP介面

　　基於http協議的介面，主要是通過工具或程式碼模擬http請求的傳送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。也可以用 介面自動化來實現，就是用程式碼實現，框架和UI自動化差不多，傳送請求用斷言來判斷。

　　2、webService介面

　　不需要再拼報文了，會給一個webservice的地址，或者wsdl檔案，直接在soapui匯入，就可以看到這個webservice裡面的所有介面，也有報文，直接填入引數呼叫，看返回結果就可以了。 

七、介面測試要點　

　　目的：測試介面的正確性和穩定性；

　　原理：模擬客戶端向伺服器傳送請求報文，伺服器接收請求報文後對相應的報文做處理並向客戶端返回應答，客戶端接收應答的過程；

　　重點：檢查資料的交換，傳遞和控制管理過程，還包括處理的次數；

　　核心：持續整合是介面測試的核心；

　　優點：為高複雜性的平臺帶來高效的缺陷監測和質量監督能力，平臺越複雜，系統越龐大，介面測試的效果越明顯（提高測試效率，提升使用者體驗，降低研發成本）；

　　用例設計重點：通常情況下主要測試最外層的兩類介面:資料進入系統介面（呼叫外部系統的引數為本系統使用）和資料流出系統介面（驗證系統處理後的資料是否正常）；

　　PS：設計用例時還需要注意外部介面提供給使用這些介面的外部使用者什麼功能，外部使用者真正需要什麼功能；

結論：

　　1、介面測試和UI測試有部分重複的內容，主要集中在業務功能測試方面。除此之外，針對各自特性的測試都不一樣，需要分別進行有針對性的測試，才能確保整個產品的質量。

　　2、介面測試可以關注於伺服器邏輯驗證，而UI測試可以關注於頁面展示邏輯及介面前端與伺服器整合驗證

　　3、介面測試持續整合：

　　對介面測試而言，持續整合自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益。介面測試包括但不限於下面的內容：

　　a) 流程方面：在迴歸階段加強介面異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。

　　b) 結果展示：更加豐富的結果展示、趨勢分析，質量統計和分析等

　　c) 問題定位：報錯資訊、日誌更精準，方便問題復現與定位。

　　d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。

　　e) 程式碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高程式碼覆蓋率。

　　f) 效能需求：完善效能測試體系，通過自動化的手段監控介面效能指標是否正常。

　　4、介面測試質量評估標準：

　　a) 業務功能覆蓋是否完整

　　b) 業務規則覆蓋是否完整

　　c) 引數驗證是否達到要求（邊界、業務規則）

　　d) 介面異常場景覆蓋是否完整

　　e) 介面覆蓋率是否達到要求

　　f)  程式碼覆蓋率是否達到要求

　　g) 效能指標是否滿足要求

　　h) 安全指標是否滿足要求

八、介面測試需要掌握的知識

　　1、瞭解系統及內部各個元件之間的業務邏輯互動；

　　2、瞭解介面的I/O（input/output：輸入輸出）；

　　3、瞭解協議的基本內容，包括：通訊原理、三次握手、常用的協議型別、報文構成、資料傳輸方式、常見的狀態碼、URL構成等；

　　4、常用的介面測試工具，比如：jmeter、loadrunner、postman、soapUI等；

　　5、資料庫基礎操作命令（檢查資料入庫、提取測試資料等）；

　　6、常見的字元型別，比如：char、varchar、text、int、float、datatime、string等；

九、其他相關知識

Get請求，Post請求的區別：

　　1、GET使用URL或Cookie傳參。而POST將資料放在Body中。

　　2、GET的URL會有長度上的限制，則POST的資料則可以非常大。

　　3、POST比GET安全，因為資料在位址列上不可見。

　　4、一般get請求用來獲取資料，post請求用來發送資料。

　　其實上面這幾點，只有最後一點說的是比較靠譜的，第一點post請求也可以把資料放到url裡面，get請求其實也沒長度限制，post請求看起來引數是隱式的，稍微安全那麼一些些，但是那只是對於小白使用者來說的，就算post請求，你通過抓包也是可以抓到引數的。（唯一區別就是這一點，上面3點區別都是不準確的）

http狀態碼：

　　1、200 2開頭的都表示這個請求傳送成功，最常見的就是200，就代表這個請求是ok的，伺服器也返回了。

　　2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了。

　　3、400 400代表客戶端傳送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有許可權訪問這個頁面，404代表沒有這個頁面。

　　4、500 5開頭的代表伺服器有異常，500代表伺服器內部異常，504代表伺服器端超時，沒返回結果。

cookie與session的區別：

　　1、cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上。

　　2、cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙考慮到安全應當使用session。

　　3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能考慮到減輕伺服器效能方面，應當使用cookie。

　　4、單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。

　　5、所以個人建議：

　　　 將登陸資訊等重要資訊存放為session

　　　 其他資訊如果需要保留，可以放在cookie中

介面測試主要用於外部系統與系統之間以及內部各個子系統之間的互動點，定義特定的互動點，然後通過這些互動點來，通過一些特殊的規則也就是協議，來進行資料之間的互動。

二、介面的型別

介面一般分為兩種：

　　1、程式內部的介面

　　程式內部的介面：方法與方法之間，模組與模組之間的互動，程式內部丟擲的介面，比如bbs系統，有登入模組、發帖模組等等，那你要發帖就必須先登入，那麼這兩個模組就得有互動，它就會丟擲一個介面，供內部系統進行呼叫。

　　2、系統對外的介面

　　系統對外的介面：比如你要從別的網站或伺服器上獲取資源或資訊，別人肯定不會把資料庫共享給你，他只能給你提供一個他們寫好的方法來獲取資料，你引用他提供的介面就能使用他寫好的方法，從而達到資料共享的目的。

比較常見的介面：

　　1、HTTP介面

　　2、WebService介面

　　http介面是走http協議，通過路徑來區分呼叫的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。　

　　WebService介面是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行呼叫，測試。

　　Json是一種通用的資料型別，所有的語言都認識它。（json的本質是字串，他與其他語言無關，只是可以經過稍稍加工可以轉換成其他語言的資料型別，比如可以轉換成Python中的字典，key-value的形式，可以轉換成JavaScript中的原生物件，可以轉換成java中的類物件等。）

三、介面的本質及工作原理

　　介面你可以簡單的理解他就是URL，工作原理就會說URL通過get或者post請求像伺服器傳送一些東西，然後得到一些相應的返回值，本質就是資料的傳輸與接收

四、什麼是介面測試

　　介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

五、為什麼要進行介面測試

　　1、越底層發現bug，它的修復成本越低。

　　2、前端隨便變，介面測好了，後端不用變，前後端是兩撥人開發的。

　　3、檢查系統的安全性、穩定性，前端傳參不可信，比如京東購物，前端價格不可能傳入-1元，但是通過介面可以傳入-1元。

　　4、如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，介面測試可以提供這種情況下的解決方案。

　　5、介面測試相對容易實現自動化持續整合，且相對UI自動化也比較穩定，可以減少人工迴歸測試人力成本與時間，縮短測試周期，支援後端快速發版需求。介面持續整合是為什麼能低成本高收益的根源。

　　6、現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端實在太容易）， 需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證。前後端傳輸、日誌列印等資訊是否加密傳輸也是需要驗證的，特別是涉及到使用者的隱私資訊，如身份證，銀行卡等。

六、如何進行介面測試

　　1、HTTP介面

　　基於http協議的介面，主要是通過工具或程式碼模擬http請求的傳送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。也可以用 介面自動化來實現，就是用程式碼實現，框架和UI自動化差不多，傳送請求用斷言來判斷。

　　2、webService介面

　　不需要再拼報文了，會給一個webservice的地址，或者wsdl檔案，直接在soapui匯入，就可以看到這個webservice裡面的所有介面，也有報文，直接填入引數呼叫，看返回結果就可以了。 

七、介面測試要點　

　　目的：測試介面的正確性和穩定性；

　　原理：模擬客戶端向伺服器傳送請求報文，伺服器接收請求報文後對相應的報文做處理並向客戶端返回應答，客戶端接收應答的過程；

　　重點：檢查資料的交換，傳遞和控制管理過程，還包括處理的次數；

　　核心：持續整合是介面測試的核心；

　　優點：為高複雜性的平臺帶來高效的缺陷監測和質量監督能力，平臺越複雜，系統越龐大，介面測試的效果越明顯（提高測試效率，提升使用者體驗，降低研發成本）；

　　用例設計重點：通常情況下主要測試最外層的兩類介面:資料進入系統介面（呼叫外部系統的引數為本系統使用）和資料流出系統介面（驗證系統處理後的資料是否正常）；

　　PS：設計用例時還需要注意外部介面提供給使用這些介面的外部使用者什麼功能，外部使用者真正需要什麼功能；

結論：

　　1、介面測試和UI測試有部分重複的內容，主要集中在業務功能測試方面。除此之外，針對各自特性的測試都不一樣，需要分別進行有針對性的測試，才能確保整個產品的質量。

　　2、介面測試可以關注於伺服器邏輯驗證，而UI測試可以關注於頁面展示邏輯及介面前端與伺服器整合驗證

　　3、介面測試持續整合：

　　對介面測試而言，持續整合自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益。介面測試包括但不限於下面的內容：

　　a) 流程方面：在迴歸階段加強介面異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。

　　b) 結果展示：更加豐富的結果展示、趨勢分析，質量統計和分析等

　　c) 問題定位：報錯資訊、日誌更精準，方便問題復現與定位。

　　d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。

　　e) 程式碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高程式碼覆蓋率。

　　f) 效能需求：完善效能測試體系，通過自動化的手段監控介面效能指標是否正常。

　　4、介面測試質量評估標準：

　　a) 業務功能覆蓋是否完整

　　b) 業務規則覆蓋是否完整

　　c) 引數驗證是否達到要求（邊界、業務規則）

　　d) 介面異常場景覆蓋是否完整

　　e) 介面覆蓋率是否達到要求

　　f)  程式碼覆蓋率是否達到要求

　　g) 效能指標是否滿足要求

　　h) 安全指標是否滿足要求

八、介面測試需要掌握的知識

　　1、瞭解系統及內部各個元件之間的業務邏輯互動；

　　2、瞭解介面的I/O（input/output：輸入輸出）；

　　3、瞭解協議的基本內容，包括：通訊原理、三次握手、常用的協議型別、報文構成、資料傳輸方式、常見的狀態碼、URL構成等；

　　4、常用的介面測試工具，比如：jmeter、loadrunner、postman、soapUI等；

　　5、資料庫基礎操作命令（檢查資料入庫、提取測試資料等）；

　　6、常見的字元型別，比如：char、varchar、text、int、float、datatime、string等；

九、其他相關知識

Get請求，Post請求的區別：

　　1、GET使用URL或Cookie傳參。而POST將資料放在Body中。

　　2、GET的URL會有長度上的限制，則POST的資料則可以非常大。

　　3、POST比GET安全，因為資料在位址列上不可見。

　　4、一般get請求用來獲取資料，post請求用來發送資料。

　　其實上面這幾點，只有最後一點說的是比較靠譜的，第一點post請求也可以把資料放到url裡面，get請求其實也沒長度限制，post請求看起來引數是隱式的，稍微安全那麼一些些，但是那只是對於小白使用者來說的，就算post請求，你通過抓包也是可以抓到引數的。（唯一區別就是這一點，上面3點區別都是不準確的）

http狀態碼：

　　1、200 2開頭的都表示這個請求傳送成功，最常見的就是200，就代表這個請求是ok的，伺服器也返回了。

　　2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了。

　　3、400 400代表客戶端傳送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有許可權訪問這個頁面，404代表沒有這個頁面。

　　4、500 5開頭的代表伺服器有異常，500代表伺服器內部異常，504代表伺服器端超時，沒返回結果。

cookie與session的區別：

　　1、cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上。

　　2、cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙考慮到安全應當使用session。

　　3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能考慮到減輕伺服器效能方面，應當使用cookie。

　　4、單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。

　　5、所以個人建議：

　　　 將登陸資訊等重要資訊存放為session

　　　 其他資訊如果需要保留，可以放在cookie中