軟件測試面試題大全

1、軟件測試面試題大全窗體頂端問題一：為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？任何軟件在開發(fā)過程中都會留下缺陷，帶有缺陷的軟件產(chǎn)品如果提交出去，可能會給公司帶來不可估量的損失，我們必須在客戶之前發(fā)現(xiàn)盡可能多的問題，從而保障客戶滿意。而發(fā)現(xiàn)問題的這個(gè)過程稱之為測試。問題二：簡述你在以前的工作中做過哪些事情，比較熟悉什么。此問題每個(gè)人都不一樣。我自己的答案如下。我主要的工作是系統(tǒng)測試和自動化測試，也曾少量涉及性能測試。在系統(tǒng)測試中，主要是對BOSS系統(tǒng)的業(yè)務(wù)邏輯功能，以及軟交換系統(tǒng)的Class 5特性進(jìn)行測試。性能測試中，主要是進(jìn)行的壓力測試，在各個(gè)不同數(shù)量請求的情況下，獲取系統(tǒng)響應(yīng)時(shí)間以及系統(tǒng)資源消耗

2、情況。自動化測試主要是通過自己寫腳本問題三：你所了解的的軟件測試類型都有哪些，簡單介紹一下。1. 基本功能驗(yàn)證。主要是對發(fā)布的版本進(jìn)行一些最主要功能的測試。英文常見叫法是Smoking Test, Basic Verification Test或者Sanity Check。2. 功能測試。主要是依據(jù)需求或者需求分析文檔，對所發(fā)布的版本進(jìn)行測試，看看是否滿足需求，是否出現(xiàn)了不必要的功能。3. 單元測試。是開發(fā)人員進(jìn)行的測試之一，一般是開發(fā)人員對很小的模塊，比如函數(shù)進(jìn)行測試，一般來說，開發(fā)人員還需要開發(fā)相應(yīng)的測試樁來進(jìn)行此類測試。4. 集成測試。在大型的開發(fā)過程中，軟件是模塊化進(jìn)行開發(fā)的，將不同的

3、模塊揉合在一起的話，需要進(jìn)行的測試就是集成測試。5. 系統(tǒng)測試。當(dāng)軟件提交給測試組后，是對整個(gè)系統(tǒng)的所有功能進(jìn)行測試，一般來說，功能測試是系統(tǒng)測試的一個(gè)部分。6. 壓力測試。主要是在很大性能的情況下，這個(gè)性能已經(jīng)接近了系統(tǒng)的極限，看看系統(tǒng)運(yùn)轉(zhuǎn)的情況。推薦精選7. 負(fù)載測試。主要是用各種不同的性能去檢測系統(tǒng)，采集各個(gè)數(shù)據(jù)在這些性能情況下的數(shù)據(jù)。8. 黑盒測試。指系統(tǒng)對你來說是完全不透明的，只給你留下了輸入和最終輸出，這個(gè)是功能測試的方法之一。9. 灰盒測試。指在了解部分系統(tǒng)內(nèi)部工作機(jī)制的情況下，對于系統(tǒng)進(jìn)行的覆蓋性測試。10. 白盒測試。主要是在單元測試和集成測試的情況下，開發(fā)人員已知代碼，對這

4、一段的代碼進(jìn)行全路徑的覆蓋測試。11. 界面測試。主要是看用戶界面的友好性和易用性，是否有文字或者排版錯(cuò)誤，是否有輸入限制等等。12. 回歸測試。一般是系統(tǒng)發(fā)現(xiàn)BUG，開發(fā)人員修改后，和BUG直接相關(guān)以及可能相關(guān)的功能進(jìn)行的測試。13. 安裝和卸載的測試。14. 恢復(fù)測試。主要是一個(gè)系統(tǒng)在發(fā)生了災(zāi)難的情況下，從錯(cuò)誤中是否容易恢復(fù)。15. 兼容性測試。一個(gè)系統(tǒng)在不同的語言，操作系統(tǒng)下的系統(tǒng)測試。16. 安全測試。系統(tǒng)在遇到攻擊或者類似情況下的表現(xiàn)。17. Alpha測試。系統(tǒng)在給最終用戶前，測試人員在實(shí)驗(yàn)室中模擬最終用戶的測試。18. Beta測試。由部分最終用戶通過使用來進(jìn)行的測試。19. 比

