就是指程序中具體負(fù)責(zé)在不同模塊之間傳輸或接受數(shù)據(jù)的并做處理的類或者函數(shù)。2、HTTP和HTTPS協(xié)議區(qū)別？https協(xié)議需要到CA（Certificate Authority，證書頒發(fā)機構(gòu)）申請證書，一般免費證書較少，因而需要一定費用；http是超文本傳輸協(xié)議，信息是明文傳輸，Https協(xié)議是由SSL+Http協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全；http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443；以前我面試很喜歡提網(wǎng)絡(luò)協(xié)議的問題，有朋友說我裝X，不實用。稍有點研究網(wǎng)絡(luò)知識，實際就不難回答答：POST和GET都是向服務(wù)器提交數(shù)據(jù)，并且都會從服務(wù)器獲取數(shù)據(jù)。1）傳送方式：get通過地址欄傳輸，post通過報文傳輸2）傳送長度：get參數(shù)有長度限制（受限于url長度），而post無限制3）GET產(chǎn)生一個TCP數(shù)據(jù)包（對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200返回數(shù)據(jù)），POST產(chǎn)生兩個TCP數(shù)據(jù)包（對于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok返回數(shù)據(jù)）4）get請求參數(shù)會被完整保留在瀏覽歷史記錄里，而post中的參數(shù)不會被保留5）在做數(shù)據(jù)查詢時，建議用GET方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用post方式主要有四種方式：application/x-www-form-urlencoded、multipart/form-data、application/json、text/xml等。6、什么是Http協(xié)議無狀態(tài)協(xié)議?怎么解決HTTP協(xié)議無狀態(tài)協(xié)議無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。即我們給服務(wù)器發(fā)送 HTTP 請求之后，服務(wù)器根據(jù)請求，會給我們發(fā)送數(shù)據(jù)過來，但是，發(fā)送完，不會記錄任何信息。HTTP 是一個無狀態(tài)協(xié)議，這意味著每個請求都是獨立的，Keep-Alive 沒能改變這個結(jié)果。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。HTTP 協(xié)議這種特性有優(yōu)點也有缺點，優(yōu)點在于解放了服務(wù)器，每一次請求“點到為止”不會造成不必要連接占用，缺點在于每次請求會傳輸大量重復(fù)的內(nèi)容信息?？蛻舳伺c服務(wù)器進(jìn)行動態(tài)交互的 Web 應(yīng)用程序出現(xiàn)之后，HTTP 無狀態(tài)的特性嚴(yán)重阻礙了這些應(yīng)用程序的實現(xiàn)，畢竟交互是需要承前啟后的，簡單的購物車程序也要知道用戶到底在之前選擇了什么商品。于是，兩種用于保持 HTTP 連接狀態(tài)的技術(shù)就應(yīng)運而生了，一個是 Cookie，而另一個則是 Session。cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上
cookie不是很安全，別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙，考慮到安全應(yīng)當(dāng)使用session
session會在一定時間內(nèi)保存在服務(wù)器上。
當(dāng)訪問增多，會比較占用你服務(wù)器的性能，考慮到減輕服務(wù)器性能方面應(yīng)當(dāng)使用cookie
單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie
可以將登陸信息等重要信息存放為session；
其他信息需要保存，可以放在cookie
1xx -- 信息提示（表示臨時的響應(yīng)。客戶端在收到常規(guī)響應(yīng)之前，準(zhǔn)備接收一個或多個1xx響應(yīng)）2xx -- 成功（表明服務(wù)器成功地接受了客戶端請求）3xx -- 重定向（客戶端瀏覽器必須采取更多操作來實現(xiàn)請求。例如，瀏覽器可能不得不請求服務(wù)器上的不同的頁面，或通過代理服務(wù)器重復(fù)該請求）4xx -- 客戶端錯誤（發(fā)送錯誤，客戶端有問題。例如，客戶端請求不存在的頁面，客戶端未提供有效的身份證驗證信息）5xx -- 服務(wù)器錯誤（服務(wù)器由于遇到錯誤而不能完成該請求）200 OK - [GET]：
服務(wù)器成功返回用戶請求的數(shù)據(jù)
201 CREATED - [POST/PUT/PATCH]：
用戶新建或修改數(shù)據(jù)成功
202 Aceepted - [*]：
表示一個請求已經(jīng)進(jìn)入后臺排隊（異步任務(wù)）
204 NO CONTENT - [DELETE]：
用戶刪除數(shù)據(jù)成功
400 INVALID REQUEST - [POST/PUT/PATCH]：
用戶發(fā)出的請求有錯誤，服務(wù)器沒有進(jìn)行新建或修改數(shù)據(jù)的操作
401 Unauthorized -[*] ：
表示用戶沒有權(quán)限（令牌、用戶名、密碼錯誤）
403 Forbidden -[*] ：
表示用戶得到授權(quán)（與401錯誤相對），但是訪問被禁止
404 NOT FOUND -[*]：
用戶發(fā)出的請求針對得到是不存在的記錄，服務(wù)器沒有進(jìn)行操作，該操作是冪等的
406 Not Acceptable - [GET]：
用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）
500 INTERNAL SERVER ERROR - [*]：
服務(wù)器發(fā)生錯誤，用戶將無法判斷發(fā)出的請求是否成功
DNS 是域名系統(tǒng) (Domain Name System)，DNS是用來做域名解析的,它會在你上網(wǎng)輸入網(wǎng)址后，把它轉(zhuǎn)換成IP，然后去訪問對方服務(wù)器；沒有它，你想上百度就要記住百度的IP，但有了DNS的處理，你只需要記住對應(yīng)網(wǎng)站的域名，即網(wǎng)址就可以了。（下面是關(guān)于實際測試中的問題，適當(dāng)休息下再繼續(xù)）接口測試實際跟一般測試不同就是測試用例的設(shè)計部分。②設(shè)計接口測試功能用例（主要從用戶角度出發(fā)看接口能否實現(xiàn)業(yè)務(wù)需求，用例設(shè)計就是黑盒用例那一套）。③各種入?yún)Ⅱ炞C（正常情況，異常情況包括輸入?yún)?shù)個數(shù)不對，類型不對，可選/必選，還有考慮參數(shù)有互斥或關(guān)聯(lián)的情況）。⑤了解接口實現(xiàn)邏輯，實現(xiàn)邏輯覆蓋（語句/條件/分支/判定/…）⑥接口能并發(fā)執(zhí)行嗎、安全嗎，性能滿足要求嗎?⑧發(fā)現(xiàn)問題跟功能測試一樣，該報bug報bug，該跟蹤狀態(tài)的跟蹤狀態(tài)。通常，設(shè)計接口測試用例需要考慮以下幾個方面：有些接口需要滿足前提，才可成功獲取數(shù)據(jù)。常見的，需要登錄Token逆向用例：針對是否滿足前置條件（假設(shè)為n個條件），設(shè)計0~n條用例正向用例：帶默認(rèn)值的參數(shù)都不填寫、不傳參，必填參數(shù)都填寫正確且存在的“常規(guī)”值，其他不填寫，設(shè)計1條用例這里根據(jù)時間情況，結(jié)合接口參數(shù)說明，可能需要設(shè)計N條正向用例和逆向用例逆向用例：針對每個必填參數(shù)，都設(shè)計1條參數(shù)值為空的逆向用例⑤參數(shù)之間是否存在關(guān)聯(lián)有些參數(shù)彼此之間存在相互制約的關(guān)系逆向用例：針對每個參數(shù)都設(shè)計1條參數(shù)值類型不符的逆向用例⑦參數(shù)數(shù)據(jù)類型自身的數(shù)據(jù)范圍值限制正向用例：針對所有參數(shù)，設(shè)計1條每個參數(shù)的參數(shù)值在數(shù)據(jù)范圍內(nèi)為最大值的正向用例根據(jù)約定的協(xié)議、方法、格式內(nèi)容，傳輸數(shù)據(jù)到接口經(jīng)處理后返回期望的結(jié)果：輸入異常值（空值、特殊字符、超過約定長度等），接口能正確處理，且按預(yù)期響應(yīng)；
輸入錯誤的參數(shù)，接口能正確處理，并按預(yù)期響應(yīng)；
多輸入、少輸入?yún)?shù)，接口能正確處理，且按預(yù)期響應(yīng)；
錯誤傳輸數(shù)據(jù)格式（如json格式寫成form格式）測試；
③安全性測試，主要指傳輸數(shù)據(jù)的安全性：敏感數(shù)據(jù)（如密碼、秘鑰）等是否加密傳輸；
返回數(shù)據(jù)是否含有敏感數(shù)據(jù)，如用戶密碼、完整的用戶銀行賬號信息等；
接口是否對傳入的數(shù)據(jù)做安全校驗，如身份ID加token類似校驗；
接口是否防止惡意請求（如大量偽造請求接口致使服務(wù)器崩潰）；
④性能測試，如接口的響應(yīng)時間、并發(fā)處理能力、壓測處理情況：并發(fā)請求相同的接口（特別為POST請求），接口的處理情況（如插入了相同的記錄導(dǎo)致數(shù)據(jù)出錯，引發(fā)系統(tǒng)故障）；
接口響應(yīng)時長在用戶可忍受的范圍內(nèi)；
對于請求量大的接口做壓測，確定最大的瓶頸點是否滿足當(dāng)前業(yè)務(wù)需要；
答：常用http協(xié)議接口測試工具，如：postman、fiddler、jmeter；webService接口用SoapUI、jmeter等。本題主要考情商，通俗來說就是忽悠能力，先唬住面試官了再說，進(jìn)去了也是瞎測測，隨時做好背鍋的準(zhǔn)備，當(dāng)然，你肯定不能回答面試官不測(心理mmp，臉上笑嘻嘻)，接下來就是扯犢子時間答：用抓包工具把接口抓取處理，然后針對性進(jìn)行測試；接口中字段信息不清楚的，找時間集中尋求開發(fā)解答。（常用抓包工具Fiddler、Charles等）15、在手工接口測試或者自動化接口測試的過程中，上下游接口有數(shù)據(jù)依賴如何處理？答：用一個全局變量來處理依賴的數(shù)據(jù)，比如登錄后返回token，其它接口都需要這個token，那就用全局變量來傳token參數(shù)。16、依賴于第三方數(shù)據(jù)的接口如何進(jìn)行測試？接著面試官會問你，如果mock的，然后你就順著坑繼續(xù)挖，搭建mock服務(wù)，參考這篇http://www.51ste.com/share/det-485.html17、接口測試中，依賴登錄狀態(tài)的接口如何測試？答：依賴登錄狀態(tài)的接口的本質(zhì)上是在每次發(fā)送請求時需要帶上session或者cookie才能發(fā)送成功，在構(gòu)建POST請求時添加必要的session或者cookie19、你平常做接口測試的過程中發(fā)現(xiàn)過哪些bug?面試官出這個題，主要是想知道你是不是真的做過接口測試，畢竟現(xiàn)在很多小伙伴簡歷經(jīng)過包裝（不包裝連面試機會都沒有，沒辦法，為了生存）常規(guī)錯誤，接口沒實現(xiàn)，沒按約定返回結(jié)果，邊界值處理出錯等。輸入異常值（空值、特殊字符、超過約定長度等），接口拋錯，沒做封裝處理；輸入錯誤的參數(shù)、多輸入、少輸入?yún)?shù)，接口可能出現(xiàn)的錯誤；安全性問題，如明文傳輸、返回結(jié)果含有敏感信息，沒對用戶身份信息做校驗，沒做惡意請求攔截等；性能問題，如接口并發(fā)插入多條相同操作，響應(yīng)時間過長，接口壓測出現(xiàn)瓶頸等；20、當(dāng)一個接口出現(xiàn)異常時候，你是如何分析異常的？先抓包，用fiddler（charles）工具抓包，或者瀏覽器上F12調(diào)試工具；APP上的話，那就用Fiddler做代理，通過手機設(shè)置代理去看請求和返回報文；查看后端日志，如Linux系統(tǒng)通過xhell連上服務(wù)器，查看接口日志，查看是否有報錯信息（命令：tail -f 日志文件）；平常提bug的時候，前端開發(fā)和后端開發(fā)總是扯皮，不承認(rèn)是對方的bug。這種情況很容易判斷，先抓包看請求報文，對著接口文檔，看請求報文有沒問題，有問題就是前端發(fā)的數(shù)據(jù)不對；請求報文沒問題，那就看返回報文，返回的數(shù)據(jù)不對，那就是后端開發(fā)的問題咯。答：現(xiàn)在針對大量應(yīng)用，普遍推崇做接口測試自動化，維護(hù)成本低、收益高。常用的工具有許多，如Jmeter、Robot Framework、pytest等。
文末寄語： 人生不如意之事十有八九。常想一二，不思八九，事事如意。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點擊舉報。
