雖然測試行業在2019不太景氣，面試後的一些面試題歸集和總結，爲了將來面試時使用。
所有的面試題中我發現超過90%都是基礎性的面試題，只要有自動化基礎，功能測試接觸，再加上面試的時候態度ok，且不卑不亢即可。
切記，面試時一定要不卑不亢，切記心浮氣躁和心虛，你懂得！
1、http與https有何區別？
答案：
①https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
②http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
③http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
④http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
2、tcp/ip三次握手
①含義理解
TCP/IP協議不僅僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇， 只是因爲在TCP/IP協議中TCP協議和IP協議最具代表性，所以被稱爲TCP/IP協議。
②三次握手：
1）客戶 端發送一個帶SYN標誌的TCP報文到server。這是三次握手過程中的報文1。
2） server端迴應client的，這是三次握手中的第2個報文。這個報文同一時候帶ACK標誌和SYN標誌。因此它表示對剛纔clientSYN報文的迴應。同一時候又標誌SYN給client，詢問client是否準備好進行數據通訊。
3） 客戶必須再次迴應服務段一個ACK報文，這是報文段3。
4）連接終止協議（四次握手）
3、悲觀鎖和樂觀鎖
悲觀鎖：
悲觀鎖原理是每次獲取數據的時候，都會擔心自己數據被修改，所以每次獲取數據的時候都會進行加鎖，確保在自己使用的過程中數據不會被別人修改，使用完成後再進行數據解鎖。由於數據進行加鎖，期間對該數據進行讀寫的其他線程都會進行等待。在Java中，synchronized的思想也是悲觀鎖。（如：同一個數據庫表A用戶在操作時B用戶不能進行操作）
適合寫入較頻繁場景，如出現大量的讀取操作，每次讀取都會進行加鎖，這樣會增加大量的鎖的開銷，降低了系統的吞吐量。
樂觀鎖：
適合讀取操作比較頻繁的場景，如果出現大量的寫入操作，數據發生衝突的可能性就會增大，爲了保證數據的一致性，應用層需要不斷的重新獲取數據，這樣會增加大量的查詢操作，降低了系統的吞吐量。
(如：A用戶操作一個表，B用戶同時操作這個表，樂觀鎖認爲不會衝突，但實際會造成衝突)
4、左連接、右連接和全連接
左連接：左邊有的，右邊沒有的爲null
右連接：左邊沒有的，右邊有的爲null
內連接：顯示左邊右邊共有的
5、數據庫中sum和count的區別以及使用
一般面試會把sum與order by 分組一起使用
count:統計你查詢出來的數據記錄條數：select count(*) from 學生表；
sum:求和：select sum(chengji) from 學生表 where name='張三'；
6、軟件測試方法有哪些？
黑盒、白盒、灰盒
7、jmeter中跟蹤重定向和自動重定向區別？
1）跟蹤重定向通俗的理解就是跟蹤請求執行的過程，並記錄一些信息給開發者看到，我們一般可以在結果日誌和監控中看到
2）自動重定向是不用跟蹤請求執行過程，也不用記錄
8、設計一個模塊測試用例
考察面試者的經驗、用例設計能力、思維、以及掌握的測試方法是否全面
從功能測試、接口測試、異常測試、性能、安全測試方面分析
9、自動化測試selenium 顯示等待和隱式等待
顯示等待就是有條件的等待，隱式等待就是無條件的等待
顯示等待：
設置等待時間
WebDriverWait(driver, 3, 0.5) #傳入三個參數，第一個是瀏覽器驅動，第二個是等待多少秒，第三個是每隔多少秒監控一次
原理：指定一個等待條件，和一個最長等待時間，程序會判斷在等待時間內條件是否滿足，如果滿足則返回，如果不滿足會繼續等待，超過時間就會拋出異常
隱式等待：
browser.implicitly_wait(10) #直接等待10秒鐘
當查找元素或元素並沒有立即出現的時候，隱式等待將等待一段時間再查找 DOM，默認的時間是0
10、pytest如何管理測試用例？
1）掌握案例規則，如以test開頭，類以Test命名等
2）案例文件執行單個py如何執行，多個文件夾的管理方式
11、cookie、token、session的區別
優先級
Cookie<session<token
安全性
Cookie:
①cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙，考慮到安全應當使用session；
②HTTP是一種無狀態協議,服務器沒有辦法單單從網絡連接上面知道訪問者的身份,爲了解決這個問題,就誕生了Cookie；
Cookie實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie，客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。
session:
①session會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能，考慮到減輕服務器性能方面，應當使用cookie；
②關閉瀏覽器不會關閉session，它具失效日期，失效後服務器認爲客戶端停止了活動，並刪除session以節省空間；
Token:
①作爲身份認證 token安全性比session好，因爲每個請求都有簽名還能防止監聽以及重放攻擊；
②Oauth token提供的是認證和授權，認證針對用戶，授權針對app；
③token的生成一般是採用uuid保證唯一性，當用戶登錄時爲其生成唯一的token，存儲一般保存在數據庫中。token過期時間採用把token二次保存在cookie或session裏面，根據cookie和session的過期時間去維護token的過期時間；
12、軟件測試結束的標準是什麼？
單元測試退出標準
1) 單元測試用例設計已經通過評審
2) 核心代碼100％ 經過Code Review
3) 單元測試功能覆蓋率達到100％
4) 單元測試代碼行覆蓋率不低於80％
5) 所有發現缺陷至少60％都納入缺陷追蹤系統且各級缺陷修復率達到標準
6) 不存在A、B類缺陷
7) C、D、E類缺陷允許存在
8) 按照單元測試用例完成了所有規定單元的測試
9) 軟件單元功能與設計一致
集成測試退出標準
1) 集成測試用例設計已經通過評審
2) 所有源代碼和可執行代碼已經建立受控基線，納入配置管理受控庫，不經過審批不能隨意更改
3) 按照集成構件計劃及增量集成策略完成了整個系統的集成測試
4) 達到了測試計劃中關於集成測試所規定的覆蓋率的要求
5) 集成工作版本滿足設計定義的各項功能、性能要求
6) 在集成測試中發現的錯誤已經得到修改，各級缺陷修復率達到標準
7) A、B類BUG不能存在
8) C、D類BUG允許存在,但不能超過單元測試總BUG的50％。
9) E類BUG允許存在
系統測試退出標準
1) 系統測試用例設計已經通過評審
2) 按照系統測試計劃完成了系統測試
3) 系統測試的功能覆蓋率達100％
4) 系統的功能和性能滿足產品需求規格說明書的要求
5) 在系統測試中發現的錯誤已經得到修改並且各級缺陷修復率達到標準
6) 系統測試後不存在A、B、C類缺陷
7) D類缺陷允許存在，不超過總缺陷的5％
8) E類缺陷允許存在，不超過總缺陷的10％
注：這只是一套比較理想化的退出標準，但在實際工作中不可能達到這種程度，尤其是測試覆蓋率和缺陷解決率不可能是100%。現在的軍方標準是達到99%。對於通用軟件來說就要根據公司實際情況了。
