1，目前市面上流行的介面大多有哪幾種協議的介面？
答：http,https,dubbo,rpc等即可，
2，介面的請求方式有哪幾種？
答：get,post,put,delete,head,Trace,opions等，大多以get和post請求為主
3、get和post區別是什么？
答：POST和GET都是向服務器提交資料，并且都會從服務器獲取資料，
區別：
（1）傳送方式：get通過地址欄傳輸，post通過報文傳輸，故而post更相對來說私密性一點
（2）傳送長度：get引數有長度限制（受限于url長度），而post無限制
（3）get請求引數會被完整保留在瀏覽歷史記錄里，而post中的引數不會被保留
（4）get方式大多用作查詢介面，獲取回應資料；而post方式更多做資料添加、修改或洗掉等操作
4，post請求的請求型別有哪幾種？
application/json json字串
application/x-www-from-urlencoded 表單傳遞
multipart/form-data 主要用于上傳檔案
5、cookie和session的區別
cookie資料存放在客戶的瀏覽器上，session資料放在服務器上
cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙，考慮到安全應當使用session
session會在一定時間內保存在服務器上，當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面應當使用cookie
單個cookie保存的資料不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie
可以將登陸資訊等重要資訊存放為session；其他資訊需要保存，可以放在cookie
6、請求介面中常見的回傳狀態碼
答：
1xx – 資訊提示（表示臨時的回應，客戶端在收到常規回應之前，準備接收一個或多個1xx回應）
2xx – 成功（表明服務器成功地接受了客戶端請求）
3xx – 重定向（客戶端瀏覽器必須采取更多操作來實作請求，例如用戶未登錄就操作了修改的功能）
4xx – 客戶端錯誤(發送錯誤，客戶端有問題)
5xx – 服務器錯誤（服務器由于遇到錯誤而不能完成該請求）
常見的有:
200 OK：服務器成功回傳用戶請求的資料
201：用戶新建或修改資料成功
202：表示一個請求已經進入后臺排隊（異步任務）
301：洗掉請求資料
302：在其他地址發現了請求資料
303：建議客戶訪問其他URL或訪問方式
304：客戶端已經執行了GET，但檔案未變化
400 ：用戶發出的請求有錯誤，服務器沒有進行新建或修改資料的操作
401：表示用戶沒有權限（令牌、用戶名、密碼錯誤）
403 ：表示用戶得到授權（與401錯誤相對），但是訪問被禁止
404：用戶發出的請求針對得到是不存在的記錄，服務器沒有進行操作，該操作是冪等的
500：服務器發生錯誤，用戶將無法判斷發出的請求是否成功，
502：服務器回傳超時
7、介面測驗用例如何進行設計
針對輸入，可按照引數型別進行設計，引數是否必填，引數之間是否存在關聯，引數資料型別限制，引數資料型別自身的資料范圍值限制；
針對介面處理，可按照邏輯進行用例設計；
針對輸出，可根據結果進行分析設計，
8、如何分析是前端還是后端的問題
答：
檢查介面，前端和后臺之間是通過介面檔案相互聯系的，需要查看介面檔案
檢查請求的資料是什么，反饋的資料又是什么
頁面可以直接F12，或者抓包查看，如果發送的資料是正確的，但是后臺反饋的資料是不符合需求的，那就是后臺的問題；如果前端沒有請求介面或請求的時候發送資料與需求不符，那這個時候就是前端的問題了，
9、介面測驗中，下游介面需要依賴上游介面的資料，該如何處理？
答：在工具中可以使用全域變數等方式將需要的資料進行傳送，或者使用對回應資料進行提取，傳給下游介面，
10、依賴第三方資料的介面如何進行測驗？
答：可以使用fiddler進行呼叫介面時預設期望回應，mock回傳自己設定的回應資料，最大限度的降低對第三方資料介面的依賴
11、若請求的介面需要先登錄后方可請求，如何進行介面測驗？
答：請求登錄口獲取回傳的回應頭，或者回應資訊中的資料，cookie，token，session等，傳遞給依賴登錄介面的請求頭中，發起請求即可，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/231994.html
標籤：其他