軟件測(cè)試經(jīng)典面試題總結(jié)文庫(kù)

1、軟件測(cè)試經(jīng)典面試題總結(jié)文庫(kù)對(duì)于軟件測(cè)試的人員來(lái)說(shuō)，做好面試準(zhǔn)備很重要，那么你了解 那些面試題了嗎 ?下面已經(jīng)為你們了軟件測(cè)試經(jīng)典面試題 , 希望可以 幫到你。1 、為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測(cè)試工作 ?參考答案： 因?yàn)闆](méi)有經(jīng)過(guò)測(cè)試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量， 就好比ISO質(zhì)量認(rèn)證一樣，測(cè)試同樣也需要質(zhì)量的保證，這個(gè)時(shí)候就 需要在團(tuán)隊(duì)中開展軟件測(cè)試的工作。 在測(cè)試的過(guò)程發(fā)現(xiàn)軟件中存在的 問(wèn)題，及時(shí)讓開發(fā)人員得知并修改問(wèn)題，在即將發(fā)布時(shí)，從測(cè)試報(bào)告 中得出軟件的質(zhì)量情況。2 、您在以往的測(cè)試工作中都曾經(jīng)具體從事過(guò)哪些工作 ?其中最 擅長(zhǎng)哪部分工作 ?參考答案： （ 根據(jù)項(xiàng)目經(jīng)驗(yàn)不同，靈

2、活回答即可 ）我曾經(jīng)做過(guò)web測(cè)試，后臺(tái)測(cè)試，客戶端軟件，其中包括功能測(cè)試，性能測(cè)試，用戶體驗(yàn)測(cè)試。最擅長(zhǎng)的是功能測(cè)試3 、您所熟悉的軟件測(cè)試類型都有哪些 ?請(qǐng)?jiān)囍謩e比較這些不 同的測(cè)試類型的區(qū)別與聯(lián)系 （如功能測(cè)試、性能測(cè)試 ?）參考答案：測(cè)試類型有：功能測(cè)試，性能測(cè)試，界面測(cè)試。功能測(cè)試在測(cè)試工作中占的比例最大， 功能測(cè)試也叫黑盒測(cè)試。 是把測(cè)試對(duì)象看作 一個(gè)黑盒子。利用黑盒測(cè)試法進(jìn)行動(dòng)態(tài)測(cè)試時(shí)，需要測(cè)試軟件產(chǎn)品的功能，不需測(cè)試 軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過(guò)程。 采用黑盒技術(shù)設(shè)計(jì)測(cè)試用例的方法 有：等價(jià)類劃分、邊界值分析、錯(cuò)誤推測(cè)、因果圖和綜合策略。性能 測(cè)試是通過(guò)自動(dòng)化的測(cè)試工具模擬多種

3、正常、 峰值以及異常負(fù)載條件 來(lái)對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。 負(fù)載測(cè)試和壓力測(cè)試都屬于性能 測(cè)試，兩者可以結(jié)合進(jìn)行。 通過(guò)負(fù)載測(cè)試，確定在各種工作負(fù)載下系 統(tǒng)的性能， 目標(biāo)是測(cè)試當(dāng)負(fù)載逐漸增加時(shí)， 系統(tǒng)各項(xiàng)性能指標(biāo)的變化 情況。壓力測(cè)試是通過(guò)確定一個(gè)系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)， 來(lái)獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測(cè)試。 界面測(cè)試， 界面是軟件與 用戶交互的最直接的層， 界面的好壞決定用戶對(duì)軟件的第一印象。 而 且設(shè)計(jì)良好的界面能夠引導(dǎo)用戶自己完成相應(yīng)的操作， 起到向?qū)У淖?用。同時(shí)界面如同人的面孔，具有吸引用戶的直接優(yōu)勢(shì)。設(shè)計(jì)合理的 界面能給用戶帶來(lái)輕松愉悅的感受和成功的感覺(jué)， 相反由于界

