以下內容首發於微信公眾號【ITester軟件測試小棧】：
測試面試題集-1.測試基礎理論
大家好我是coco小錦鯉最近很多小可愛在找工作、找實習
因為知識積累不系統
不會總結
經驗不足等原因
還沒有找到理想的測試工作
看着身邊的朋友
都紛紛收到了心儀的offer
而自己卻待在原地
恐慌和對未來的迷茫每日劇增
接下來每周五給大家推送面試系列記得持續關注哦
Q:
一、進行測試用例設計的時候用到的方法有哪些？
A:
最常使用的測試用例設計方法包括等價類划分法、邊界值分析方法、場景法、錯誤推測法。其中，最容易發現錯誤的是邊界值法，使用最多的是場景法。以注冊為例：首先從需求確定用戶名和密碼的長度類型約束，根據需求寫測試點，然后設計測試數據，編寫測試用例。
Q:
二、測試計划包括哪些主要步驟和信息？
A:
測試計划包括引言、測試基本內容（測試目的、測試范圍、測試環境、測試工具、測試人員）、實施計划（任務分配、進度安排）、風險控制等。
Q:
三、測試報告需要包含哪些內容？測試報告交付文檔有哪些？你認為測試報告的側重點是什么？
A:
測試報告包括：引言、測試基本信息、測試結果及缺陷分析、測試結論和建議，交付文檔。
交付文檔有測試用例、提交的bug、測試報告。
測試報告的側重點是測試結果和缺陷分析，測試結論。
Q:
四、bug的生命周期？你是怎么跟進bug的？
A:
bug的生命周期，就是一個bug被發現到這個bug被關閉的過程。生命周期中一般缺陷狀態：新建、指派、已解決、待驗、關閉。
具體流程如下：1.新建Bug，把bug記錄到缺陷管理平台;2.指派給對應的開發人員；3.開發人員對Bug進行確認；4.開發對Bug進行修復；5.開發修改后，等新代碼包更新測試環境，然后進行bug驗證；6.如果Bug已經修復，測試人員直接關閉 ；7.如果待驗的bug在驗證時沒有解決好，我們需要重新打開>指派>已解決>待驗，循環這個過程。中間其他狀態：重新打開、拒絕、延期等；8.如果提交bug后，開發一直沒有修改狀態，我們會提醒開發。延期、不予修改的bug則跟開發溝通，找產品確認是否修改。
Q:
五、Bug記錄包含哪些內容？如何提交高質量的bug記錄？
A:
一條bug信息至少需要以下幾條：
bug標題；bug產生的模塊；bug對應的版本；bug嚴重級別；優先級；bug詳細現象描述，包括bug出現的操作步驟，報錯日志信息、bug截圖等等。
提交高質量的軟件缺陷記錄需要做到以下幾點：
1.嚴格按照測試流程執行測試：參考需求以及詳細設計等前期文檔設計出高效的測試用例，然后嚴格執行測試用例，對發現的問題要充分確認肯定，然后再向外發布。
2.規范提交Bug：注重唯一性，一個bug說明一個問題或者說明一類問題可重現。
3.提交Bug注意准確性：提供這個bug的精確步驟，要讓開發人員容易看懂一致；Bug描述及所有信息要前后一致，不可有歧義完整性。
4.明確指明缺陷嚴重等級和優先級：明確嚴重等級和優先等級之間的差別，優先解決優先級高的問題。
5.Bug附錄：能附帶bug現象截圖的就帶截圖，有報錯日志的就貼上日志信息客觀性。
6.不可重現的缺陷也要記錄：首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之后仍不能重現，仍然要報告此缺陷，但在報告中要注明無法再現，缺陷出現的頻率。
7.明確指明缺陷類型：根據缺陷的現象，總結判斷缺陷的類型。如，功能缺陷、界面缺陷、數據缺陷，合理化建議這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬於其中某種形式。
Q:
六、測試分為哪幾個階段?
A:
按照開發階段划分，軟件測試可以分為單元測試、集成測試、系統測試和驗收測試；
1.單元測試：針對每個單元的測試，以及確保每個模塊能正常工作為目標；
2.集成測試：對已測試過的模塊進行組裝，進行集成測試，目的在於檢驗與軟件設計相關的程序結構問題；
3.系統測試：檢驗軟件產品能否與系統的其他部分（比如硬件、數據庫及操作人員）協調工作；
4.驗收測試：檢驗軟件產品質量的最后一道工序，主要突出用戶的作用，同時軟件開發人員也應有一定程度的參與。
Q:
七、什么是回歸測試？
A:
回歸測試有兩類：用例回歸和錯誤回歸；用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行測試，看看會重新發現問題。錯誤回歸，就是在新版本中，對以前版本中出現並修復的缺陷進行再次驗證，並以缺陷為核心，對相關修改的部分進行測試的方法。
Q:
八、什么是驗收測試？Alpha測試和Beta測試的區別是什么？
A:
驗收測試是以用戶為主的測試，軟件開發和QA人員也應該參加，測試一般在用戶所在地進行，由用戶驗證軟件產品是否滿足了所有的需求的一系列的驗收測試工作。僅限於內部測試穩定后，根據合同中需求由發包商進行驗收測試。驗收測試的目的是為了以發現”未實現的需求”為目的，以評估”適合使用”為目標，該類測試的不是以發現缺陷為主要目的。
Alpha測試和Beta測試的區別：兩者的主要區別是測試的場所不同。Alpha測試是指把用戶請到開發方的場所來測試；beta測試是指在一個或多個用戶的場所進行的測試。Alpha測試的環境是受開發方控制的,用戶的數量相對比較少,時間比較集中。Alpha測試在系統開發接近完成時對應用系統的測試；測試后仍然會有少量的設計變更。這種測試一般由最終用戶或其它人員完成，不能由程序或測試員完成。
Beta測試是當開發和測試基本完成時所做的測試，最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。
Q:
九、你提的問題，開發人員說不是BUG時，你如何應付？
A:
開發人員說不是bug，有兩種情況，一是需求沒有確定，所以可以找產品經理進行確認，評估是否需要改動，三方商量確定好后再看是否要改。二是這種情況開發認為不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出BUG的依據是什么，如果被用戶發現或出了問題，會有什么不良結果。如果還是有分歧，可以將這個問題提出來,跟開發經理和測試經理進行確認，確定是bug的話，一定要堅持自己的立場，讓問題得到最后的確認。
Q:
十、測試結束的標准是什么？
A:
各個公司可能不同，以下僅供參考，具體根據公司實際情況執行。
1.系統測試用例設計已經通過評審；
2.按照系統測試計划完成了系統測試；
3.核心代碼100％ 經過Code Review；
4.系統測試的功能覆蓋率達100％；
5.系統的功能和性能滿足產品需求規格說明書的要求；
6.在系統測試中發現的錯誤已經得到修改並且各級缺陷修復率達到標准；
7.嚴重錯誤和主要錯誤的缺陷修復率必須達到100%，不允許存在功能性的錯誤；次要錯誤和一般錯誤的缺陷修復率必須達到85%以上，允許存在少量功能缺陷，后續版本解決；對於較小錯誤的缺陷修復率最好達到60%~70%以上；對於測試建議性的問題，可調低優先級；
8.由開發經理，測試經理，項目經理共同確認后發布上線。
想要獲取相關資料和軟件 ？
Q群：701841415