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
