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