介面測試是什麼？如何做好介面測試？
文章目錄
1.什麼是介面？
2.介面都有哪些類型？
3.什麼是介面測試？
4.為什麼要做介面測試？
5.怎樣做介面測試？
6.介面測測試點是什麼？
7.介面測試都要掌握哪些知識？
8.其他相關知識？
1.什麼是介面？
形象來講：我們天天用的手機，需要充電，那麼我們需要給給手機插上充電器， 如果充電器的介面型號對不上，那麼就不能進行充電， 我們調用介面也是一樣，必須要根據介面設計文檔來，不能自己隨心所欲去調用。
從另一個角度說，介面就是外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，然後通過這些交互點來，通過一些特殊的規則也就是協議，來進行數據之間的交互。
2.介面都有哪些類型？
軟體中的介面：就是對外提供了一種服務
本地介面：我們提供的basepage、 DBUtil、selenium、 htmltestrunner、pymysql中封裝了很多方法，方便調用，那這些方法也可以算介面，只是是本地介面，不能通過網路訪問而已
網路介面：軟體提供了一種服務，但是這個服務部署好之後，可以通過網路遠程調用、socket介面、webservice介面、http介面（這個是目前介面測試最主要的一種協議）
3.什麼是介面測試？
介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
簡單來說就是調用介面，然後輸入參數的各種情況，檢查對應的輸出是否符合預期
4.問什麼要做介面測試？
1.測試場景更完善，測試一些通過頁面不能構造的場景，銀行app轉賬金額不能是0，但是通過介面可以構造轉賬0元的場景。
2、檢查系統的安全性、穩定性，前端傳參不可信，比如淘寶購物，前端價格不可能傳入-1元，但是通過介面可以傳入-1元。
3.如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，介面測試可以提供這種情況下的解決方案。
4. 介面測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮短測試周期，支援後端快速發版需求。介面持續集成是為什麼能低成本高收益的根源。
5. 現在很多系統前後端架構是分離的，從安全層面來說：
(1)、只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證。
(2)、前後端傳輸、日誌列印等資訊是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私資訊，如身份證，銀行卡等。
6.介面自動化測試可以儘早發現系統服務端存在的問題，儘早修復，縮短測試周期。
5.怎樣做介面測試？
–由於我們項目前後端調用主要是基於http協議的介面，所以測試介面時主要是通過工具或程式碼模擬http請求的發送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、python+requests、robotframework+httplibrary等。
–也可以用 介面自動化來實現，就是用程式碼實現，框架主要也就是介面對象模型，這種模型抽取出介面後，可以最大程度的提升介面的復用性，提高用例的可維護性。
6.介面測測試點是什麼？
目的：測試介面的正確性和穩定性；
原理：模擬客戶端向伺服器發送請求報文，伺服器接收請求報文後對相應的報文做處理並向客戶端返回應答，客戶端接收應答的過程；
重點：檢查數據的交換，傳遞和控制管理過程，還包括處理的次數；
核心：持續集成是介面測試的核心；
優點：為高複雜性的平台帶來高效的缺陷監測和品質監督能力，平台越複雜，系統越龐大，介面測試的效果越明顯（提高測試效率，提升用戶體驗，降低研發成本）；
用例設計重點：通常情況下主要測試最外層的兩類介面:數據進入系統介面（調用外部系統的參數為本系統使用）和數據流出系統介面（驗證系統處理後的數據是否正常）；
PS：設計用例時還需要注意外部介面提供給使用這些介面的外部用戶什麼功能，外部用戶真正需要什麼功能；
問題1.1、後端介面都測試什麼？
–回答這個問題，我們可以從介面測試活動內容的角度下手，看一下面這張圖，基本反應了當前我們項目後端介面測試的主要內容：
問題2、後端介面測試一遍 ，前端也測試一遍，是不是重複測試了？
–回答這個問題，我們可以直接對比介面測試和app端測試活動的內容，如下圖為app測試時需要覆蓋或考慮內容：
從上面這兩張圖對比可以看出，兩個測試活動中相同的部分有功能測試、邊界分析測試和性能測試，其它部分由於各自特性或關注點不同需要進行特殊的測試，在此不做討論。接下來我們針對以上三部分相同的內容再進行分析：
1、基本功能測試：
由於是針對基本業務功能進行測試，所以這部分是兩種測試重合度最高的一塊，開發同學通常所指的也主要是這部分的內容。
2、邊界分析測試：
在基本功能測試的基礎上考慮輸入輸出的邊界條件，這部分內容也會有重複的部分（比如業務規則的邊界）。但是，前端的輸入輸出很多時候都是提供固守的值讓用戶選擇（如下拉框），在這種情況下測試的邊界範圍就非常有限，但介面測試就不存在這方面的限制，相對來說介面可以覆蓋的範圍更廣，同樣的，介面出現問題的概率也更高。
3、性能測試：
這個比較容易區分，雖然都需要做性能測試，但關注點確大不相同。App端性能主要關注與手機相關的特性，如手機cpu、記憶體、流量、fps等。而介面性能主要關注介面響應時間、並發、服務端資源的使用情況等。兩種測試時的策略和方法都有很大區別，所以這部分內容是需要分開單獨進行測試的，理論上來說這也是不同的部分。
綜論：
1、介面測試和app測試的活動有部分重複的內容，主要集中在業務功能測試方面。除此之外，針對各自特性的測試都不一樣，需要分別進行有針對性的測試，才能確保整個產品的品質。
2、介面測試可以關注於伺服器邏輯驗證，而UI測試可以關注於頁面展示邏輯及介面前端與伺服器集成驗證
4、介面測試持續集成：
對介面測試而言，持續集成自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實現了介面自動化，主要應用於回歸階段，後續還需要加強自動化的程度，包括但不限於下面的內容：
a) 流程方面：在回歸階段加強介面異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。
b) 結果展示：更加豐富的結果展示、趨勢分析，品質統計和分析等
c) 問題定位：報錯資訊、日誌更精準，方便問題復現與定位。
d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。
e) 程式碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高程式碼覆蓋率。
f) 性能需求：完善性能測試體系，通過自動化的手段監控介面性能指標是否正常。
5、介面測試品質評估標準：
a) 業務功能覆蓋是否完整
b) 業務規則覆蓋是否完整
c) 參數驗證是否達到要求（邊界、業務規則）
d) 介面異常場景覆蓋是否完整
e) 介面覆蓋率是否達到要求
f) 程式碼覆蓋率是否達到要求
g) 性能指標是否滿足要求
h) 安全指標是否滿足要求
7.介面測試都要掌握哪些知識？
①了解系統及內部各個組件之間的業務邏輯交互；
②了解介面的I/O（input/output：輸入輸出）；
③了解協議的基本內容，包括：通訊原理、三次握手、常用的協議類型、報文構成、數據傳輸方式、常見的狀態碼、URL構成等；
④常用的介面測試工具，比如：jmeter、loadrunner、postman、soapUI等；
⑤資料庫基礎操作命令（檢查數據入庫、提取測試數據等）；
⑥常見的字元類型，比如：char、varchar、text、int、float、datatime、string等；
如何學這些技能？
- 系統間業務交互邏輯：通過需求文檔、流程圖、思維導圖、溝通等很多渠道和方式；
- 協議：推薦《圖解http》這本書，內容生動，相對算是入門級的書籍，其他的還有《圖解tcp、IP》等；
- 介面測試工具：百度這些工具，然後你會發現，好多的教學部落格、相關問題解決方案、以及一些基於工具的書籍，當然，選擇合適的書很重要；
- 資料庫操作命令：學習網站（W3C、菜鳥教程）、教學部落格，以及一些資料庫相關書籍，入門級推薦：《mysql必知必會》、《oracle PL/SQL必知必會》等
- 字元類型：還是百度，有句話這麼說：內事不決問百度，外事不決問Google。。。
- 關注公 眾 號:零基礎學自動化測試實戰
如何獲取介面相關資訊？
一般的企業，都會由開發或者對應的技術負責人員編寫介面文檔，裡面會註明介面相關的地址、參數類型、方法、輸入、輸出等資訊，如果沒有，想辦法獲取。。。
介面文檔八要素：
封面：封面最好是本公司規定的封面，有logo，內容標題，版本號，公司名稱，文檔產生日期；
修訂歷史：表格形式較好些，包括：版本、修訂說明、修訂日期、修訂人、審核時間審核人等；
介面資訊：介面調用方式，常用的GET/POST方式，介面地址；
功能描述：簡潔清晰的描述介面功能，比如：介面獲取的資訊不包括哪些；
介面參數說明：每個參數都要和實際中調用的一樣，包括大小寫；參數的含義言簡意賅的說明，格式，是string 還是int 還是long等格式；
說明部分，說明參數值是需要哪裡提供，並詳細說明參數怎麼生成的，例如時間戳，是哪個時間段的，參數是否必填，一些參數是必須要有的，有些是可選參數等；
返回值說明：
①最好有一個模板返回值，並說明每個返回參數的意義；
②提供一個真實的調用介面，真實的返回值；
調用限制，安全方面：
加密方式，或者自己公司一個特殊的加密過程，只要雙方採用一致的加密演算法就可以調用介面，保證了介面調用的安全性，比如常見的md5；
文檔維護：文檔在維護的時候，如有修改一定要寫上修改日期，修改人，對大的修改要有版本號變更；
8.其他相關知識？
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狀態碼：
表示http響應狀態的三位數字， 不同數據有不同的含義， 常見狀態碼含義如下
200 OK //客戶端請求成功，系統正常處理了這次請求 400 Bad Request //客戶端請求有語法錯誤，不能被伺服器所理解 #很多時候我們構造的請求數據格式錯了 403 Forbidden //伺服器收到請求，但是拒絕提供服務 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL 或者服務沒有部署好 500 Internal Server Error //伺服器發生不可預期的錯誤 一般看到這種錯誤提單
502 Bad GateWay //網關錯誤， 說明網路不通， 或者伺服器沒有開啟
其實響應碼可以代表任何意義，只要雙方溝通清楚就行，上面只是說行業標準這樣，大家都按照這個要求去做的
http協議如何識別這次請求來自誰？
對於服務端來說，任何一次請求都是全新的開始，也就是說每次請求都是獨立的，那我認證了獲取服務端授權之後，後面的請求，服務端怎麼知道我是誰的呢？
主流的思路如下
第一次請求時，我帶上用戶名和密碼， 然後服務端校驗傳遞的用戶名密碼正確之後，返回一個唯一的字元串，俗稱token， 後面請求帶上這個token，服務端就知道這個請求是來自誰啦。
這樣做的好處是什麼？ 不需要每次都傳用戶名和密碼，用戶名和密碼暴露的風險就小很多， 系統會更加安全
那麼這個token可以放在請求哪些位置呢？ 請求頭、cookie、傳遞的數據中都是可以的， 只要能夠攜帶數據都可以用， 但是絕大多數請求都是放在cookie中
cookie的簡單理解
由服務端發送出來以存儲在網路瀏覽器（當然如果是介面測試，我們就要想辦法自己保存，瀏覽器有自己的cookie管理器）上，下一次請求 瀏覽器會自動根據介面調用匹配對應cookie
COOKIE主要有哪些欄位呢：
1、name COOKIE的名字
2、value COOKIE對應的值
3、domain 域名 就是說這個COOKIE對應哪一個域名有效
4、path 路徑 ， COOKIE對應的哪一個路徑才會有效
5、expires/Max-Age 欄位為此cookie超時時間。若設置其值為一個時間，那麼當到達此時間後，此cookie失效。不設置的話默認值是Session，意思是cookie會和session一起失效。當瀏覽器關閉(不是瀏覽器標籤頁，而是整個瀏覽器) 後，此cookie失效。
舉一個例子， 訪問禪道伺服器返回的內容中的COOKIE值
Set-Cookie: id=123456789; expires=Tue, 26-Otc-2020 08:16:28 GMT; domain = 119.29.100.135 path=/pro/
cookie匹配的時候 1、域名(IP)必須一致， 2、cookie必須有效， 3、路徑必須在指定的路徑之內（和指定路徑相同或者在指定路徑的子路徑）
1、//119.29.100.138/pro/
2、//119.29.100.135/pro/
3、//119.29.100.135/pro/test/
4、//119.29.100.135/pro11/
5、//119.29.100.135/test/pro/
2、3訪問的時候會帶上對應的COOKIE id =123456789
1、不會帶上因為域名不對
4、不會帶上因為路徑不對
5、不會帶上，埠號後面不是/pro/開始