5、較測試。和其他具有相同或者類似功能的系統(tǒng)進(jìn)行對比的測試。20. 驗(yàn)收測試。一般是最終用戶在接受產(chǎn)品前，依據(jù)自己所提出的要求進(jìn)行的測試，很多情況下，驗(yàn)收測試可能委托第三方機(jī)構(gòu)完成。問題四：測試計(jì)劃工作的目的是什么？測試計(jì)劃文檔的內(nèi)容應(yīng)該包括什么？其中哪些是最重要的？推薦精選軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件。包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測試計(jì)劃，參與測試的項(xiàng)目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實(shí)施過程的順暢溝通，跟蹤和控制測試進(jìn)度，應(yīng)對測試過程中的各種變更。測試計(jì)劃和測試詳細(xì)規(guī)格、測

6、試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。問題五：你認(rèn)為做好測試計(jì)劃工作的關(guān)鍵是什么？1. 明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性編寫軟件測試計(jì)劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計(jì)劃的價(jià)值取決于它對幫助管理測試項(xiàng)目，并且找出軟件潛在的缺陷。因此，軟件測試計(jì)劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實(shí)可行，測試工具并且具有較高的實(shí)用性，便于使用，生成的測試結(jié)果直觀、準(zhǔn)確2. 堅(jiān)持“5W”規(guī)則，明確內(nèi)容與過程“5

7、W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時(shí)做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計(jì)劃，可以幫助測試團(tuán)隊(duì)理解測試的目的（Why），明確測試的范圍和內(nèi)容（What），確定測試的開始和結(jié)束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。3. 采用評審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求測試計(jì)劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團(tuán)隊(duì)，測試計(jì)劃內(nèi)容的可能不準(zhǔn)確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計(jì)劃的內(nèi)容沒有及時(shí)更新，誤導(dǎo)測試執(zhí)行人員。推薦精選4

8、. 分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨(dú)立創(chuàng)建的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)行測試過程的測試用例放到獨(dú)立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)問題六：常見的測試用例設(shè)計(jì)方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計(jì)工作中的應(yīng)用。1. 等價(jià)類劃分劃分等價(jià)類: 等價(jià)類是指某個(gè)輸入域的子集合.在該子集合中,各個(gè)輸入數(shù)據(jù)對于揭露程序中的錯(cuò)誤都是等效的.并合理地假定:測試某等價(jià)類的代表

9、值就等于對這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)類,在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價(jià)類劃分可有兩種不同的情況:有效等價(jià)類和無效等價(jià)類.2. 邊界值分析法邊界值分析方法是對等價(jià)類劃分方法的補(bǔ)充。測試工作經(jīng)驗(yàn)告訴我,大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計(jì)測試用例,可以查出更多的錯(cuò)誤.使用邊界值分析方法設(shè)計(jì)測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價(jià)類的邊界,就是應(yīng)著重測試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不

10、是選取等價(jià)類中的典型值或任意值作為測試數(shù)據(jù).3. 錯(cuò)誤推測法推薦精選基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤, 從而有針對性的設(shè)計(jì)測試用例的方法.錯(cuò)誤推測方法的基本思想: 列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況,根據(jù)他們選擇測試用例. 例如, 在單元測試時(shí)曾列出的許多在模塊中常見的錯(cuò)誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等, 這些就是經(jīng)驗(yàn)的總結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯(cuò)誤的情況. 可選擇這些情況下的例子作為測試用例.4. 因果圖方法前面介紹的等價(jià)類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入

11、條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價(jià)類,他們之間的組合情況也相當(dāng)多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應(yīng)產(chǎn)生多個(gè)動作的形式來考慮設(shè)計(jì)測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況. 5. 正交表分析法有時(shí)候，可能因?yàn)榇罅康膮?shù)的組合而引起測試用例數(shù)量上的激增，同時(shí)，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進(jìn)行縮減一些用例，從而達(dá)

12、到盡量少的用例覆蓋盡量大的范圍的可能性。6. 場景分析方法指根據(jù)用戶場景來模擬用戶的操作步驟，這個(gè)比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。問題七：您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？白盒測試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果推薦精選黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題問題八：詳細(xì)的描述一個(gè)測試活動完整的過程。1. 項(xiàng)目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評審，評審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實(shí)現(xiàn)的功能的地方

13、。項(xiàng)目經(jīng)理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項(xiàng)目計(jì)劃。然后SQA進(jìn)入項(xiàng)目，開始進(jìn)行統(tǒng)計(jì)和跟蹤2. 開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進(jìn)行評審，評審的主要內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計(jì)劃文檔，測試計(jì)劃包括的內(nèi)容上面有描述。3. 測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時(shí)開發(fā)人員完成概要設(shè)計(jì)文檔，詳細(xì)設(shè)計(jì)文檔。此兩份文檔成為測試人員撰寫測試用例的補(bǔ)充材料。4. 測試用例完成后，測試和開發(fā)需要進(jìn)行評審。5. 測試人員搭建環(huán)境6. 開發(fā)人員提交第一個(gè)版本，可能存在未完成功能，需要說明。測試人員進(jìn)行測試，發(fā)現(xiàn)BUG后提交給BugZilla。

