轉眼2021年招聘季已将到來，沒點真本事真技術，沒點面試經驗，不了解點職場套路，如何過五關斬六将？如何打敗面試官？如何拿下那夢寐以求的offer？
如果你的跳槽意向已經很确定，那麼請往下看！
跳槽最重要的一步自然是面試，馬上跳槽季，網上出現了各種面試題，一時會讓人眼花缭亂，分不清最該看哪個，是以小編整理出以下資料僅供大家參考。
Linux作業系統
java
c#
c++
python
shell
SQL語句也是必須的
01、什麼是bug？
答：軟體的bug指的是軟體當中不符合使用者需求的問題。
常見的軟體bug分為以下三類：
沒有實作的功能
完成了使用者需求的功能，但是運作時會出現一些功能或性能上的問題
實作了使用者不需求的多餘功能
02、簡單概述缺陷報告，并說明包括哪些項？
答：現在缺陷報告一般不再使用紙質檔文檔編寫，而是專用測試管理工具（如TestDirector），這樣便于缺陷管理。在這些工具中，每個缺陷作為一條記錄輸入指定的缺陷管理系統中。
缺陷報告包括：軟體名稱、版本号、功能模闆、缺陷編号、對應的用例編号、編寫時間、編寫人、測試員、預期結果、實際結果、缺陷描述、嚴重級别、優先級别
03、開發人員修複缺陷後，如何保證不影響其他功能？
答：重新執行用例、看是否出現錯誤結果。并對周圍的一些相關功能點追加新的測試用例。
04、什麼時候功能測試？
答：功能測試是在規定的一段時間内運作軟體系統的所有功能，以驗證這個軟體系統有無嚴重錯誤。
05、請問功能測試和性能測試的差別是什麼？
測試目的 檢測實際軟體的功能是否符合使用者需求，測功能是不是全部實作，某個實作是不是有BUG。 驗證軟體品質的三個品質特性，可靠性，正确性和效率。主要是測試産品的健壯性
測試方式 功能測試按照系用例，按照系統需求說明書和測試用例，對産品的功能一步步進行測試。找出産品功能是否全部實作 一般都使用性能工具對産品的健壯性進行評估。通過建立場景和虛拟使用者模拟真實環境，進行壓力測試和負載測試。
06、為什麼選擇測試這行？
答：它是一個新興的行業，有發展潛力，而且很鍛煉人，需要掌握更多的技能，比做開發要更全面。
Q1：項目中相關需求問題，測試可以直接和客戶溝通嗎？
A1：可以，最初與客戶溝通需求時，測試人員直接參與，是以我們可以直接和客戶方的代表開會進行溝通。
A2：不可以，我們的需求是産品線提的，産品線與客戶直接溝通，是以關于需求問題我們直接找産品線。
Q2：需求确定中不确定的需求怎麼解決？
A2：一般情況下先由項目組内讨論解決，如果依舊得不到解決，則直接與需求方确認。
Q3：什麼是測試方案，什麼是測試政策？
A3：測試方案是指導我們怎麼測的問題，裡面的主要内容是測試點。政策是指導我們要測什麼方面，比如要進行功能測試，性能測試，相容性測試等等，并指出需要依賴與什麼工具。
Q4：測試方案包含哪些内容？
A4：業務功能的描述，對需求功能的了解，業務流程圖，業務表，測試點等。
Q5：測試用例設計方法有哪些？
A5：等價類、邊界值、錯誤推測法、場景法、因果圖、判定表。
Q6：測試用例内容有哪些？
A6：ID 、标題、 優先級、 預置條件 、操作步驟 、預期結果、 實際結果、測試人、測試時間。
Q7：測試用例為什麼需要有優先級，有哪一些優先級？
A7：因為在不同階段執行的用例數目是不同的，用例對應的功能的重要程度也是不同的，我們用的是高中低三級。
Q8：你們項目一共有多少條測試用例？
A8：500-------到2000，具體項目具體分析，和項目大小顆粒度大小都有關系。
Q9：測試用例需要哪些人來評審？
A9：測試組内評審的，因為我們的方案是全體項目組成員(PM/SE開發和測試)來評審的并且方案裡的測試點寫到了測試用例标題的程度。我們是項目組全體來評審的額，畢竟測試是保證軟體品質的最後一個環節，測試用例是測試執行的依據，是以測試用例十分重要，項目組非常重視測試用例的評審，希望把漏測的降到最低，是以我們的測試用例是項目組全體成員來評審的。
Q10：一個項目需要寫多少測試用例怎麼估算？
A10：這個在需求分析之後根據測試點來評估的，我們的測試點寫的很細，是以測試用例的數目幾乎等于測試點的數目。
Q11：不能發現BUG的測試用例不是好的測試用例嗎？
A11：我不這樣認為，我覺得在執行之前，每個用例都可能發現缺陷，好的測試用例是一套完整的不遺漏的測試用例，是能夠被其他的測試人員執行的測試用例。不能因為是否找到BUG來說明用例是否好。
Q12：為什麼要進行交叉測試？
A12：因為自己執行自己設計的用例，會按照設計用例的思路來執行用例，可能會忽略一些偶然或異常的情況，交叉執行可能會發現新的BUG，當然如果用例已經寫得很細，顆粒度很小嗎，輸入輸出寫得很全面交叉執行的結果都會差不多，無論誰來執行結果都是一樣的。
Q13：什麼叫預測試，預測試是怎麼進行的，預測試一般為多長時間？
A13：預測試就是開放剛剛開發完成，測試環境剛搭建起來，這時我們要對系統的各種功能能不能跑通，業務流程能不能完成進行測試，就是冒煙測試，這就是轉測試，我們轉測試大概需要一天的時間。
Q14：你的測試職業發展是什麼？
A14：測試經驗越多，測試能力越高。是以我的職業發展是需要時間積累的，一步步向着進階測試工程師奔去。而且我也有初步的職業規劃，前3年積累測試經驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務。
Q15：你認為測試人員需要具備哪些素質？
A15：做測試應該要有一定的協調能力，因為測試人員經常要與開發接觸處理一些問題，如果處理不好的話會引起一些沖突，這樣的話工作上就會不好做。還有測試人員要有一定的耐心，有的時候做測試很枯燥乏味。除了耐心，測試人員不能放過每一個可能的錯誤。
Q16：你為什麼能夠做測試這一行？
A16：雖然我的測試技術還不是很成熟，但是我覺得我還是可以勝任軟體測試這個工作的，因為做軟體測試不僅是要求技術好，還有有一定的溝通能力，耐心、細心等外在因素。綜合起來看我認為我是勝任這個工作的。
07、什麼是系統瓶頸？
系統瓶頸就是軟體在一定的并發量、通路量下無法達到使用者的需求。
比如說使用者需要在10s内完成一個通路，但是每一次都要12s才能完成，這個就是性能瓶頸，有可能是程式本身的問題，也有可能和作業系統、軟體相關。
08、沒有産品說明書和需求文檔地情況下能夠進行黑盒測試嗎？
可以。
這個情況下我們就要進行探索性測試，把軟體當成使用者需求，一步步進行測試。憑借經驗判斷功能正确與否，有的時候還可以與項目經理、開發人員一起進行交流溝通，進而進行更好的測試。
09、為什麼盡量不要讓時間富裕的員工去做一些測試？
首先，專業的測試人員是有一定的技能和耐心對軟體一步一步進行測試。如果讓時間充裕的員工去測試的話，他可能心思并不在測試上面。會很随意的、沒有目标的進行測試。這樣子的話測試并不完整，有的時候甚至很重要的bug都沒法找出。是以還是需要專業的測試人員來進行測試的。
10、完全測試程式是可能的嗎？
不可能！測試人員對程式進行測試，隻能找出程式中的bug，但是并不能保證程式是沒有bug的。
完全的測試要花費很多的人力财力，并且測試的資料量過大，很浪費時間。測試的結果還很多，有的都是類似的，沒有必要進行相同的測試。是以完全測試是不可能的。
11、軟體測試的風險主要展現在哪裡？
主要展現在沒法完全測試。有些問題可能隐藏在沒有測到的地方。這樣子就被忽略了。客戶使用的時候并不熟悉軟體是如何操作的。可能有的時候會誤點點出問題。這樣子的話我們就要承擔很大的風險了。
發現的缺陷越多，說明軟體缺陷越多嗎？
是的，通常如果發現一個缺陷的話，有的時候會發現很多類似的缺陷，因為由于開發人員的習慣，可能一個地方有錯誤，另外一個地方就會有相同的錯誤。
12、所有的軟體缺陷都能修複嗎？所有的軟體缺陷都要修複嗎？
從理論上來說所有的缺陷都是可以修複的，但是并不是所有的缺陷都要修複。
一些對于軟體沒有影響的、不影響使用的缺陷我們可以不用修複。因為修複些細小的缺陷也是需要花費很多時間。項目上面可能會因為時間問題而先忽略這些小缺陷。
13、開發人員老是犯一些低級錯誤怎麼解決？
要在開發的前期就制定好一些編碼規範，這樣子可以減少很多因為個人習慣引起的錯誤。同時，測試人員在發現開發人員犯一些低級錯誤的時候不可以指責他們，要耐心的給他們指出錯誤所在。然後可以有開發人員自己進行測試，找出一些一眼看得出來是錯誤的地方。
14、您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？
我一般都是做的Web測試，搭建測試環境，對于一個程式進行內建測試，系統測試，回歸測試等。還要編寫測試用例以及一些文檔，使用者使用手冊，功能測試文檔等等。最擅長的是功能測試。
15、開發人員說不是bug時，你如何應付？
首先把自己的理由告訴開發人員。在同開發人員溝通到底是不是bug，但是如果開發人員還是認為不是bug的話，就把這個問題提到項目經理處，同時附上自己的理由。有項目經理決定是否為bug。
16、軟體測試項目從什麼時候開始為什麼？
一般軟體測試越早展開越好，一般是從需要階段就要進行軟體測試。軟體測試不僅是測試功能，對于需求文檔一類的也要進行測試。越早的找出bug，就會減少後續開發人員修改程式的次數，并且可以降低成本，如果等整個軟體開發的差不多了發現一個緻命的錯誤的話，是需要花費很多時間和人力來重新修改的。如果在一開始就發現的話就不會出現這種情況了。
18、功能測試用例需要詳細到什麼程度才是合格的？
測試用例覆寫到所有的測試點。
19、一個缺陷測試報告的組成？
缺陷編号、缺陷标題、缺陷描述、缺陷的優先級、缺陷的重要程度、缺陷所述的子產品、缺陷所屬的版本、缺陷所屬的開發人員、輸入資料、輸出結果、缺陷分析等。
20、測試用例通常包括哪些内容？
用例編号、測試環境、用例标題、輸入資料、預期結果等
21、你都用什麼測試方法？
根據不同的系統和子產品有不同的方法。主要是黑盒測試和白盒測試。
23、什麼是軟體測試，軟體測試的目的？
軟體測試是通過人工或者自動化的操作進行還沒有商業化用途的程式，檢視他們的功能是否滿足客戶需求。
目的：在最短時間内找出盡可能多的軟體缺陷。
24、什麼是相容性測試？
相容性測試是檢查軟體在不同軟體平台，硬體平台上是否可以正常運作的測試。主要檢視軟體在不同作業系統、浏覽器、資料庫中是否運作正常。
25、什麼是軟體測試？
答：為了發現程式中的錯誤而執行程式的過程
26、軟體測試的對象有哪些？
答：軟體測試并不等于程式測試。軟體測試應貫穿于軟體定義與開發的整個期間。
需求分析、概要設計、詳細設計以及程式編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程式，都應成為軟體測試的對象。
27、當測試過程發生錯誤時，有哪幾種解決辦法？
1）跳轉到别的測試過程
2）調用一個能夠清除錯誤的過程
3）退出過程，啟用另一個
4）退出過程和應用程式，重新啟動Windows，在失敗的地方重新開始測試
28、怎麼才能夠全面的測試到每一個點？
答：測試的全面性主要需要在設計測試計劃的時候考慮，從測試政策，産品需求等等多個角度考慮進而定義全部的測試點。
29、開發與測試的關系？
答：開發和測試是一個有機的整體。在産品釋出之前，開發和測試是循環進行的，測出的缺陷要經開發人員修改後繼續測試。在開發的同時測試經理開始編寫測試用例，測試文檔要參考開發文檔，是以開發和測試是不可分割的，少了任何一個都不能開發出産品。
30、測試活動中統計了哪些資料？
答：工作量 bug數量
31、進行測試時産生了哪些文檔或記錄？
答：測試的整個過程有系統測試計劃、系統測試用例、系統測試報告、缺陷報告、産品釋出說明
在執行測試的過程中隻有缺陷報告，這個還是用在缺陷管理工具中進行的，最後在工具中導出缺陷報告
32、怎樣做好測試計劃？
1）了解系統。從整個系統的高度了解被測系統必須滿足的功能和非功能性需求。利用涉及整個系統的文檔，形成對系統的整體了解。
2）及早介入。為了深入了解項目，測試人員應該在系統的開始階段介入，可以增加對客戶需求，客戶問題，潛在風險以及最重要的功能方面的了解
3）測試期望。程式員的期望是什麼？客戶的期望是什麼？銷售對測試的期望又是什麼？測試目标必須是絕對的，以免說不清是否達到目标。
4）吸取教訓。把以前工作中學習到的經驗教訓運用過來，對确定測試政策很有作用。
5）工作量太小。完成測試需要多少工作量？需要多少人員？
6）技術選擇。系統會采取什麼技術？系統會采用什麼架構？這些資訊有助于确定測試政策和測試工具。
7）時間表。系統開發和測試配置設定的時間有多長？截止日期是什麼時候？
測試執行個體
01、您所熟悉的測試用例設計方法都有哪些？請分别以具體的例子來說明這些方法在測試用例設計工作中的應用。
答：有黑盒和白盒兩種測試種類，黑盒有等價類劃分法，邊界分析法，因果圖法和錯誤猜測法。白盒有邏輯覆寫法，循環測試路徑選擇，基本路徑測試。
例子：在一次輸入多個條件的完整性查詢中。利用等價類劃分法則和邊界分析法則，首先利用等價劃分法，可以一個或多個結果是OK的測試用例，然後确認多個NG的測試用例，然後利用邊界值分析法，可以對結果分别是OK和NG的測試用例進行擴充和補充。
02、您認為做好測試用例設計工作的關鍵是什麼？
答：測試用例設計工作的關鍵是對可行的和不可行的都要考慮。
1，輸入 2，詳細的操作步驟 3，預期輸出 4，實際輸出。
03、您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。
答：有使用過LoadRunner，該工具能夠錄制測試人員的操作步驟，然後對這個操作步驟模拟出多個使用者來播放出來。
1、Visural User Genertor 建立腳本，選擇協定，錄制操作，編輯操作。
2、中央控制器（Controller）排程虛拟使用者，建立場景，選擇腳本，建立虛拟使用者，設計shedual，設定ip spoofer。
3、運作腳本。分析shedual。
4、分析測試結果。
04、您認為性能測試工作的目的是什麼？做好性能測試工作的關鍵是什麼？
答：性能測試工作的目的是檢查系統是否滿足在需求說明書中規定的性能，性能測試常常需要和強度測試結合起來，并常常要求同時進行軟體和硬體的檢測。
性能測試主要的關注對象是響應時間，吞吐量，占用記憶體大小（輔助存儲區），處理精度等。
05、在您以往的工作中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些内容？如何送出高品質的軟體缺陷（Bug）記錄？
答：檢測時間，系統環境，硬體環境，嚴重程度，程式版本，确認人，功能模闆，問題描述，詳細操作步驟，是否會重制。
問題描述和詳細操作步驟要盡可能詳細。Bug應該盡量用書面語，對于嚴重程度比較高的缺陷要在相同環境下測試一遍。
在C\S模式下，如果條件滿足可以使用替換法來确認是client端的問題還是server端的問題。
06、你對測試最大的興趣在哪裡？為什麼？
答：最大的興趣就是具有挑戰性。
因為我并不知道哪裡會出現bug，在找到一個bug後會很高興。并且測試需要很強的耐心和細心。我可以很容易的找到一些細節問題。
07、測試活動中，如果發現需要文檔不完善或者不準确，怎麼處理？
答：要及時的與項目經理進行溝通協調。要在郵件中詳細的把不完善不準确的地方描述出來，并提出自己的意見。
08、你認為做好測試計劃工作的關鍵是什麼？
答：首先，要有一個明确的目标，詳細的閱讀需求文檔說明。
其次，要對整個測試人員、測試時間、測試進度進行一個預估，并預先進行管理。
最後，要對整個測試流程設定一個規範，所有測試人員都按着規範做事，不能随心所欲的測試。
09、軟體配置管理工作開展的情況和認識？
拿到一台裸機過後要安裝客戶需要的作業系統，并且安裝一些所必須的軟體。
10、你覺得軟體測試通過的标準應該是什麼樣的？
答：測試用例完全執行，測試用例覆寫到所有的測試點，并且缺陷的密度達到客戶的需求。
11、軟體測試的文檔測試應當貫穿于軟體生命周期的全過程，其中使用者文檔是文檔測試的重點。那麼軟體系統的使用者文檔包括哪些？
答：使用者安裝文檔、使用者配置文檔、使用者使用手冊、聯機指導等。
12、簡述軟體系統中使用者文檔的測試要點？
完整性：使用者文檔中功能的描述要完整的。不能讓使用者産生疑問。
一緻性：使用者文檔中的功能描述要與實際軟體中的功能一緻。不能描述過盛。
易使用性：使用者文檔描述的内容要友善使用者閱讀并且能夠讓使用者很清楚的知道如何操作。
圖表：有的時候用圖表描述會很明了。
13、測試用例如何設計的？
答：在測試用例的設計之前首先要仔細閱讀開發的詳細設計文檔，充分了解産品的詳細功能，不清楚的地方與開發人員進行溝通，搞懂每個功能，盡量詳細到輸入框、按鈕等小功能，功能點清楚之後按照功能子產品分類進行用例編寫。在具體的用例設計中會運用到等價類邊界值等黑盒測試方法
算法與資料
在項目中，算法任務有時也會和一些用戶端的功能相結合，舉幾個例子 負回報過濾如使用者選擇不喜歡後不再出現；曝光過濾如規定出現幾次後不再出現；重新整理規則如規定重新整理後推薦資料的變化；還有一些如關注等操作後對于算法的實時影響等。對于這部分的測試，我們一般和用戶端的功能測試結合起來，手動操作用戶端，并檢查後續回報的算法結果。
01、按你的了解，軟體接口是什麼？
答：
就是指程式中具體負責在不同子產品之間傳輸或接受資料的并做處理的類或者函數。
02、HTTP和HTTPS協定差別？
https協定需要到CA（Certificate Authority，證書頒發機構）申請證書，一般免費證書較少，因而需要一定費用；
http是超文本傳輸協定，資訊是明文傳輸，Https協定是由SSL+Http協定建構的可進行加密傳輸、身份認證的網絡協定，比http協定安全；
http和https使用的是完全不同的連接配接方式，用的端口也不一樣，前者是80，後者是443；
03、HTTPS在哪一層？
以前我面試很喜歡提網絡協定的問題，有朋友說我裝X，不實用。稍有點研究網絡知識，實際就不難回答
答：HTTPS在應用層。
04、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方式
05、常見的POST送出資料方式
主要有四種方式：application/x-www-form-urlencoded、multipart/form-data、application/json、text/xml等。
06、什麼是Http協定無狀态協定?怎麼解決HTTP協定無狀态協定
無狀态是指協定對于事務處理沒有記憶能力，伺服器不知道用戶端是什麼狀态。即我們給伺服器發送 HTTP 請求之後，伺服器根據請求，會給我們發送資料過來，但是，發送完，不會記錄任何資訊。HTTP 是一個無狀态協定，這意味着每個請求都是獨立的，Keep-Alive 沒能改變這個結果。缺少狀态意味着如果後續處理需要前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。HTTP 協定這種特性有優點也有缺點，優點在于解放了伺服器，每一次請求“點到為止”不會造成不必要連接配接占用，缺點在于每次請求會傳輸大量重複的内容資訊。用戶端與伺服器進行動态互動的 Web 應用程式出現之後，HTTP 無狀态的特性嚴重阻礙了這些應用程式的實作，畢竟互動是需要承前啟後的，簡單的購物車程式也要知道使用者到底在之前選擇了什麼商品。于是，兩種用于保持 HTTP 連接配接狀态的技術就應運而生了，一個是 Cookie，而另一個則是 Session。
07、cookie和session的差別
cookie資料存放在客戶的浏覽器上，session資料放在伺服器上
cookie不是很安全，别人可以分析存放在本地的cookie并進行cookie欺騙，考慮到安全應當使用session
session會在一定時間内儲存在伺服器上。當通路增多，會比較占用你伺服器的性能，考慮到減輕伺服器性能方面應當使用cookie
單個cookie儲存的資料不能超過4K，很多浏覽器都限制一個站點最多儲存20個cookie
可以将登陸資訊等重要資訊存放為session；其他資訊需要儲存，可以放在cookie
08、請求接口中常見的傳回狀态碼
1 – 資訊提示（表示臨時的響應。用戶端在收到正常響應之前，準備接收一個或多個1xx響應）
2 – 成功（表明伺服器成功地接受了用戶端請求）
3 – 重定向（用戶端浏覽器必須采取更多操作來實作請求。例如，浏覽器可能不得不請求伺服器上的不同的頁面，或通過代理伺服器重複該請求）
4 – 用戶端錯誤（發送錯誤，用戶端有問題。例如，用戶端請求不存在的頁面，用戶端未提供有效的身份證驗證資訊）
5 – 伺服器錯誤（伺服器由于遇到錯誤而不能完成該請求）
架構
unittest
spring
其他
有清晰的思路，有的時候比确切的答案更重要
從功能測試的角度分析
功能度：用水杯裝水看漏不漏；水能不能被喝到
界面：杯子的外形，界面上的文字，圖形，顔色等是否符合原型圖
易用性：杯子是否燙手、是否有防滑措施、是否友善飲用
使用者文檔：使用手冊是否對杯子的用法、限制、使用條件等有較長的描述
相容性：杯子是否能夠容納果汁、白水、酒精、汽油等
面試的時候，我覺得我被問過很多奇葩的問題，有的時候不僅僅隻有一個，有的時候會有很多，他們會從一個問題裡抽出更多的問題來回讓人覺得是在刁難，但是又不得不回答這些問題。這時候需要注意随機應變，不可慌亂，祝君順利。
文末分享：這下面有我學習整理出來的自動化測試資料、大廠面試…待你來領取~ 見公衆号：【傷心的辣條】願你我都有所獲…
合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
我的測試學習交流群：902061117 群裡有技術大牛一起交流分享~
包裝成1年工作經驗的測試工程師，我給他的面試前的建議如下
自動化測試到底要學什麼？
為何跳槽不考慮騰訊？聊聊我和鵝廠的一點往事
自動化測試和手動測試哪個更進階？
新手必看：怎麼寫一個合格的測試用例？
python登入接口測試問題記錄與解決 ( 幹 貨 )