4、面設(shè)計(jì) 的失敗，讓用戶有挫敗感， 再實(shí)用強(qiáng)大的功能都可能在用戶的畏懼與 放棄中付諸東流。區(qū)別在于，功能測(cè)試關(guān)注產(chǎn)品的所有功能上，要考 慮到每個(gè)細(xì)節(jié)功能， 每個(gè)可能存在的功能問(wèn)題。 性能測(cè)試主要關(guān)注于 產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。 界面測(cè)試更關(guān)注于用戶 體驗(yàn)上，用戶使用該產(chǎn)品的時(shí)候是否易用，是否易懂，是否規(guī)范 （ 快 捷鍵之類的 ） ，是否美觀 （能否吸引用戶的注意力 ） ，是否安全 （盡量在 前臺(tái)避免用戶無(wú)意輸入無(wú)效的數(shù)據(jù)， 當(dāng)然考慮到體驗(yàn)性， 不能太粗魯 的彈出警告 ）? 做某個(gè)性能測(cè)試的時(shí)候， 首先它可能是個(gè)功能點(diǎn)， 首先 要保證它的功能是沒(méi)問(wèn)題的，然后再考慮該功能點(diǎn)的性能測(cè)試

5、4 、您認(rèn)為做好測(cè)試用例設(shè)計(jì)工作的關(guān)鍵是什么 ?參考答案： 白盒測(cè)試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部 程序邏輯結(jié)果黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模 塊輸出和輸入接口。 不可能做到完全測(cè)試， 以最少的用例在合理的時(shí) 間內(nèi)發(fā)現(xiàn)最多的問(wèn)題1 、測(cè)試計(jì)劃工作的目的是什么 ?測(cè)試計(jì)劃工作的內(nèi)容都包括什 么 ?其中哪些是最重要的 ?參考答案：軟件測(cè)試計(jì)劃是指導(dǎo)測(cè)試過(guò)程的綱領(lǐng)性文件， 包含了產(chǎn)品概述、 測(cè)試策略、測(cè)試方法、測(cè)試區(qū)域、測(cè)試配置、測(cè)試周期、測(cè)試資源、 測(cè)試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測(cè)試計(jì)劃，參與測(cè)試的項(xiàng)目成 員，尤其是測(cè)試管理人員， 可以明確測(cè)試任務(wù)和測(cè)試方法，保

6、持測(cè)試 實(shí)施過(guò)程的順暢溝通， 跟蹤和控制測(cè)試進(jìn)度， 應(yīng)對(duì)測(cè)試過(guò)程中的各種 變更。測(cè)試計(jì)劃和測(cè)試詳細(xì)規(guī)格、 測(cè)試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系， 測(cè)試計(jì)劃主要從宏觀上規(guī)劃測(cè)試活動(dòng)的范圍、 方法和資源配置， 而測(cè) 試詳細(xì)規(guī)格、 測(cè)試用例是完成測(cè)試任務(wù)的具體戰(zhàn)術(shù)。 所以其中最重要 的是測(cè)試測(cè)試策略和測(cè)試方法 （ 最好是能先評(píng)審 ）2 、您所熟悉的測(cè)試用例設(shè)計(jì)方法都有哪些 ?請(qǐng)分別以具體的例 子來(lái)說(shuō)明這些方法在測(cè)試用例設(shè)計(jì)工作中的應(yīng)用。參考答案：01. 等價(jià)類劃分劃分等價(jià)類 : 等價(jià)類是指某個(gè)輸入域的子集合 在該子集合中 ,各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的 . 并 合理地假定 : 測(cè)試某等價(jià)類的

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