14、7. 開發(fā)提交第二個(gè)版本，包括Bug Fix以及增加了部分功能，測試人員進(jìn)行測試。8. 重復(fù)上面的工作，一般是3-4個(gè)版本后BUG數(shù)量減少，達(dá)到出貨的要求。9. 如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。問題九：以往是否曾經(jīng)從事過性能測試工作？請盡可能的詳細(xì)描述您以往的性能測試工作的完整過程。曾經(jīng)做過一套網(wǎng)管系統(tǒng)的性能測試，主要測試該軟件在同時(shí)管理大量終端的情況下，在響應(yīng)時(shí)間，CPU/磁盤/內(nèi)存等參數(shù)是否滿足要求。推薦精選也曾經(jīng)做過軟交換系統(tǒng)的呼叫性能測試，主要是測試軟交換系統(tǒng)在有大量呼叫的情況下，響應(yīng)時(shí)間，呼叫成功率，CPU/磁盤/內(nèi)存等參數(shù)是否滿足設(shè)計(jì)要求。問題十：您在從事性

15、能測試工作時(shí)，是否使用過一些測試工具？如果有，請?jiān)囀鲈摴ぞ叩墓ぷ髟?，并以一個(gè)具體的工作中的例子描述該工具是如何在實(shí)際工作中應(yīng)用的。測試網(wǎng)管系統(tǒng)中，使用的Mimic來模擬終端，能夠大量的節(jié)省成本。測試軟交換系統(tǒng)的時(shí)候，使用的Prolab來模擬終端并發(fā)送呼叫軟交換，他完成了同時(shí)數(shù)百人才能完成的摘機(jī)撥號工作，主要工作原理是產(chǎn)生一些符合要求的IP包并發(fā)送給軟交換系統(tǒng)，同時(shí)對軟交換系統(tǒng)的回應(yīng)進(jìn)行處理，決定下一步動作。問題十一：您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？主要是保障在大量用戶的情況下，服務(wù)能正常使用。問題十二：在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪

16、些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？1. 在傳統(tǒng)的BugZilla中，BUG描述應(yīng)該包括以下的信息2. 和BUG產(chǎn)生對應(yīng)的軟件版本3. 開發(fā)的接口人員4. BUG的優(yōu)先級5. BUG的嚴(yán)重程度6. BUG可能屬于的模塊，如果不能確認(rèn)，可以用開發(fā)人員來判斷7. BUG標(biāo)題，需要清晰的描述現(xiàn)象推薦精選8. BUG描述，需要盡量給出重新Bug的步驟9. BUG附件中能給出相關(guān)的日志和截圖。高質(zhì)量的BUG記錄就是指很容易理解的BUG記錄，所以，對于描述的要求高，能提供的信息多且準(zhǔn)確，很好的幫助開發(fā)人員定位。問題十二：BUG管理工具的跟蹤過程用BugZilla為例子 測試人員發(fā)現(xiàn)了BUG，提

17、交到Bugzilla中，狀態(tài)為new，BUG的接受者為開發(fā)接口人員開發(fā)接口將BUG分配給相關(guān)的模塊的開發(fā)人員，狀態(tài)修改為已分配開發(fā)人員和測試確認(rèn)BUG，如果是本人的BUG，則設(shè)置為接收；如果是別的開發(fā)人員的問題，則轉(zhuǎn)發(fā)出去，由下一個(gè)開發(fā)人員來進(jìn)行此行為；如果認(rèn)為不是問題，則需要大家討論并確認(rèn)后，拒絕這個(gè)BUG，然后測試人員關(guān)閉此問題。如果開發(fā)人員接受了BUG，并修改好以后，將BUG狀態(tài)修改為已修復(fù)，并告知測試在哪個(gè)版本中可以測試。測試人員在新版本中測試，如果發(fā)現(xiàn)問題依然存在，則拒絕修改；如果已經(jīng)修復(fù)，則關(guān)閉BUG。問題十二：您認(rèn)為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的

18、效果？維持測試人員同開發(fā)團(tuán)隊(duì)中其他成員良好的人際關(guān)系的關(guān)鍵是什么？盡量能有面對面的溝通，如果做不到，那么盡量能直接通過電話溝通，如果只能通過Email等非及時(shí)溝通工具的話，強(qiáng)調(diào)必須對特性的理解深刻以及能表達(dá)清楚。一是真誠，二是團(tuán)隊(duì)精神，三是在專業(yè)上有共同語言，當(dāng)然也可以通過直接指出一些小問題，而不是進(jìn)入BUG Tracking System來增加對方的好感。推薦精選問題十三：在您以往的測試工作中，最讓您感到不滿意或者不堪回首的事情是什么？您是如何來對待這些事情的？某次性能測試覆蓋不足，造成系統(tǒng)崩潰。問題十四：你對測試最大的興趣在哪里？為什么？最大的興趣就是測試有難度，有挑戰(zhàn)性！做測試越久越能感

