中國IT行業的發展，軟體測試作為產量質量監控的重要崗位，成為IT企業必備人才，對此小編進行了軟體測試面試題整理，並分享給求職者，幫助大家順利過關。
軟體測試面試題(一)
1、根據你的經驗說說你對軟體測試/質量保證的理解?
軟體質量保證與測試是根據軟體開發階段的規格說明和程式的內部結構而精心設計的一批測試用例(即輸入資料和預期的輸出結果)，並利用這些測試用例去執行程式，以發現錯誤的過程。它是對應用程式的各個方面進行測試以檢查其功能、語言有效性及外觀排布.。
2、軟體測試的流程是什麼?
需求調查: 全面瞭解您的系統概況、應用領域、軟體開發週期、軟體開發環境、開發組織、時間安排、功能需求、效能需求、質量需求及測試要求等根據系統概況進行專案所需的人員、時間和工作量估計及專案報價。
制定初步的專案計劃: 在與您充分共同和協商的基礎上制定我們的測試計劃。
測試準備: 組織測試團隊、培訓、建立測試和管理環境等。
測試設計: 按照測試要求進行每個測試項的測試設計，包括測試用例的設計及測試指令碼的開發等。
測試實施: 按照測試計劃進行實施測試。
測試評估: 根據測試的結果，出具測試評估報告。
3、(1) 你對SQA的職責和工作活動(如軟體度量)的理解：
SQA就是獨立於軟體開發的專案組，通過對軟體開發過程的監控，來保證軟體的開發流程按照指定的CMM規程(如果有相應的CMM規程)，對於不符合項及時提出建議和改進方案，必要是可以要高層經理彙報以求問題的解決。通過這樣的途徑來預防缺陷的引入，從而減少後期軟體的維護成本。SQA主要的工作活動包括制定SQA工作計劃，參與階段產物的評審，進行過程質量、功能配置及物理配置的審計等;對專案開發過程中產生的資料進行度量等等;
(2) 說說你對軟體配置管理的理解：
專案在開發的過程中要用相應的配置管理工具對配置項(包括各個階段的產物)進行變更控制，配置管理的使用取決於專案規模和複雜性能及風險的水平。軟體的規模越大，配置管理就顯得越重要。還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標準，隨後的工作便基於此標準，並且只有經過授權後才能變更這個標準。配置管理工具主要有CC,VSS,CVS等，偶只用過CVS，對其它的不熟悉
(3) 怎樣寫測試計劃和測試用例：
簡單點，測試計劃裡應有詳細的測試策略(測試方法等)，合理詳盡的資源安排等，至於測試用例，那是依賴於需求(包括功能與非功能需求)是否細化到功能點，是否可測試等。
(4) 說說主流的軟體工程思想(如CMM，CMMI，RUP，XP，PSP，TSP等)的大致情況以及對它們的理解：
CMM:SW Capability Maturity Model 軟體能力成熟度模型,其作用是用於軟體過程的改進、評估及軟體能力的評鑑
CMMI:Capability Maturity Model Integration 能力成熟度模型整合 CMMI融入了大部分最新的軟體管理實踐，同時彌補了SW-CMM模型中的缺陷
RUP:rational unified process 是軟體工程化過程。
XP：extreme program，即極限程式設計的意思，適用於小型團隊的軟體開發，想上面第三個問題就可以結合原型法採用這樣的開發流程。要明白測試對於xp開發的重要性，強調測試(重點是單元測試)先行的理念。程式設計可以明顯提高程式碼的質量，持續整合對於快速定位問題很有好處。
PSP ,TSP 分別是個體軟體過程(Personal Software Process)，群組軟體過程(Team Software Process)大家都知道，CMM只是告訴你怎麼做但並沒有告訴你如何做，所以PSP/TSP就是告訴你企業在實施CMM的過程中如何做，PSP強調建立個人技能(如何制定計劃、控制質量及如何與其他人相互協作等等)而TSP著重於生產並交付高質量的軟體產品(如何有效地規劃和管理所面臨的專案開發任務等等)。總之，單純實施CMM，永遠不能真正做到能力成熟度的升級，只有將實施CMM與實施PSP和TSP有機地結合起來，才能發揮最大的效力。因此，軟體過程框架應該是CMM/PSP/TSP的有機整合。
4、還有問一下你是怎樣保證軟體質量的，也就是說你覺得怎樣才能最大限度地保證軟體質量?
測試並不能夠最大限度的保證軟體的質量，軟體的高質量是開發和設計出來的，而不是測試出來的，它不僅要通過對軟體開發流程的監控，使得軟體開發的各個階段都要按照指定的規程進行，通過對各個階段產物的評審，QA對流程的監控，對功能及配置的審計來達到開發的最優化。當然測試也是保證軟體質量的一個重要方式，是軟體質量保證工程的一個重要組成部分。
5、然後緊接著就基於目前中國的國情，大多數公司的軟體專案進度緊張、人員較少、需求文件根本沒有或者很不規範，你認為在這種情況下怎樣保證軟體的質量?
(大多數公司最想知道的就是在這種困難面前你該怎麼保證軟體的質量，因為這些公司一般就是這種情況—–既不想投入過多又想保證質量，faint )出現以上的情況，如果僅僅想通過測試來提高軟體質量，那幾乎是不可能，原因是沒有足夠的時間讓你去測試，少而不規範的文件導致測試需求無法細化何談足夠且有針對性進行測試。所以，作為公司質量保證的你應該先和專案經理確定符合專案本身最適合的軟體生命週期模型(比如RUP的剪裁，原型法),明確專案的開發流程並督促專案組按照此流程開展工作，所有專案組成員(專案經理更加重要)都要制定出合理的工作計劃，加強程式碼的單元測試，在客戶既定的產品交付日期範圍之內，進行產品的持續整合等等，如果時間允許可以再配合客戶進行必要的系統功能測試。
6、一個測試工程師應具備那些素質和技能?
1、掌握基本的測試基礎理論 ;
2、本著找出軟體存在的問題的態度進行測試,即客觀吧,不要以挑刺形象出現
3、可熟練閱讀需求規格說明書等文件 ;
4、以使用者的觀點看待問題
5、有著強烈的質量意識 ;
6、細心和責任心 ;
7、良好的有效的溝通方式(與開發人員及客戶)
8、具有以往的測試經驗 ;能夠及時準確地判斷出高危險區在何處.
7、做好軟體測試的一些關鍵點
1.測試人員必須經過測試基礎知識和理論的相關培訓。
2.測試人員必須熟悉系統功能和業務。
3.測試必須事先要有計劃，而且測試方案要和整個專案計劃協調好
4.必須事先編寫測試用例，測試執行階段必須根據測試用例進行
5.易用性，功能，分支，邊界，效能等功能性和非功能性需要都要進行測試
6.對於複雜的流程一定要進行流程分支，組合條件分析，再進行等價類劃分準備相關測試資料
7.測試設計的一個重要內容是要準備好具體的測試資料，清楚這個測試資料是測哪個場景或分支的
8.個人任務平均每三個測試用例至少應該發現一個BUG，否則只能說明測試用例質量不好
9.除了每日構建的冒煙測試可以考慮測試自動化外，其它暫時都不要考慮去自動化。
8、軟體測試員自身素質培養
(1)首先，應對軟體測試感興趣和對自己有自信，如果具備了這兩點，那麼在開發過程中不管遇到什麼樣的困難，我相信你一定能克服。
(2)善於懷疑，世界上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事，我卻認為可能發生。別人認為是對的，我卻認為不是對的。
(3) 打破砂鍋問到底的精神，對於只出現過一次的bug，一定找出原因，不解決誓不罷休。
(4) 保持一個良好的心情，否則可能無法把測試作好。不要把生活中的不愉快的情緒帶到工作中來。
(5) 做測試時要細心，不是所有的bug都能很容易的找出，一定要細心才能找出這些bug。
(6) 靈活一些，聰明一點，多製造一些容易產生bug的例子。
(7) 在有條件的情況下，多和客戶溝通，他們身上有你所需要的`。
(8) 設身處地為客戶著想，從他們的角度去測試系統。
(9) 不要讓程式設計師，以“這種情況不可能發生”這句話說服你，相反，你應該去說服他，告訴他在客戶心裡，並不是這樣的。
(10) 考慮問題要全面，結合客戶的需求、業務的流程、和系統的構架，等多方面考慮問題。
(11)提出問題不要複雜化，這一點和前面的有點矛盾，如果你是一新手，暫時不要管這一點，因為最終將有你的小組成員討論解決。
(12) 追求完美，對於新測試員來說，努力的追求完美，這對你很好，儘管有些事無法做到，但你應該去嘗試。
(13)幽默感，能和開發小組很好的溝通是關鍵，試著給你的開發小組找一個“BUG殺手”，或對他們說“我簡直不敢相信，你寫的程式居然到現在沒有找到BUG”。
(14)到此是不是對測試很有興趣呢?不過我要告訴你，測試過程中有酸甜苦辣，其中的滋味只有你知道，也許你會感到枯燥，要學會放鬆自己，去溜冰或做你喜歡做的事，不過，別放棄，因為你的自信告訴過你“你會是很優秀的測試員”不是嗎?
9、為什麼要在一個團隊中開展軟體測試工作?
因為沒有經過測試的軟體很難在釋出之前知道該軟體的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測試的工作。在測試的過程發現軟體中存在的問題，及時讓開發人員得知並修改問題，在即將釋出時，從測試報告中得出軟體的質量情況。
10、您所熟悉的軟體測試型別都有哪些?
測試型別有：功能測試，效能測試，介面測試。
功能測試在測試工作中佔的比例最大，功能測試也叫黑盒測試。
效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。
介面測試，介面是軟體與使用者互動的最直接的層，介面的好壞決定使用者對軟體的第一印象。
11、您認為做好測試用例設計工作的關鍵是什麼?
白盒測試用例設計的關鍵是以較少的用例覆蓋儘可能多的內部程式邏輯結果黑盒用例設計的關鍵同樣也是以較少的用例覆蓋模組輸出和輸入介面。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題
軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做一個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或資料驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能?
2、在介面上，輸入是否能正確的接受?能否輸出正確的結果?
3、是否有資料結構錯誤或外部資訊(例如資料檔案)訪問錯誤?
4、效能上是否能夠滿足要求?
5、是否有初始化或終止性錯誤?
軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做一個開啟的盒子，它允許測試人員利用程式內部的邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程式模組進行如下檢查：
1、對程式模組的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在迴圈的邊界和執行的界限內執行迴圈體。
4、測試內部資料結構的有效性，等等。4、驗收測試是部署軟體之前的最後一個測試操作。驗收測試的目的是確保軟體準備就緒，並且可以讓終端使用者將其用於執行軟體的既定功能和任務。驗收測試是向未來的使用者表明系統能夠像預定要求那樣工作。經整合測試後，已經按照設計把所有的模組組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測試的任務，即軟體的功能和效能如同使用者所合理期待的那樣。
12、測試計劃工作的目的是什麼?測試計劃工作的內容都包括什麼?其中哪些是最重要的?
軟體測試計劃是指導測試過程的綱領性檔案，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟體測試計劃，參與測試的專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試策略和測試方法(最好是能先評審)
13、您認為做好測試計劃工作的關鍵是什麼?
1. 明確測試的目標，增強測試計劃的實用性
編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試專案，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確
2.堅持“5W”規則，明確內容與過程
“5W”規則指的是“What(做什麼)”、“Why(為什麼做)”、“When(何時做)”、“Where(在哪裡)”、“How(如何做)”。利用“5W”規則建立軟體測試計劃，可以幫助測試團隊理解測試的目的(Why)，明確測試的範圍和內容(What)，確定測試的開始和結束日期(When)，指出測試的方法和工具(How)，給出測試文件和軟體的存放位置(Where)。
3.採用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成後，如果沒有經過評審，直接傳送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
4. 分別建立測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立建立的測試詳細規格文件，把用於指導測試小組執行測試過程的測試用例放到獨立建立的測試用例文件或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
14、 您所熟悉的測試用例設計方法都有哪些?
1.等價類劃分
2.邊界值分析法
3.錯誤推測法
4.因果圖方法
15、你的測試職業發展是什麼?
測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向著高階測試工程師奔去。而且我也有初步的職業規劃，前3年累積測試經驗，按如何做好測試工程師的11，12點要求自己，不斷的更新自己改正自己，做好測試任務。
16、你自認為測試的優勢在哪裡?
優勢在於我對測試堅定不移的信心和熱情，雖然經驗還不夠，但測試需要的基本技能我有信心在工作中得以發揮。
17、當開發人員說不是BUG時，你如何應付?
開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先儘可能的說出是BUG的依據是什麼?如果被使用者發現或出了問題，會有什麼不良結果?程式設計師可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最後的確認。
軟體測試面試題(二)
1、介紹一下整體專案流程
答案：
1. 搭建缺陷管理的環境和測試環境以及配置管理的環境搭建;2. 編寫測試計劃;3. 設計測試用例;4. 編寫測試用例;5. 測試用例的評審;6. 執行測試;7. 缺陷管理; 8. 測試報告的輸出
2、在實際專案中你是如何做測試計劃
答案：
1.對客戶提供的或需求分析人員編寫的使用者需求文件或需求規格說明書進行分析，提煉出測試要點;
2.根據測試要點編寫測試用例。
3.由評審組對測試用例進行評審--修改--再次評審--初步定稿
4.執行測試
4.1 按照測試用例對系統進行功能驗證及客戶的需求驗證
4.2 將測試過程中產生的Bug錄入缺陷管理系統
4.3 新版本釋出後，對本次版本新增加的功能以及開發人員修正的Bug進行迴歸測試
4.4 根據專案需要提交測試報告。
3、你是如何制定測試過程中的時間進度表的
答案:根據專案的需求、開發週期、開發人員的開發進度等時間安排來制定一個測試時間進度初 稿，並將測試時間進度表交與整個項
目團隊成員大家一起討論和分析，最終和所有人達成共識制定出一個大家都可以執行的測試時間進度表。
時間表中包括了開發人員提交功能或功能模組的時間，以及為了更好的執行測試，配合測試人員進行功能培訓的時間，以及測試
執行時間等，都詳細的寫到WBS中，並按照這個時間進度表來執行專案的測試任務。
4、測試計劃都包括那些項
答案：1. 測試計劃目標 2. 測試參考文件 3.測試術語與定義 4. 測試內容 5. 測試人員的分工 6. 測試進度 7. 測試流程
8. 測試工具 9.測試缺陷管理 10. 測試的風險分析
5、測試用例如何設計的
答案：在測試用例設計之前首先要熟悉客戶的需求文件或需求規格說明書，以做到對被測系統的熟悉，充分了解產品的詳細功能，並在熟
悉過程中即使與研發人員和客戶人員進行有效的溝通。然後從需求中提煉中各個模組的詳細功能點編寫出一個測試要點的文件。根
據測試要點設計測試用例，測試要點與測試用例是一個一對多的關係，一個測試要點可能會需要幾個測試用例的驗證，有正常的操
作和異常的操作，甚至是幾個正常與幾個異常的操作，這要根據實際功能的要求來具體分析具體實現。
6、測試用例包括那些項
答案：產品名稱、功能模組、用例的編號、編寫人、被測功能的簡述，測試的預置條件，測試步驟，預期結果，實際結果。
7、缺陷處理流程
1.講缺陷的詳細資訊錄入缺陷管理系統，並分配給對應的開發人員
2.如果遇到一些難以再現的缺陷，在開發人員修正過程中配合開發人員進行Bug的再現。
3.開發人員修正Bug後，會在缺陷管理系統中將修正後的Bug狀態更改，通常為Fixed狀態。
4.新版本釋出後，測試人員會講bug狀態已經更改為Fixed的Bug進行迴歸測試。如果測試通過，則將該Bug關閉，如果仍
未通過，則將該Bug從Fixed更改為Reopen狀態，繼續讓開 發人員來修正。並等待下一個新版本釋出後的二次迴歸測試。
8、缺陷報告包括那些項
答案：編寫人、被測系統的版本號、測試環境、預期結果、實際結果、對於實際結果如有必要附上截圖、測試用例數、測試
用例通過 數，測試用例的通過率、對缺陷的一個分析彙總。
9、缺陷報告嚴重級別的劃分
嚴重級別的錯誤：影響系統整體基本流程執行的錯誤，由於某一操作造成系統無窮迴圈或伺服器崩潰的錯誤
較嚴重：功能實現錯誤、內部計算錯誤、
一般：UI錯誤，一些易用性的錯誤或建
10、開發人員修復缺陷後，如何保證不影響其他功能
答案：Bug的修復以及新功能的新增都有可能對版本造成一些影響，為了避免，在新版本釋出以後，首先會對新版本做一個基礎
的流程測試也叫做冒煙測試，如果測試基本流程都順利通過沒有任何問題，那麼測試人員可以繼續進行詳細的測試，否
則就將冒煙測試中出現 的問題以及問題有可能出現的原因反饋給開發人員，由開發人員修正後再次發版，進行測試。這
是一個迭代的過程。
10、發現問題後你是如何判斷其是否是BUG，你是如何提交的、
答案：測試用例是經過評審組嚴格的評審，完全按照客戶的需求規格說明書作為最終依據來評審的，如果測試過程中，測試結果與實際結
果不符就很可能是Bug，如果一些比較明顯的問題就直接錄入缺陷管理系統，如果是一些邊界問題不容易確定的，可以通過和開發人
員甚至是設計人員等進行溝通最後得出一個結果究竟是否是Bug，如果是Bug就錄入，如果是一個需要增加的新功能等，可以錄入缺
陷管理系統，型別為新需求。
11、修復一個BUG而導致其他的BUG出現，該如何處理
答案：幫助開發人員分析問題鎖定原因然後進行新Bug的修正。
12、測試總結報告包括那些項
答案：測試用例的通過數，測試用例的未通過數，以及測試用例的通過率，未通過的功能都集中在哪幾個功能模組 ，根據測試經驗以及測試結果進行一個缺陷的分析和建議。
13、測試工作進行到一半是，發現時間不夠，你如何處理
答案：1.與客戶溝通本次釋出的版本什麼是最重要的，什麼是其次，我會安排一個優先順序來對整體測 試功能進行一個篩選。
2.我會和測試組原體人員一起加班
14、開發與測試的關係
答案：開發和測試是一個整體，也可以說測試驅動著開發，開發配合著測試，相輔相成的，在一個完整的專案組中缺一不可。
15、如果你是測試組長你如何對專案及組員進行管理
答案： 首先要從需求開始，充分了解被測系統的功能以及業務需求，並在遇到問題的時候及時有效的與開發人員以及其他專案相關人員
進行溝通，做到最被測系統的十分熟悉。並瞭解整個測試組的成員他們的測試技能以及擅長的工作，做到測試任務的合理分配，
得以讓測試工作快速，穩定高效的進行!
16、如果你提交的BUG開發人員說這不是缺陷你該怎麼辦
答：若遇到開發人員說提交BUG不是缺陷則跟專案組的需求人員，設計人員以及該功能的開發人員共同討論做確認。