8、當(dāng)選取正好等于 , 剛剛大于或剛剛小于邊界的值作為測(cè) 試數(shù)據(jù), 而不是選取等價(jià)類中的典型值或任意值作為測(cè)試數(shù)據(jù) .03. 錯(cuò)誤推測(cè)法基于經(jīng)驗(yàn)和直覺(jué)推測(cè)程序中所有可能存在的各 種錯(cuò)誤,從而有針對(duì)性的設(shè)計(jì)測(cè)試用例的方法 . 錯(cuò)誤推測(cè)方法的基本 思想: 列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況 , 根據(jù)他們選擇測(cè)試用例 .例如, 在單元測(cè)試時(shí)曾列出的許多在模塊中 常見的錯(cuò)誤 . 以前產(chǎn)品測(cè)試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等 , 這些就是經(jīng)驗(yàn)的總 結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況. 輸入表格為空格或輸入表 格只有一行 . 這些都是容易發(fā)生錯(cuò)誤的情況 .可選擇這些情況下的例子作為測(cè)試用例 .

9、04. 因果圖方法前面介紹的等價(jià)類劃分方法和邊界值分析方法 都是著重考慮輸入條件 , 但未考慮輸入條件之間的聯(lián)系 , 相互組合等 . 考慮輸入條件之間的相互組合 ,可能會(huì)產(chǎn)生一些新的情況 . 但要檢查 輸入條件的組合不是一件容易的事情 , 即使把所有輸入條件劃分成等 價(jià)類,他們之間的組合情況也相當(dāng)多 . 因此必須考慮采用一種適合于 描述對(duì)于多種條件的組合 , 相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來(lái)考慮設(shè)計(jì)測(cè)試 用例.這就需要利用因果圖 （邏輯模型）. 因果圖方法最終生成的就是 判定表 . 它適合于檢查程序輸入條件的各種組合情況 .1 、你以前工作時(shí)的測(cè)試流程是什么 ?參考答案： （靈活回答 ） 公司對(duì)測(cè)試流

10、程沒(méi)有規(guī)定如何做，但每個(gè)測(cè)試人員都有自己的 一套測(cè)試流程。我說(shuō)下我 1年來(lái)不斷改正 （自己總結(jié)，吸取同行的方 法）后的流程吧。需求評(píng)審 （ 有開發(fā)人員，產(chǎn)品經(jīng)理，測(cè)試人員，項(xiàng)目 經(jīng)理）-需求確定（出一份確定的需求文檔 ）-開發(fā)設(shè)計(jì)文檔 （開發(fā)人 員在開始寫代碼前就能輸出設(shè)計(jì)文檔 ）- 想好測(cè)試策略，寫出測(cè)試用 例-發(fā)給開發(fā)人員和測(cè)試經(jīng)理看看 （ 非正式的評(píng)審用例 ）- 接到測(cè)試 版本-執(zhí)行測(cè)試用例（中間可能會(huì)補(bǔ)充用例）- 提交bug（有些bug需 要開發(fā)人員的確定 （嚴(yán)重級(jí)別的，或突然發(fā)現(xiàn)的在測(cè)試用例范圍之外 的，難以重現(xiàn)的），有些可以直接錄制進(jìn)TD）-開發(fā)人員修改（可以在 測(cè)試過(guò)程中快速的修

11、改 ）-回歸測(cè)試（可能又會(huì)發(fā)現(xiàn)新問(wèn)題， 再按流程 開始跑）。2 、當(dāng)開發(fā)人員說(shuō)不是BUG時(shí)，你如何應(yīng)付？參考答案：開發(fā)人員說(shuō)不是bug,有2種情況，一是需求沒(méi)有確定，所以我可以這么做， 這個(gè)時(shí)候可以找來(lái)產(chǎn)品經(jīng)理進(jìn)行確認(rèn)，需 不需要改動(dòng), 3 方商量確定好后再看要不要改。二是這種情況不可能 發(fā)生，所以不需要修改，這個(gè)時(shí)候，我可以先盡可能的說(shuō)出是 BUG勺 依據(jù)是什么 ?如果被用戶發(fā)現(xiàn)或出了問(wèn)題, 會(huì)有什么不良結(jié)果 ?程序員 可能會(huì)給你很多理由,你可以對(duì)他的解釋進(jìn)行反駁。如果還是不行, 那我可以給這個(gè)問(wèn)題提出來(lái) ,跟開發(fā)經(jīng)理和測(cè)試經(jīng)理進(jìn)行確認(rèn) , 如果 要修改就改，如果不要修改就不改。其實(shí)有些真的