19、覺到做好測試有多難。曾經(jīng)在無憂測試網(wǎng)上看到一篇文章，是關(guān)于如何做好一名測試工程師。一共羅列了11，12點(diǎn)，有部分是和人的性格有關(guān)，有部分需要后天的努力。但除了性格有關(guān)的1，2點(diǎn)我沒有把握，其他點(diǎn)我都很有信心做好它。剛開始進(jìn)入測試行業(yè)時(shí)，對測試的認(rèn)識是從無憂測試網(wǎng)上了解到的一些資料，當(dāng)時(shí)是沖著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發(fā)更難，雖然當(dāng)時(shí)我很想做開發(fā)（學(xué)校專業(yè)課我基本上不缺席，因?yàn)槲蚁矚g我的專業(yè)），但看到測試比開發(fā)更難更有挑戰(zhàn)性，想做好測試的意志就更堅(jiān)定了。我覺得做測試整個(gè)過程中有2點(diǎn)讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測試用例的設(shè)計(jì)，因

20、為測試的精華就在測試用例的設(shè)計(jì)上了，要在版本出來之前，把用例寫好，用什么測試方法寫？（也就是測試計(jì)劃或測試策略），如果你剛測試一個(gè)新任務(wù)時(shí)，你得花一定的時(shí)間去消化業(yè)務(wù)需求和技術(shù)基礎(chǔ)，業(yè)務(wù)需求很好理解（多和產(chǎn)品經(jīng)理和開發(fā)人員溝通就能達(dá)到目的），而技術(shù)基礎(chǔ)可就沒那么簡單了，這需要你自覺的學(xué)習(xí)能力，比如說網(wǎng)站吧，最基本的技術(shù)知識你要知道網(wǎng)站內(nèi)部是怎么運(yùn)作的的，后臺是怎么響應(yīng)用戶請求的？測試環(huán)境如何搭建？這些都需要最早的學(xué)好。至少在開始測試之前能做好基本的準(zhǔn)備，可能會遇到什么難題？需求細(xì)節(jié)是不是沒有確定好？這些問題都能在設(shè)計(jì)用例的時(shí)候發(fā)現(xiàn)。第二是發(fā)現(xiàn)BUG的時(shí)候了，這應(yīng)該是測試人員最基本的任務(wù)了，一般

21、按測試用例開始測試就能發(fā)現(xiàn)大部分的bug，還有一部分bug需要測試的過程中更了解所測版本的情況獲得更多信息，補(bǔ)充測試用例，測試出bug。還有如何發(fā)現(xiàn)bug？這就需要在測試用例有效的情況下，通過細(xì)心和耐心去發(fā)現(xiàn)bug了，每個(gè)用例都有可能發(fā)現(xiàn)bug，每個(gè)地方都有可能出錯(cuò)，所以測試過程中思維要清晰（測試過程數(shù)據(jù)流及結(jié)果都得看仔細(xì)了，bug都在里面發(fā)現(xiàn)的）。如何描述bug也很有講究，bug在什么情況下會產(chǎn)生，如果條件變化一點(diǎn)點(diǎn)，就不會有這個(gè)bug，以哪些最少的操作步驟就能重現(xiàn)這個(gè)bug，這個(gè)bug產(chǎn)生的規(guī)律是什么？如果你夠厲害的話，可以幫開發(fā)人員初步定位問題。推薦精選問題十五：你的測試職業(yè)發(fā)展目標(biāo)是什么？測試經(jīng)驗(yàn)越多，測試能力越高。所以我的職業(yè)發(fā)展是需要時(shí)間累積的，一步步向著高級測試工程師奔去。而且我也有初步的職業(yè)規(guī)劃，前3年累積測試經(jīng)驗(yàn)，按如何做好測試工程師的11，12點(diǎn)要求自己，不斷的更新自己改正自己，做好測試任務(wù)。問題十六：你自認(rèn)為測試的優(yōu)勢在哪里？有韌性有能力面對挑戰(zhàn)有信心做好每一件事情有比較好的教育背景從以前的經(jīng)理處都得到了很好的評價(jià)表明我做的很好問題十七：當(dāng)開發(fā)人員說不是BUG時(shí)，你如何應(yīng)付？如果確實(shí)是自己理解錯(cuò)誤，則承認(rèn)錯(cuò)誤，沒什么大不了