對于軟件測試的人員來說，做好面試準(zhǔn)備很重要，那么你了解那些面試題了嗎?下面小編已經(jīng)為你們整理了軟件測試經(jīng)典面試題,希望可以幫到你。

　　軟件測試經(jīng)典面試題(一)

　　1、為什么要在一個團(tuán)隊(duì)中開展軟件測試工作?

　　參考答案：

　　因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比ISO質(zhì)量認(rèn)證一樣，測試同樣也需要質(zhì)量的保證，這個時候就需要在團(tuán)隊(duì)中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質(zhì)量情況。

　　2、您在以往的測試工作中都曾經(jīng)具體從事過哪些工作?其中最擅長哪部分工作?

　　參考答案：(根據(jù)項(xiàng)目經(jīng)驗(yàn)不同，靈活回答即可)

　　我曾經(jīng)做過web測試，后臺測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗(yàn)測試。最擅長的是功能測試

　　3、您所熟悉的軟件測試類型都有哪些?請?jiān)囍謩e比較這些不同的測試類型的區(qū)別與聯(lián)系(如功能測試、性能測試„„)

　　參考答案：

　　測試類型有：功能測試，性能測試，界面測試。 功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒

　　測試法進(jìn)行動態(tài)測試時，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術(shù)設(shè)計(jì)測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。 性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。 界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設(shè)計(jì)良好的界面能夠引導(dǎo)用戶自己完成相應(yīng)的操作，起到向?qū)У淖饔谩Ｍ瑫r界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設(shè)計(jì)合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設(shè)計(jì)的失敗，讓用戶有挫敗感，再實(shí)用強(qiáng)大的功能都可能在用戶的畏懼與放棄中付諸東流。 區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能上，要考慮到每個細(xì)節(jié)功能，每個可能存在的功能問題。性能測試主要關(guān)注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試更關(guān)注于用戶體驗(yàn)上，用戶使用該產(chǎn)品的時候是否易用，是否易懂，是否規(guī)范(快捷鍵之類的)，是否美觀(能否吸引用戶的注意力)，是否安全(盡量在前臺避免用戶無意輸入無效的數(shù)據(jù)，當(dāng)然考慮到體驗(yàn)性，不能太粗魯?shù)膹棾鼍??做某個性能測試的時候，首先它可能是個功能點(diǎn)，首先要保證它的功能是沒問題的，然后再考慮該功能點(diǎn)的性能測試

　　4、您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么?

　　參考答案：

　　白盒測試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果 黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題

　　軟件測試經(jīng)典面試題(二)

　　1、測試計(jì)劃工作的目的是什么?測試計(jì)劃工作的內(nèi)容都包括什么?其中哪些是最重要的?

　　參考答案：

　　軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風(fēng)險分析等內(nèi)容。借助軟件測試計(jì)劃，參與測試的項(xiàng)目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實(shí)施過程的順暢溝通，跟蹤和控制測試進(jìn)度，應(yīng)對測試過程中的各種變更。 測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法(最好是能先評審)

　　2、您所熟悉的測試用例設(shè)計(jì)方法都有哪些?請分別以具體的例子來說明這些方法在測試用例設(shè)計(jì)工作中的應(yīng)用。

　　參考答案：

　　01 .等價類劃分 劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

　　02.邊界值分析法 邊界值分析方法是對等價類劃分方法的補(bǔ)充。測試工作經(jīng)驗(yàn)告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計(jì)測試用例,可以查出更多的錯誤. 使用邊界值分析方法設(shè)計(jì)測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價類的邊界,就是應(yīng)著重測試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).

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

　　04.因果圖方法 前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當(dāng)多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應(yīng)產(chǎn)生多個動作的形式來考慮設(shè)計(jì)測試用例. 這就需要利用因果圖(邏輯模型). 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

　　軟件測試經(jīng)典面試題(三)

　　1、你以前工作時的測試流程是什么?

　　參考答案：(靈活回答)

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

　　2、當(dāng)開發(fā)人員說不是BUG時，你如何應(yīng)付?

