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