12、不是 bug，我也只 是建議的方式寫進(jìn)TD中，如果開發(fā)人員不修改也沒(méi)有大問(wèn)題。如果 確定是 bug 的話,一定要堅(jiān)持自己的立場(chǎng),讓問(wèn)題得到最后的確認(rèn)。3 、軟件的構(gòu)造號(hào)與版本號(hào)之間的區(qū)別？BVT(BuildVerificatio nTest)參考答案：版本控制命名格式 : 主版本號(hào) . 子版本號(hào) . 修正版本 號(hào) . 編譯版本號(hào) Major.Minor.Revision.Build應(yīng)根據(jù)下面的約定使用這些部分：Major ：具有相同名稱但不同主版本號(hào)的程序集不可互換。 例如, 這適用于對(duì)產(chǎn)品的大量重寫,這些重寫使得無(wú)法實(shí)現(xiàn)向后兼容性。Minor ：如果兩個(gè)程序集的名稱和主版本號(hào)相同, 而次版本

13、號(hào)不 同,這指示顯著增強(qiáng),但照顧到了向后兼容性。例如,這適用于產(chǎn)品 的修正版或完全向后兼容的新版本。Build ：內(nèi)部版本號(hào)的不同表示對(duì)相同源所作的重新編譯。 這適 合于更改處理器、平臺(tái)或編譯器的情況。 Revision ：名稱、主版本號(hào) 和次版本號(hào)都相同但修訂號(hào)不同的程序集應(yīng)是完全可互換的。 這適用 于修復(fù)以前發(fā)布的程序集中的安全漏洞。BVT(BuildVerificationTest) ： 作為 Build 的一部分，主要是通過(guò)對(duì)基本功能、特別是關(guān)鍵功 能的測(cè)試，保證新增代碼沒(méi)有導(dǎo)致功能失效，保證版本的持續(xù)穩(wěn)定。 實(shí)現(xiàn)BVT方式是有以下幾種：1、測(cè)試人員手工驗(yàn)證關(guān)鍵功能實(shí)現(xiàn)的 正確性。特點(diǎn)

14、：這是傳統(tǒng)開發(fā)方法中，通常采用的方式。無(wú)需維護(hù)測(cè) 試腳本的成本，在測(cè)試人力資源充足，測(cè)試人員熟悉業(yè)務(wù)、并對(duì)系統(tǒng) 操作熟練情況下效率很高，比較靈活快速。缺點(diǎn)：人力成本較高 ; 對(duì) 測(cè)試人員能力有一定要求 ; 測(cè)試人員面對(duì)重復(fù)的工作，容易產(chǎn)生疲倦 懈怠，從而影響測(cè)試質(zhì)量。2、借助基于GUI的自動(dòng)化功能測(cè)試工具 來(lái)完成，將各基本功能操作錄制成測(cè)試腳本， 每次回放測(cè)試腳本驗(yàn)證 功能實(shí)現(xiàn)的正確性。特點(diǎn)：能夠模擬用戶操作完成自動(dòng)的測(cè)試，從 UI 入口到業(yè)務(wù)實(shí)現(xiàn)，每一層的代碼實(shí)現(xiàn)都經(jīng)過(guò)驗(yàn)證 ;節(jié)約人力成本 ; 降低測(cè)試人員重復(fù)勞動(dòng)的工作量， 機(jī)器不會(huì)疲倦 ;缺點(diǎn)：對(duì)于 UI 變動(dòng) 比較頻繁的系統(tǒng)來(lái)說(shuō)， 這種方式的維護(hù)成本很高， 實(shí)施起來(lái)非常困難。 另外，在項(xiàng)目周期較