　　參考答案： 開發(fā)人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產(chǎn)品經(jīng)理進(jìn)行確認(rèn)，需不需要改動，3方商量確定好后再看要不要改。二是這種情況不可能發(fā)生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據(jù)是什么?如果被用戶發(fā)現(xiàn)或出了問題，會有什么不良結(jié)果?程序員可能會給你很多理由，你可以對他的解釋進(jìn)行反駁。如果還是不行，那我可以給這個問題提出來,跟開發(fā)經(jīng)理和測試經(jīng)理進(jìn)行確認(rèn),如果要修改就改,如果不要修改就不改。其實(shí)有些真的不是bug，我也只是建議的方式寫進(jìn)TD中，如果開發(fā)人員不修改也沒有大問題。如果確定是bug的話，一定要堅(jiān)持自己的立場，讓問題得到最后的確認(rèn)。

　　3、軟件的構(gòu)造號與版本號之間的區(qū)別?BVT(BuildVerificationTest)

　　參考答案：版本控制命名格式: 主版本號.子版本號[.修正版本號[.編譯版本號 ]]

　　Major.Minor [.Revision[.Build]]

　　應(yīng)根據(jù)下面的約定使用這些部分：

　　Major ：具有相同名稱但不同主版本號的程序集不可互換。例如，這適用于對產(chǎn)品的大量重寫，這些重寫使得無法實(shí)現(xiàn)向后兼容性。

　　Minor ：如果兩個程序集的名稱和主版本號相同，而次版本號不同，這指示顯著增強(qiáng)，但照顧到了向后兼容性。例如，這適用于產(chǎn)品的修正版或完全向后兼容的新版本。

　　Build ：內(nèi)部版本號的不同表示對相同源所作的重新編譯。這適合于更改處理器、平臺或編譯器的情況。 Revision ：名稱、主版本號和次版本號都相同但修訂號不同的程序集應(yīng)是完全可互換的。這適用于修復(fù)以前發(fā)布的程序集中的安全漏洞。

　　BVT(BuildVerificationTest)：

　　作為Build的一部分，主要是通過對基本功能、特別是關(guān)鍵功能的測試，保證新增代碼沒有導(dǎo)致功能失效，保證版本的持續(xù)穩(wěn)定。實(shí)現(xiàn)BVT方式是有以下幾種：1、測試人員手工驗(yàn)證關(guān)鍵功能實(shí)現(xiàn)的正確性。特點(diǎn)：這是傳統(tǒng)開發(fā)方法中，通常采用的方式。無需維護(hù)測試腳本的成本，在測試人力資源充足，測試人員熟悉業(yè)務(wù)、并對系統(tǒng)操作熟練情況下效率很高，比較靈活快速。缺點(diǎn)：人力成本較高;對測試人員能力有一定要求;測試人員面對重復(fù)的工作，容易產(chǎn)生疲倦懈怠，從而影響測試質(zhì)量。2、借助基于GUI的自動化功能測試工具來完成，將各基本功能操作錄制成測試腳本，每次回放測試腳本驗(yàn)證功能實(shí)現(xiàn)的正確性。特點(diǎn)：能夠模擬用戶操作完成自動的測試，從UI入口到業(yè)務(wù)實(shí)現(xiàn)，每一層的代碼實(shí)現(xiàn)都經(jīng)過驗(yàn)證;節(jié)約人力成本;降低測試人員重復(fù)勞動的工作量，機(jī)器不會疲倦;缺點(diǎn)：對于UI變動比較頻繁的系統(tǒng)來說，這種方式的維護(hù)成本很高，實(shí)施起來非常困難。另外，在項(xiàng)目周期較短且后續(xù)無延續(xù)性或繼承的情況下，也不推薦使用此方式。3、由開發(fā)人員通過自動化測試工具完成業(yè)務(wù)層的BVT測試。特點(diǎn)：通過對業(yè)務(wù)層關(guān)鍵功能的持續(xù)集成測試，保證系統(tǒng)功能的持續(xù)穩(wěn)定?？梢越Y(jié)合DailyBuild，做為Build的一部分，自動實(shí)現(xiàn)并輸入BVT報告。缺點(diǎn)：僅對業(yè)務(wù)規(guī)則實(shí)現(xiàn)的正確性進(jìn)行了測試，對表現(xiàn)層無法測試到，對于諸如：前臺頁面控件各種事件響應(yīng)、頁面元素變化等方面的問題無法保證。

　　
看了“軟件測試經(jīng)典面試題”