1、get和post區別是什么？
答：POST和GET都是向服務器提交數據，並且都會從服務器獲取數據。
區別：
（1）傳送方式：get通過地址欄傳輸，post通過報文傳輸
（2）傳送長度：get參數有長度限制（受限於url長度），而post無限制
（3）GET產生一個TCP數據包（對於GET方式的請求，瀏覽器會把http header和data一並發送出去，服務器響應200返回數據），POST產生兩個TCP數據包（對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok返回數據）
（4）get請求參數會被完整保留在瀏覽歷史記錄里，而post中的參數不會被保留
（5）在做數據查詢時，建議用GET方式；而在做數據添加、修改或刪除時，建議用post方式
2、cookie和session的區別
（1）cookie數據存放在客戶的瀏覽器上，session數據放在服務器上
（2）cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙，考慮到安全應當使用session
（3）session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面應當使用cookie
（4）單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie
（5）可以將登陸信息等重要信息存放為session；其他信息需要保存，可以放在cookie
3、請求接口中常見的返回狀態碼
答：
1xx -- 信息提示（表示臨時的響應。客戶端在收到常規響應之前，准備接收一個或多個1xx響應）
2xx -- 成功（表明服務器成功地接受了客戶端請求）
3xx -- 重定向（客戶端瀏覽器必須采取更多操作來實現請求。例如，瀏覽器可能不得不請求服務器上的不同的頁面，或通過代理服務器重復該請求）
4xx -- 客戶端錯誤（發送錯誤，客戶端有問題。例如，客戶端請求不存在的頁面，客戶端未提供有效的身份證驗證信息）
5xx -- 服務器錯誤（服務器由於遇到錯誤而不能完成該請求）
常見的有
（1）200 OK - [GET]：服務器成功返回用戶請求的數據
（2）201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數據成功
（3）202 Aceepted - [*]：表示一個請求已經進入后台排隊（異步任務）
（4）204 NO CONTENT - [DELETE]：用戶刪除數據成功
（5）400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發出的請求有錯誤，服務器沒有進行新建或修改數據的操作
（6）401 Unauthorized -[*] ：表示用戶沒有權限（令牌、用戶名、密碼錯誤）
（7）403 Forbidden -[*] ：表示用戶得到授權（與401錯誤相對），但是訪問被禁止
（8）404 NOT FOUND -[*]：用戶發出的請求針對得到是不存在的記錄，服務器沒有進行操作，該操作是冪等的
（9）406 Not Acceptable - [GET]：用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）。
（10）410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再得到的。
（11）422 Unprocesable entity - [POST/PUT/PATCH] 當創建一個對象時，發生一個驗證錯誤。
（12）500 INTERNAL SERVER ERROR - [*]：服務器發生錯誤，用戶將無法判斷發出的請求是否成功。
4、怎么設計接口測試用例
通常，設計接口測試用例需要考慮以下幾個方面：
（1）是否滿足前提條件
有些接口需要滿足前提，才可成功獲取數據。常見的，需要登錄Token
逆向用例：針對是否滿足前置條件（假設為n個條件），設計0~n條用例
（2）是否攜帶默認值參數
正向用例：帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的“常規”值，其他不填寫，設計1條用例
（3）業務規則、功能需求
這里根據時間情況，結合接口參數說明，可能需要設計N條正向用例和逆向用例
（4）參數是否必填
逆向用例：針對每個必填參數，都設計1條參數值為空的逆向用例
（5）參數之間是否存在關聯
有些參數彼此之間存在相互制約的關系
（6）參數數據類型限制
逆向用例：針對每個參數都設計1條參數值類型不符的逆向用例
（7）參數數據類型自身的數據范圍值限制
正向用例：針對所有參數，設計1條每個參數的參數值在數據范圍內為最大值的正向用例
5、如何分析是前段還是后端的問題
（1）檢查接口，前端和后台之間是通過接口文件相互聯系的，需要查看接口文件
（2）檢查請求的數據是什么，反饋的數據又是什么
（3）根據接口文件，檢查數據是否正確。如果發送的數據是正確的，但是后台反饋的數據是不符合需求的，那就是后台的問題；如果前端沒有請求接口或請求的時候發送數據與需求不符，那這個時候就是前端的問題了。
（先抓包看請求報文，對着接口文檔，看請求報文有沒問題，有問題就是前端發的數據不對
請求報文沒問題，那就看返回報文，返回的數據不對，那就是后端開發的問題）
6、在手工接口測試或者自動化接口測試過程中，上下游接口有數據依賴如何處理？
答：在工具中可以使用全局變量等方式將需要的數據進行傳送
7、依賴第三方數據的接口如何進行測試？
答：可以使用SoapUI等工具直接調用第三方數據接口的webservice，通過返回值來查看第三方數據的接口是否調用正常
也可以利用一些MOCK的工具來模擬第三方的數據返回，最大限度的降低對第三方數據接口的依賴
8、接口測試中，依賴登錄狀態的接口如何測試？
答：依賴登錄狀態的接口的本質上是在每次發送請求時需要帶上session或者cookie才能發送成功，在構建POST請求時添加必要的session或者cookie
根據網絡資料，總結了以下一些常見的接口測試面試題：
- 為什么要做接口測試？
- 接口測試能發現哪些問題？
- 接口測試怎么測？
- 用什么工具測接口？
- WebService接口是如何測試的？
- 沒有接口文檔如何做接口測試？
- 在接口測試過程中，上下游接口有數據依賴如何處理？
- 依賴第三方數據的接口如何進行測試？
- 當一個接口出現異常時，你是如何分析異常的？
- 如何模擬弱網測試？
- 如何分析一個bug是前端的還是后端的？
為什么要做接口測試
在討論為什么要做接口測試之前，我們先稍微了解下接口是什么？
接口可以很不准確的理解成是與資源打交道，這個資源可能是本系統的，也可能是其他系統的。
舉個例子，假如我們在開發1個bug管理系統，該系統需要拿到公司的所有開發和測試人員的信息，這樣開發和測試人員不用注冊都可以登錄進去了，這應該很好理解。
那么這些人員的信息儲存在哪里呢？一般存儲在hr系統里。現在的需求更加明確了，我們要到hr系統中去拿到人員信息，獲取hr系統中的人員資源。
怎么拿呢？很多種方式，可以直接把hr系統的數據庫拷貝一份放到bug管理系統里，不過這樣不好，因為數據的同步會有點麻煩；還可以直接連hr系統的數據庫去查，這樣也不太好，這樣我們就需要了解hr系統的數據存儲結構和邏輯，一旦hr系統的數據字段發生改變，bug管理系統也要去該，以便同步。
比較好的做法是，hr系統暴露一些接口，通過這些接口去獲取人員信息資源，這樣bug系統就不需要關心hr系統的數據存儲實現了。
這些接口可能是這樣的：
- 登錄的接口，提供人員的用戶名和密碼，去hr系統中判斷該人員是否存在，如果存在驗證用戶名和密碼，如果驗證通過就返回1個token，該token就是這個人員的通行證，通過token可以登錄到bug管理系統中去；
- 獲取人員信息的接口，返回該人員的職位：測試還是開發，以及用戶名，昵稱等信息；
綜上：接口可以理解成是不同系統或模塊之間資源交流方式。
接口測試實際上是黑盒測試，基本的測試思路是根據輸入和輸出判斷被測系統或對象的邏輯。獲取人員的信息，我需要把人員的用戶名傳給hr系統接口，這樣hr系統的接口會返回給我用戶的一些更加具體的信息。這里的輸入是用戶名，輸出是用戶的詳細信息。
既然是接口獲取和操作資源的方式，而大部分系統和產品中，資源一般都是產品的核心，比如微信核心資源就是通訊錄關系鏈和聊天記錄等，因此資源是必測的。
另外接口中大部分的內容是數據，通過數據的對比我們能推測到系統和產品的邏輯，測接口就是測邏輯。
最后接口中的返回相對單純，不像web頁面，html代碼中有太多ui的東西，ui最不穩定，變化太快，接口相對穩定一點點，但是里面的干擾信息更少，斷言相對容易很多。
請看以下一個案例，如下圖一個提現功能
比如這個輸入框，平常拿到這個web頁面，會對輸入框做用例設計：
- 輸入一個負數（如：-100），點提交
- 輸入金額為0（如：0），點提交
- 輸入金額為0-100的數（如：20），點提交
- 輸入金額為100（如：100），點提交
- 輸入金額大於100（如：108），點提交
- 輸入1位小數（如：10.1），點提交
- 輸入2位小數（如：10.12），點提交
- 輸入3位小數（如：10.123），點提交
按照這個等價類，邊界值用例測完，頁面上不能輸入負數和大於3位數小數點，然后就可以上線了。
然而。。。突然有一天數據庫里面插入了一個提現金額為負數（-100），於是整個部門炸鍋了，首先找到測試（背鍋）去復現問題，測試在頁面上反復輸入負數，無法提交，認為沒問題啊！
首先前端開發對輸入框是做了限制的，前端的web開發肯定沒問題，這個鍋前端開發MM不背。那么如果別人用戶不通過你的web頁面，直接發請求提交了呢？
納尼！！！不通過頁面也能提交。。。這就是我們接下來要提到的接口測試了。
接口測試能發現哪些問題
這個問題其實回到起來很簡單，只要做過接口測試的，總能發現幾個BUG吧，把你平常發現的bug說2-3個就可以了。
面試官出這個題，主要是想知道你是不是真的做過接口測試，畢竟現在很多小伙伴簡歷都是寫的假的（你要不寫估計面試機會都沒有，沒辦法，為了生存，能理解）
比如上面說的，提現輸入框，在頁面上輸入負數，肯定是無法提交過去（前端頁面會判斷金額），如果我不走前端，直接用接口工具發請求，輸入一個負數過去。
（假設服務端沒做提現金額數據判斷）
余額=當前余額（100）-提現金額（-100），那么提現-100，余額就變成200了，也就是越提現，余額越大了
可以用接口工具去直接請求接口，也可以fiddler抓包，抓到接口后修改金額為負數
所以，接口測試的必要性就體現出來了：
1.可以發現很多在頁面上操作發現不了的bug
2.檢查系統的異常處理能力
3.檢查系統的安全性、穩定性
4.前端隨便變，接口測好了，后端不用變
5.可以測試並發情況，一個賬號，同時（大於2個請求）對最后一個商品下單，或不同賬號，對最后一個商品下單
6.可以修改請求參數，突破前端頁面輸入限制（如金額）
接口測試怎么測
- 通過性驗證：首先肯定要保證這個接口功能是好使的，也就是正常的通過性測試，按照接口文檔上的參數，正常傳入，是否可以返回正確的結果。
-
參數組合：現在有一個操作商品的接口，有個字段type，傳1的時候代表修改商品，商品id、商品名稱、價格有一個是必傳的，type傳2的時候是刪除商品，
商品id是必傳的，這樣的，就要測參數組合了，type傳1的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。 -
接口安全：
1、繞過驗證，比如說購買了一個商品，它的價格是300元，那我在提交訂單時候，我把這個商品的價格改成3元，后端有沒有做驗證，更狠點，我把錢改成-3，是不是我的余額還要增加？
2、繞過身份授權，比如說修改商品信息接口，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功
3、參數是否加密，比如說我登陸的接口，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。
4、密碼安全規則，密碼的復雜程度校驗 -
異常驗證：
所謂異常驗證，也就是我不按照你接口文檔上的要求輸入參數，來驗證接口對異常情況的校驗。比如說必填的參數不填，輸入整數類型的，傳入字符串類型，長度是10的，傳11，總之就是你說怎么來，我就不怎么來，其實也就這三種，必傳非必傳、參數類型、入參長度。 -
性能測試
接口並發情況，如上面提到的：一個賬號，同時（大於2個請求）對最后一個商品下單，或不同賬號，對最后一個商品下單
接口響應時間，響應時間太長了，肯定需要優化，一般都是毫秒級別
用什么工具測接口
- postman： 推薦。基本功能免費。最簡單的基於http接口的調試和測試工具;
- jmeter：后置處理器配合斷言基本上可以滿足接口測試需求，就是測試報告要做二次開發
- 自己擼代碼：推薦。配合類似xunit測試框架，基本可以滿足一切需求；零基礎實現python接口自動化視頻教程，一起擼代碼吧
- soapui: 收費的；
- insomnia：強力推薦。postman的弱化版，基本功能免費，重要的是工具代碼開源，可以自己改；
- paw: 強力推薦。mac上最強，淘寶買個授權好像就百把塊錢；
WebService接口是如何測試的
webService接口用SoapUI
沒有接口文檔如何做接口測試
沒有接口文檔，那還能咋辦，瞎測唄！一個公司的開發流程里面，如果接口文檔都沒有，是無法展開接口測試的，你都不知道這個接口干什么的，也不知道具體每個字段代表什么意思，那還測啥呢？
--當然，你肯定不能回答面試官不測(心理mmp，臉上笑嘻嘻)，接下來就是扯犢子時間
1.沒有接口文檔，那就需要先跟開發溝通，然后整理接口文檔（本來是開發寫的，沒辦法，為了唬住面試官，先說自己整理了）
2.沒有接口文檔，可以抓包看接口請求參數，然后不懂的跟開發溝通
本題主要靠情商，通俗來說就是忽悠能力，先唬住面試官了再說，進去了也是瞎測測，隨時做好背鍋的准備
在接口測試過程中，上下游接口有數據依賴如何處理
用一個全局變量來處理依賴的數據，比如登錄后返回token,其它接口都需要這個token,那就用全局變量來傳token參數
依賴第三方數據的接口如何進行測試
這個標准答案是：mock
接着面試官會問你，如果mock的，然后你就順着坑繼續挖，搭建mock服務，參考這篇【https://www.cnblogs.com/yoyoketang/p/9348552.html】
當一個接口出現異常時，你是如何分析異常的
1.抓包，用fiddler工具抓包，或者瀏覽器上f12,app上的話，那就用fiddler設置代理，去看請求報文和返回報文了
2.查看后端日志，xhell連上服務器，查看日志
如何模擬弱網測試
fiddler和charles都可以模擬弱網測試，平常說的模擬丟包，也是模擬弱網測試
如何分析一個bug是前端還是后端的
平常提bug的時候，前端開發和后端開發總是扯皮，不承認是對方的bug
這種情況很容易判斷，先抓包看請求報文，對着接口文檔，看請求報文有沒問題，有問題就是前端發的數據不對
請求報文沒問題，那就看返回報文，返回的數據不對，那就是后端開發的問題咯