本文為霍格沃茲測試學院學員學習筆記，進階學習文末加群。

本系列文章總結歸納了一些軟體測試工程師常見的面試題，主要來源於個人面試遇到的、網路蒐集（完善）、工作日常討論等，分為以下十個部分，供大家參考。如有錯誤的地方，歡迎指正。有更多的面試題或面試中遇到的坑，也歡迎補充分享。希望大家都能找到滿意的工作，共勉之！

軟體測試工程師面試題系列篇 | 目錄

1. 測試常見問題與流程篇
2. 測試工具篇
3. 計算機網路知識與資料庫篇
4. Linux 篇
5. Python 程式設計篇
6. 自動化測試篇：包含 Selenium、Appium 和介面測試
7. 效能測試篇
8. 軟素質篇：10 大靈魂拷問
9. 反問面試官篇
10. 計算機網路篇（基礎知識）

1.擅長哪些開發語言？

• 學習過 Java，C 等
• 半精通 Python

2.輸入 URL 到網頁顯示出來的全過程

a. 輸入網址
b. DNS解析
c. 建立tcp連線
d. 客戶端傳送HTTP請求
e. 伺服器處理請求
f. 伺服器響應請求
g. 瀏覽器展示HTML
h. 瀏覽器傳送請求獲取其他在HTML中的資源。

3.HTTP 和 HTTPS 的區別

• HTTPS 裡面是要有證書的，HTTP 並沒有證書。證書的作用是證明你是這個網站的擁有者。誰去證明？最頂級的 CA 去幫你證明，這些頂級的 CA 都是瀏覽器、作業系統本身就自動幫你整合，而且自動新增到設定信任裡面去；
• HTTPS 要兼顧安全+效能的方面，由於對稱式加密雖然速度很快，但是安全性特別的低，因為雙方要規定對稱式加密的祕鑰，別人都無法知道，但你怎麼能確保別人不知道你的祕鑰呢，因此需要有非對稱式加密去保證安全，但非對稱式加密速度又很慢，如果客戶端和伺服器端都用非對稱式加密，網路得卡死了。所以當雙方建立好了非對稱加密後，再約定一個隨機數，等大家都非對稱解密了之後呢，就拿到只有對方知道的唯一隨機數（祕鑰），就可以用祕鑰來進行對稱式加密和解密了；

4.HTTP 的報文結構

• HTTP請求報文：一個HTTP請求報文由請求行、請求頭部、空行和請求資料4個部分組成
• HTTP響應報文：HTTP響應也由三個部分組成，分別是：狀態行、訊息報頭、響應正文

5.HTTP 常見的響應狀態碼

• 200 請求已成功，請求所希望的響應頭或資料體將隨此響應返回。
• 201 請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 - - URI 已經隨 Location 頭資訊返回
• 202 伺服器已接受請求，但尚未處理
• 301 （永久移動） 請求的網頁已永久移動到新位置。伺服器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
• 302 （臨時移動） 伺服器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。
• 303 （檢視其他位置） 請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，伺服器返回此程式碼。
• 304 （未修改） 自從上次請求後，請求的網頁未修改過。伺服器返回此響應時，不會返回網頁內容。
• 305 （使用代理） 請求者只能使用代理訪問請求的網頁。如果伺服器返回此響應，還表示請求者應使用代理。
• 307 （臨時重定向） 伺服器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。
• 401 當前請求需要使用者驗證。如果當前請求已經包含了 Authorization 證書，那麼
• 401 響應代表著伺服器驗證已經拒絕了那些證書
• 403 伺服器已經理解請求，但是拒絕執行它。與 401 響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重複提交
• 404 請求失敗，請求所希望得到的資源未被在伺服器上發現
• 500 伺服器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在伺服器的程式碼出錯時出現。
• 501 伺服器不支援當前請求所需要的某個功能。當伺服器無法識別請求的方法，並且無法支援其對任何資源的請求。
• 502 作為閘道器或者代理工作的伺服器嘗試執行請求時，從上游伺服器接收到無效的響應。
• 503 由於臨時的伺服器維護或者過載，伺服器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以後恢復。

6.cookie 和 session 機制的區別

• cookies 資料儲存在客戶端，session 資料儲存在伺服器端；
• cookies 可以減輕伺服器壓力，但是不安全，容易進行 cookies 欺騙；
• session 較安全，但佔用伺服器資源

7.TCP 和 UDP 的區別

• TCP：面向連線，可靠的，速度慢，效率低
• UDP：無連線、不可靠、速度快、效率高

8.TCP 為什麼是三次握手和四次揮手

