接口測試最近幾年被炒的火熱了，越來越多的測試同行意識到接口測試的重要性。接口測試為什么會如此重要呢？ 主要是平常的功能點點點，大家水平都一樣，是個人都能點，面試時候如果問你平常在公司怎么測試的，你除了說點點點，還能說什么呢，無非就是這個項目點完了點那個項目， 這就是為什么各行各業(yè)的只要手指能點得動的人都來轉(zhuǎn)行軟件測試了。面試的時候面試官希望你除了點點點，還能更深入一點的思考頁面上看不到的功能，也就是接口測試了。接口是看不見的，但是可以訪問！
HTTP, HTTPS協(xié)議
- 什么是DNS
DNS是域名系統(tǒng)（Domain Name System），DNS是用來做域名解析的，它會在你上網(wǎng)輸入網(wǎng)址后，把它轉(zhuǎn)換成IP，然后去訪問對方服務器；沒有它，你想上百度就要記住百度的IP，但有了DNS的處理，你只需要記住對應網(wǎng)站的域名，即網(wǎng)址就可以了。
- HTTP協(xié)議
HTTP協(xié)議：超文本傳輸協(xié)議，是基于TCP的協(xié)議，默認為80端口。它的作用是用來規(guī)定客戶端和服務器的數(shù)據(jù)傳輸格式。是一種用于請求與響應模式的、無狀態(tài)、無連接 的應用層協(xié)議。 由于HTTP協(xié)議是一種請求-響應模式，所以一般需要關(guān)注HTTP請求和HTTP響應。
- 怎么抓取HTTPS協(xié)議
使用fiddler工具抓取HTTPS，體操作請查看文末領(lǐng)取教程
- 說出請求接口中常見的返回狀態(tài)碼
1xx -- 信息提示（表示臨時的響應?？蛻舳嗽谑盏匠Ｒ?guī)響應之前，準備接收一個或多個1xx響應）
2xx -- 成功（表明服務器成功地接受了客戶端請求）
3xx -- 重定向（客戶端瀏覽器必須采取更多操作來實現(xiàn)請求。例如，瀏覽器可能不得不請求服務器上的不同的頁面，或通過代理服務器重復該請求）
4xx -- 客戶端錯誤（發(fā)送錯誤，客戶端有問題。例如，客戶端請求不存在的頁面，客戶端未提供有效的身份證驗證信息）
5xx -- 服務器錯誤（服務器由于遇到錯誤而不能完成該請求）
常見的返回碼有：
200 OK - [GET]：服務器成功返回用戶請求的數(shù)據(jù)
201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數(shù)據(jù)成功
202 Aceepted - [*]：表示一個請求已經(jīng)進入后臺排隊（異步任務）
204 NO CONTENT - [DELETE]：用戶刪除數(shù)據(jù)成功
400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發(fā)出的請求有錯誤，服務器沒有進行新建或修改數(shù)據(jù)的操作
401 Unauthorized -[*] ：表示用戶沒有權(quán)限（令牌、用戶名、密碼錯誤）
403 Forbidden -[*] ：表示用戶得到授權(quán)（與401錯誤相對），但是訪問被禁止
404 NOT FOUND -[*]：用戶發(fā)出的請求針對得到是不存在的記錄，服務器沒有進行操作，該操作是冪等的
406 Not Acceptable - [GET]：用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當創(chuàng)建一個對象時，發(fā)生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]：服務器發(fā)生錯誤，用戶將無法判斷發(fā)出的請求是否成功。
- HTTP協(xié)議請求方式
HTTP協(xié)議常用的請求方式有如下幾種：
- HTTP和HTTPS協(xié)議區(qū)別
安全性 安全性低——明文傳輸、易受攻擊，無法確認雙方身份，也無法確保數(shù)據(jù)的完整性 安全性高——使用ssl加密傳輸協(xié)議，信息是密文，可以認證雙方的身份，防止信息被截取篡改
默認TCP端口 80端口 443端口
靈活度或技術(shù)門檻 簡單快速，使用很靈活 技術(shù)門檻：多數(shù)個人或私人網(wǎng)站難以支撐
速度 協(xié)議簡單，HTTP服務器的程序規(guī)模小，因而通信速度很快 加重服務端的負擔，需要資源來支撐，降低用戶的訪問速度
費用 沒有額外的費用 CA機構(gòu)頒發(fā)的證書都是需要年費的
- HTTP和HTTPS實現(xiàn)機有什么不同
HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設計了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進行加密，從而就誕生了HTTPS。簡單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，要比http協(xié)議安全。
- HTTPS和HTTP的區(qū)別主要如下：
1、https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比http協(xié)議安全。
- POST和GET的區(qū)別
POST和GET都是向服務器提交數(shù)據(jù)，并且都會從服務器獲取數(shù)據(jù)。
區(qū)別：
（1）傳送方式：get通過地址欄傳輸，post通過報文傳輸
（2）傳送長度：get參數(shù)有長度限制（受限于url長度），而post無限制
（3）GET產(chǎn)生一個TCP數(shù)據(jù)包（對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去，服務器響應200返回數(shù)據(jù)），POST產(chǎn)生兩個TCP數(shù)據(jù)包（對于POST，瀏覽器先發(fā)送header，服務器響應100 continue，瀏覽器再發(fā)送data，服務器響應200 ok返回數(shù)據(jù)）
（4）get請求參數(shù)會被完整保留在瀏覽歷史記錄里，而post中的參數(shù)不會被保留
（5）在做數(shù)據(jù)查詢時，建議用GET方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用post方式
- HTTP請求報文與響應報文格式
請求報文：一個HTTP請求報文由請求行（Request Line）、請求頭（Header）、空行(Blank Line)和請求體（Body）4個部分組成。
響應報文：HTTP響應報文和請求報文的結(jié)構(gòu)差不多，由狀態(tài)行、響應頭、空行、響應體4個部分組成。
- 什么是HTTP協(xié)議無狀態(tài)協(xié)議?怎么解決HTTP協(xié)議無狀態(tài)協(xié)議
是指協(xié)議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態(tài)。即我們給服務器發(fā)送 HTTP 請求之后，服務器根據(jù)請求，會給我們發(fā)送數(shù)據(jù)過來，但是，發(fā)送完，不會記錄任何信息。
解決方案:通過cookie和session來保持狀態(tài)。
- 常見的POST提交數(shù)據(jù)方式
請求body;請求url+請求body：
Content-type:
application/x-www-form-urlencoded: 表單提交--鍵值對， form
multipart/form-data：文件上傳---文件 ，MIME
application/json，text/xml
- HTTP協(xié)議學了哪幾個版本
http協(xié)議目前有4個版本(0.9,1.0,1.1,2.0)，其中1.0、1.1版本在互聯(lián)網(wǎng)上被廣泛使用，2.0版本目前應用很少，是下一代的http協(xié)議。
- Cookies和Session區(qū)別
1.存儲位置不同：Cookie 是將用戶數(shù)據(jù)通過加密的方式保存在客戶端，大多數(shù)情況 Cookie 存儲在瀏覽器；Session 是用于控制客戶端和服務端的連接，Session 存儲在服務器；
2.存儲容量不同：單個 Cookie 保存的數(shù)據(jù)不得超過 4kb，一個站點最多 20 個 Cookie，Session 一般情況下沒有上限，不過建議不要存放太多東西，否則影響性能；
3.存取方式不同：Cookie 只能用 ASCII 字符串，通過編碼方式獲取 Unicode 字符或者二進制數(shù)據(jù)，不好存儲復雜的信息，而 Session 能存儲任何類型的數(shù)據(jù)；
4.隱私策略/安全性不同：Cookie 放在客戶端，可以進行 Cookie 欺騙，所以不安全，Session 放在服務端，更加安全；
5.有效期不同：Cookie 可以設置屬性達到長期有效，Session 依賴于 JSESSIONID 的 Cookie，Cookie JSESSIONID 的過期時間默認為-1，只需要關(guān)閉窗口 Session 就會失效，就算不依賴 Cookie，用 UrL 重寫也不能完成，如果 Session 超時時間過長，容易導致內(nèi)存溢出；
6.服務器壓力不同：Cookie 保存在本地，不存在服務端壓力，Session 保存在服務端，每個用戶產(chǎn)生一個 Session，當訪問增多，會比較占用服務器的性能，如果主要考慮到減輕服務器性能方面，應當使用 Cookie；
7.瀏覽器支持不同：如果瀏覽器禁用 Cookie，那么 Cookie 直接失效，Session 比較好點，可以用 URL 重寫；
8.Cookie 和 Session 應用的場景：Cookie 一般用于記住用戶的登錄狀態(tài)，如記錄用戶的習慣，購物車；而 Session 用于登錄驗證。
- HTTPS在哪一層, 會話層在第幾層
https在應用層。
會話層為7層協(xié)議的第五層，為表示層提供建立、維護和結(jié)束會話連接的功能，并提供會話管理服務。
- 瀏覽器輸入url按回車背后經(jīng)歷了哪些？
在瀏覽器中輸入URL并回車后，主要發(fā)生以下步驟：
解析URL，獲取要訪問的域名
DNS域名解析，根據(jù)訪問的域名獲得目標服務器的IP地址
瀏覽器與服務端三次握手建立TCP連接
連接建立成功之后就可以發(fā)送HTTP請求報文以及服務器返回HTTP響應報文
斷開TCP鏈接
瀏覽器解析響應報文，渲染頁面
TCP, UDP協(xié)議
TCP/UDP協(xié)議的區(qū)別，TCP如何保證正確，微信基于什么協(xié)議，QQ基于什么協(xié)議，為什么？
你熟悉OSI協(xié)議嗎？原理是什么
接口用例設計
怎么設計接口測試用例？
HTTPS測試點
從HTTP變化到HTTPS協(xié)議，測試點
購物車模塊, 加入購物車接口測試點分析
http://...?orderId=,**, 接口設計用例
設計接口測試用例時，涉及的是電商系統(tǒng)，其中包括很多修改，如商品.商家、店鋪等等，針對這些數(shù)據(jù)的修改，會涉及到很多參數(shù)。如商品的名稱，商品的尺碼，商品的顔色等等。那在設計實現(xiàn)"修改"接口時，如何確定要傳什么參數(shù)？是只需要傳我要修改的參數(shù)，還是全部參數(shù)都要傳？
上傳文件測試點
根據(jù)以下界面設計測試用例
- 一個訂單的幾種狀態(tài)如何全部測到，如：未處理，處理中，處理失敗，處理成功
接口測試
為什么要做接口測試
你平常做接口測試的過程中發(fā)現(xiàn)過哪些BUG
平常你是怎么測試接口的
平常用什么工具測接口的
沒有接口文檔，如果做接口測試
接口測試的流程
常用什么接口測試工具, 說一個你在工作中具體怎么做接口測試的實例
不可逆的操作，如何處理，比如刪除一個訂單這種接口如何測試
接口產(chǎn)生的垃圾數(shù)據(jù)如何清理
測試的數(shù)據(jù)你放在哪
你們數(shù)字簽名怎么實現(xiàn)的
當一個接口出現(xiàn)異常時候，你是如何分析異常的
你們怎么做的參數(shù)化
如何進行數(shù)據(jù)清洗
如何進行數(shù)據(jù)檢驗
response怎么驗證, 參數(shù)特別多
做接口測試如何分析是前端還是后端的問題
在測試接口中怎么知道請求成功還是失敗
如何模擬弱網(wǎng)測試
異步接口怎么測試
接口的加密測試中對稱加密與非對稱加密有什么區(qū)別？如何開展測試？請詳解
請詳細闡述接口測試和UI測試在測試活動中是如何協(xié)同測試的？
目前接口文檔是由word格式管理，因迭代快，產(chǎn)生很多文襠，分不清哪些是不用的接口，哪些是正在用的接口，哪些是更新后的接口, 文襠雜亂.另外因是 word格式管理，不方便詢問，如何管理？每次查看接口文檔需要下載多個word,不能避免下載操作查看，效率不高，如何提高工作效率？
接口依賴
很多接口都需要登錄怎么處理？
依賴于登錄的接口如何處理 -token 和 session的管理
在手工接口測試或自動化接口測試的過程中，上下游接口有數(shù)據(jù)依賴如何處理？
依賴于第三方數(shù)據(jù)的接口如何進行測試
接口測試中依賴登錄狀態(tài)的接口如何測試
如果兩個請求有嚴格的先后順序，需要測試調(diào)轉(zhuǎn)順序的情況
下個接口請求參數(shù)依賴上個接口的返回數(shù)據(jù)
Web Service
HTTP接口測試和Web Service接口測試區(qū)別是什么？
Web Service接口是如何測試的
接口框架
接口測試框架怎么搭建的？
你有沒有做過框架穩(wěn)定性優(yōu)化相關(guān)的工作？
持續(xù)集成怎么做的？
Mock
Mock怎么使用
你們Mock是怎么做的
RPC
rpc接口怎么測試
什么是RPC接口，用Http設計一個RPC接口
你有沒有自己實現(xiàn)過rpc框架
性能
JMeter怎么存儲變量, 讓下一個接口使用
如何進行接口壓測
JMeter執(zhí)行10次
JMeter獲取上一個request的結(jié)果
JMeter完成一個用例
做接口測試當請求參數(shù)多時tps下降明顯，此接口根據(jù)參數(shù)從redis中獲取數(shù)據(jù)，每個參數(shù)與redfs交互一次，當一組參數(shù)是tps5133,五組參數(shù)是tps1l69,多次交互影響了處理性能，請詳細描述如何改進增進效果的方案
高能部分
TCP報頭格式
UDP報頭格式
TCP/UDP區(qū)別（不僅是宏觀上的，最好能根據(jù)各自的機制講解清楚）
HTTP狀態(tài)碼（最好結(jié)合使用場景，比如在緩存命中時使用哪個）
HTTP協(xié)議（一些報頭字段的作用，如cace-control、keep-alive）
OSI協(xié)議、TCP/IP協(xié)議以及每層對應的協(xié)議
Session機制、Cookie機制
TCP三次握手、四次揮手（這個問題真的要回答吐了，不過真的是面試官最喜歡問的，建議每天手擼一遍，而且不只是每次請求的過程，各種FIN_WAIT、TIME_WAIT狀態(tài)也要掌握）。
打開網(wǎng)頁到頁面顯示之間的過程（涵蓋了各個方面，DNS解析過程，Nginx請求轉(zhuǎn)發(fā)、連接建立和保持過程、瀏覽器內(nèi)容渲染過程，考慮的越詳細越好）。
http和https區(qū)別，https在請求時額外的過程，https是如何保證數(shù)據(jù)安全的
IP地址子網(wǎng)劃分
POST和GET區(qū)別
DNS解析過程
TCP如何保證數(shù)據(jù)的可靠傳輸?shù)模ㄟ@個問題可以引申出很多子問題，擁塞控制慢開始、擁塞避免、快重傳、滑動窗口協(xié)議、停止等待協(xié)議、超時重傳機制，最好都能掌握）
地址解析協(xié)議ARP
交換機和路由器的區(qū)別
HTTP2.0、thrift
API接口與SDI接口的區(qū)別（API是提供給別人的接口）
dubbo如何一條鏈接并發(fā)多個調(diào)用。Dubbo的原理，序列化相關(guān)問題
你怎么理解http協(xié)議
說說http協(xié)議的工作流程
http有哪些請求提交方式
http中的200,302,403,404,500,503都代表什么狀態(tài)
什么是web緩存？有什么優(yōu)點
你怎么理解cookie和session，有哪些不同點
什么是https，說說https的工作原理
什么是http代理服務器，有什么用
什么是分布式系統(tǒng)
分布式系統(tǒng)你會考慮哪些方面
講講CAP理念
怎么理解強一致性、單調(diào)一致性和最終一致性
分布式系統(tǒng)設計你會考慮哪些策略
講一講TCP協(xié)議的三次握手和四次揮手流程
講一講TCP協(xié)議的三次握手和四次揮手流程
為什么TCP建立連接協(xié)議是三次握手，而關(guān)閉連接卻是四次握手呢？為什么不能用兩次握手進行連接
為什么TCP TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)
什么是DoS、DDoS、DRDoS攻擊？如何防御
為什么說TCP/IP協(xié)議是不可靠的
OSI有哪七層模型？TCP/IP是哪四層模型
關(guān)于這些知識點的掌握肯定是需要自己多花時間和精力的
建議大家看教程沒有過多廢話，書籍太枯燥主要還是接口自動化使用技巧實踐
重要，作者的裙里有大佬的講解非常詳細，能夠幫助你快速理解與掌握?；貧w主頁查看進裙方式~
