本文為霍格沃茲測試學院學員學習筆記，進階學習文末加群。
本系列文章總結歸納了一些軟件測試工程師常見的面試題，主要來源於個人面試遇到的、網絡搜集（完善）、工作日常討論等，分為以下十個部分，供大家參考。如有錯誤的地方，歡迎指正。有更多的面試題或面試中遇到的坑，也歡迎補充分享。希望大家都能找到滿意的工作，共勉之！
- 測試常見問題與流程篇
- 測試工具篇
- 計算機網絡知識與數據庫篇
- Linux 篇
- Python 編程篇
- 自動化測試篇：包含 Selenium、Appium 和接口測試
- 性能測試篇
- 軟素質篇：10 大靈魂拷問
- 反問面試官篇
- 計算機網絡篇（基礎知識）
- 學習過 Java，C 等
- 半精通 Python
a. 輸入網址
b. DNS解析
c. 建立tcp連接
d. 客戶端發送HTTP請求
e. 服務器處理請求
f. 服務器響應請求
g. 瀏覽器展示HTML
h. 瀏覽器發送請求獲取其他在HTML中的資源。
- HTTPS 里面是要有證書的，HTTP 並沒有證書。證書的作用是證明你是這個網站的擁有者。誰去證明？最頂級的 CA 去幫你證明，這些頂級的 CA 都是瀏覽器、操作系統本身就自動幫你集成，而且自動添加到設置信任里面去；
- HTTPS 要兼顧安全+性能的方面，由於對稱式加密雖然速度很快，但是安全性特別的低，因為雙方要規定對稱式加密的秘鑰，別人都無法知道，但你怎么能確保別人不知道你的秘鑰呢，因此需要有非對稱式加密去保證安全，但非對稱式加密速度又很慢，如果客戶端和服務器端都用非對稱式加密，網絡得卡死了。所以當雙方建立好了非對稱加密后，再約定一個隨機數，等大家都非對稱解密了之后呢，就拿到只有對方知道的唯一隨機數（秘鑰），就可以用秘鑰來進行對稱式加密和解密了；
- HTTP請求報文：一個HTTP請求報文由請求行、請求頭部、空行和請求數據4個部分組成
- HTTP響應報文：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 由於臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以后恢復。
- cookies 數據保存在客戶端，session 數據保存在服務器端；
- cookies 可以減輕服務器壓力，但是不安全，容易進行 cookies 欺騙；
- session 較安全，但占用服務器資源
- TCP：面向連接，可靠的，速度慢，效率低
- UDP：無連接、不可靠、速度快、效率高
- 三次握手能保證數據可靠傳輸又能提高傳輸效率。若握手是兩次：如果只是兩次握手， 至多只有連接發起方的起始序列號能被確認，另一方選擇的序列號則得不到確認；
- 要保證雙方都關閉了連接。因為 TCP 是全雙工的，就是要等到兩邊都發送 fin 包確認雙方都沒有數據傳輸后才關閉；
- 為了保證可靠的斷開TCP的雙向連接，確保足夠的時間讓對方收到 ACK 包。若客戶端回復的 ACK 丟失，server 會在超時時間到來時，重傳最后一個 fin 包，處於 TIME_WAIT 狀態的 client 可以繼續回復 Fin 包，發送 ACK。
- 保證讓遲來的 TCP 報文段有足夠的時間被識別和丟棄，避免新舊連接混淆。有些路由器會緩存沒有收到的數據包，如果新的連接開啟，這些數據包可能就會和新的連接中的數據包混在一起。連接結束了，網絡中的延遲報文也應該被丟棄掉，以免影響立刻建立的新連接。
- 請求頭多了 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 上，所以不能用來傳遞敏感信息。
- 請求頭缺失或錯誤
- 參數 length 不符
- 以上為個人理解，有誤請指正。
- create table、create view、 select from where、insert into、update set values、delete、alter、order by、having
- 一組數據庫操作命令，當作是自己寫的一個方法，一系列步驟自己去封裝（個人理解）
SELECT a.name, b.score FROM student a, grade b WHERE a.id = b.id AND kemu = '數學' ORDER BY score DESC； 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； 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 - 開啟慢查詢日志，可以讓 MySQL 記錄下查詢超過指定時間的語句，通過定位分析性能的瓶頸，才能更好的優化數據庫系統的性能。
- 硬件環境問題，如磁盤IO
- 查詢語句問題，如join、子查詢、沒建索引
- 索引失效，建了索引，查詢的時候沒用上
- 查詢關聯了太多的join
- 服務器關聯緩存，線程數等
- 表中存在冗余字段，在生成笛卡爾積時耗費多余的時間
- 需要將數據緩存在內存中，提升查詢效率
- 這里希望大家補充
- Redis 的知識，了解的不是很多
- 拋磚引玉，請大家指正和補充。