• 三次握手能保證資料可靠傳輸又能提高傳輸效率。若握手是兩次：如果只是兩次握手， 至多隻有連線發起方的起始序列號能被確認，另一方選擇的序列號則得不到確認；
• 要保證雙方都關閉了連線。因為 TCP 是全雙工的，就是要等到兩邊都發送 fin 包確認雙方都沒有資料傳輸後才關閉；

9.TCP為什麼最後揮手後會有time_wait

• 為了保證可靠的斷開TCP的雙向連線，確保足夠的時間讓對方收到 ACK 包。若客戶端回覆的 ACK 丟失，server 會在超時時間到來時，重傳最後一個 fin 包，處於 TIME_WAIT 狀態的 client 可以繼續回覆 Fin 包，傳送 ACK。
• 保證讓遲來的 TCP 報文段有足夠的時間被識別和丟棄，避免新舊連線混淆。有些路由器會快取沒有收到的資料包，如果新的連線開啟，這些資料包可能就會和新的連線中的資料包混在一起。連線結束了，網路中的延遲報文也應該被丟棄掉，以免影響立刻建立的新連線。

10.簡要說明 HTTP 請求中的 Post 和 Get 有哪些區別的地方

• 請求頭多了 content-length 和 content-type 欄位
• Post 可以附加 body，可以支援 form、json、xml、binary 等各種資料格式
• 行業通用規範
• 無狀態變化的建議使用 Get
• 資料的寫入與狀態的修改建議使用 Post
• 基於 HTTP 協議：都是請求返回資料，Get 將請求體放在頭上，只發一次請求，Post 將請求體放在內部，需要傳送兩次請求
• GET 在瀏覽器回退時是無害的，而 POST 會再次提交請求。
• GET 請求會被瀏覽器主動 cache，而 POST 不會，除非手動設定。
• GET 請求只能進行 URL 編碼，而 POST 支援多種編碼方式。
• GET 請求在 URL 中傳送的引數是有長度限制的，而 POST 麼有。
• 對引數的資料型別，GET 只接受 ASCII 字元，而 POST 沒有限制。
• GET 比 POST 更不安全，因為引數直接暴露在 URL 上，所以不能用來傳遞敏感資訊。

11.如果一個請求，返回的狀態碼是 200，但是沒有內容，可能發生了什麼？

• 請求頭缺失或錯誤
• 引數 length 不符
• 以上為個人理解，有誤請指正。

資料庫篇

1. 工作中常使用的 SQL 語法有哪些？

• create table、create view、 select from where、insert into、update set values、delete、alter、order by、having

2.資料庫儲存過程

• 一組資料庫操作命令，當作是自己寫的一個方法，一系列步驟自己去封裝（個人理解）

3.SQL 常見查詢語句編寫（此處僅舉例常見的查詢語句，如有更多坑，希望補充）

a.查詢所有學生的數學成績，顯示學生姓名 name, 分數， 由高到低。

SELECT a.name, b.score FROM student a, grade b WHERE a.id = b.id AND kemu = '數學' ORDER BY score DESC；

b.統計每個學生的總成績（由於學生可能有重複名字）,顯示欄位：學生 id，姓名，總成績。

SELECT a.id, a.name, c.sum_score from student a, (SELECT b.id, sum(b.score) as sum_score FROM grade b GROUP BY id) c WHERE a.id = c.id ORDER BY sum_score DESC；

c.列出各門課程成績最好的學生， 要求顯示欄位: 學號，姓名,科目，成績

SELECT c.id , a.name, c.kemu, c.score FROM grade c, student a,(SELECT b.kemu, MAX(b.score) as max_score FROM grade b GROUP BY kemu) t WHERE c.kemu = t.kemu AND c.score = t.max_score AND a.id = c.id

4.慢查詢是什麼意思？

• 開啟慢查詢日誌，可以讓 MySQL 記錄下查詢超過指定時間的語句，通過定位分析效能的瓶頸，才能更好的優化資料庫系統的效能。

5.導致資料庫效能差的可能原因有哪些？

• 硬體環境問題，如磁碟IO
• 查詢語句問題，如join、子查詢、沒建索引
• 索引失效，建了索引，查詢的時候沒用上
• 查詢關聯了太多的join
• 伺服器關聯快取，執行緒數等
• 表中存在冗餘欄位，在生成笛卡爾積時耗費多餘的時間

6.Redis 快取應用場景

• 需要將資料快取在記憶體中，提升查詢效率
• 這裡希望大家補充

7.怎麼定位 Redis 快取失效問題（快取壞了）

• Redis 的知識，瞭解的不是很多
• 拋磚引玉，請大家指正和補充。

更多內容，我們在後續文章分享。

免費領取：介面測試+效能測試+自動化測試+測試開發+測試用例+簡歷模板+測試文件