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、沒有接口文檔，如果做接口測試？
本題主要考情商，通俗來說就是忽悠能力，先唬住面試官了再說，進去了也是瞎測測，隨時 做好背鍋的準備，當然，你肯定不能回答面試官不測
答：用抓包工具把接口抓取處理，然後針對性進行測試；接口中字段信息不清楚的，找時間
集中尋求開發解答。（常用抓包工具 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 等。
23、列出幾個 JMeter 監聽器？
一些 JMeter 監聽器是： 集合報告 彙總報告 查看結果樹 用表格查看結果 圖形結果 BeanShell Listener 摘要報告等
24、在 python 中進行數據驅動測試
在 unittest 中，沒有自帶的數據驅動，我們得藉助 ddt 來實現，首先，我們得在 python 運行環境中安裝 ddt，用下列命令安裝 pip install ddt 另 外 一 個 測 試 框 架 pytest ， 它 自 帶 數 據 驅 動 實 現 ， 是 通 過 @pytest.mark.parametrize(argnames,argvalues) 來實現參數化的。 也可以根據自己需求用 python 實現數據的讀取和驅動。
25、接口自動化中的關聯怎麼處理？
把上一個請求返回的結果傳入到下一個請求的參數中，將請求的結果反射到一個類屬性（使 用 setattr（）函數），下一個請求去調用這個類屬性
26、自動化測試怎麼校驗結果？
斷言 ，預期結果與實際結果對比
數據庫校驗，根據測試場景來查詢數據庫裏的數據和請求之前的數據進行比對 測碼學院
27、自動化使用的測試框架是什麼？
簡述自動化框架的設計、維護
測試框架：python+unittest+requests+ddt+openpyxl+pymysql+logging
python：入門簡單，語法簡潔
unittest ：定義一個測試用例類，具體的方法來維護測試用例的生命週期，測試場景行爲， 測試用例 前置場景，行爲，期望結果，實際結果，斷言方法，Setup teardown 方法
requests：接口調用 ，支持 http 請求的庫，API 簡潔，提供不同的 http 請求方法，支持 session，cookies，
ddt ：數據驅動，ddt 類裝飾器，data 測試方法裝飾器 unpack 解包可迭代的數據類型
普通用戶，數據庫，配置文件—（基礎數據）
openpyxl： 數據管理 excel 管理數據，使用 openpyxl 模塊來進行 excel 數據的讀和寫 （excle，csv, json, yaml, txt 都可以管理測試數據）
pymysql：數據庫交互，數據校驗
eval，json：數據格式的轉換 Eval 將 python 支持的格式轉換成對應的格式
logging：日誌處理， 統一日誌輸出格式，渠道，級別，執行結果的記錄，便於定位問題
jenkins：持續集成
2/框架設計思路：數據驅動+結構分層（可讀性，可維護性，可擴展性）
數據驅動：將維護數據與代碼分離，接口調用行爲一致，針對不同的參數組合驅動不同的測 試場景，減少代碼冗餘
結構分層：數據層+用例層+邏輯層
數據層：測試數據的支撐 data.xls
用例層：用例的執行 test_register.py test_recharge.py
邏輯層：公用的方法的封裝與提取 doexcle.py do_mysql.py http_requests.py logger.py 等模塊
3/框架設計步驟：
準備測試數據： EXCEL 表準備測試用例—excel 數據的讀取—參數值的替換 測碼學院
發起請求：請求方法（get/post 方法進行封裝—URL 的拼接（不同—參數轉化爲字典
拿到請求的返回值：解析返回值 code，status，msg 信息
斷言
好處：
1、自動化測試用例和手工測試用例的完美結合，減少重複工作
2、配置靈活，可以自主切換測試環境，執行測試用例
3、常用功能進行封裝，邏輯清晰，易於維護
4、統一執行入口，管理測試用例集：
run.py 模塊通過模糊查找來選擇需要執行的測試用例
5、持續集成，定時構建，快速反饋
28、具體的在這個項目中自動化怎麼應用到實際的，您對自動化結果的分析
完成所有的自動化測試框架的設計和實現後，進行接口測試，然後集成到
jenkins，配置定時執行，生成 html 報表，查看測試通過率，查看接口的功能
每次發版時，進行迴歸測試，新功能開發未提測前