軟件測(cè)試經(jīng)典面試題總結(jié)文庫(kù)
對(duì)于軟件測(cè)試的人員來(lái)說(shuō),做好面試準(zhǔn)備很重要,那么你了解那些面試題了嗎?下面小編已經(jīng)為你們整理了軟件測(cè)試經(jīng)典面試題,希望可以幫到你。
軟件測(cè)試經(jīng)典面試題(一)
1、為什么要在一個(gè)團(tuán)隊(duì)中開(kāi)展軟件測(cè)試工作?
參考答案:
因?yàn)闆](méi)有經(jīng)過(guò)測(cè)試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量,就好比ISO質(zhì)量認(rèn)證一樣,測(cè)試同樣也需要質(zhì)量的保證,這個(gè)時(shí)候就需要在團(tuán)隊(duì)中開(kāi)展軟件測(cè)試的工作。在測(cè)試的過(guò)程發(fā)現(xiàn)軟件中存在的問(wèn)題,及時(shí)讓開(kāi)發(fā)人員得知并修改問(wèn)題,在即將發(fā)布時(shí),從測(cè)試報(bào)告中得出軟件的質(zhì)量情況。
2、您在以往的測(cè)試工作中都曾經(jīng)具體從事過(guò)哪些工作?其中最擅長(zhǎng)哪部分工作?
參考答案:(根據(jù)項(xiàng)目經(jīng)驗(yàn)不同,靈活回答即可)
我曾經(jīng)做過(guò)web測(cè)試,后臺(tái)測(cè)試,客戶(hù)端軟件,其中包括功能測(cè)試,性能測(cè)試,用戶(hù)體驗(yàn)測(cè)試。最擅長(zhǎng)的是功能測(cè)試
3、您所熟悉的軟件測(cè)試類(lèi)型都有哪些?請(qǐng)?jiān)囍謩e比較這些不同的測(cè)試類(lèi)型的區(qū)別與聯(lián)系(如功能測(cè)試、性能測(cè)試„„)
參考答案:
測(cè)試類(lèi)型有:功能測(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à)類(lèi)劃分、邊界值分析、錯(cuò)誤推測(cè)、因果圖和綜合策略。 性能測(cè)試是通過(guò)自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(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è)試,界面是軟件與用戶(hù)交互的最直接的層,界面的好壞決定用戶(hù)對(duì)軟件的第一印象。而且設(shè)計(jì)良好的界面能夠引導(dǎo)用戶(hù)自己完成相應(yīng)的操作,起到向?qū)У淖饔?。同時(shí)界面如同人的面孔,具有吸引用戶(hù)的直接優(yōu)勢(shì)。設(shè)計(jì)合理的界面能給用戶(hù)帶來(lái)輕松愉悅的感受和成功的感覺(jué),相反由于界面設(shè)計(jì)的失敗,讓用戶(hù)有挫敗感,再實(shí)用強(qiáng)大的功能都可能在用戶(hù)的畏懼與放棄中付諸東流。 區(qū)別在于,功能測(cè)試關(guān)注產(chǎn)品的所有功能上,要考慮到每個(gè)細(xì)節(jié)功能,每個(gè)可能存在的功能問(wèn)題。性能測(cè)試主要關(guān)注于產(chǎn)品整體的多用戶(hù)并發(fā)下的穩(wěn)定性和健壯性。界面測(cè)試更關(guān)注于用戶(hù)體驗(yàn)上,用戶(hù)使用該產(chǎn)品的時(shí)候是否易用,是否易懂,是否規(guī)范(快捷鍵之類(lèi)的),是否美觀(能否吸引用戶(hù)的注意力),是否安全(盡量在前臺(tái)避免用戶(hù)無(wú)意輸入無(wú)效的數(shù)據(jù),當(dāng)然考慮到體驗(yàn)性,不能太粗魯?shù)膹棾鼍??做某個(gè)性能測(cè)試的時(shí)候,首先它可能是個(gè)功能點(diǎn),首先要保證它的功能是沒(méi)問(wèn)題的,然后再考慮該功能點(diǎn)的性能測(cè)試
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)題
軟件測(cè)試經(jīng)典面試題(二)
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è)試方法,保持測(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à)類(lèi)劃分 劃分等價(jià)類(lèi): 等價(jià)類(lèi)是指某個(gè)輸入域的子集合.在該子集合中,各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的.并合理地假定:測(cè)試某等價(jià)類(lèi)的代表值就等于對(duì)這一類(lèi)其它值的測(cè)試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)類(lèi),在每一個(gè)等價(jià)類(lèi)中取一個(gè)數(shù)據(jù)作為測(cè)試的輸入條件,就可以用少量代表性的測(cè)試數(shù)據(jù).取得較好的測(cè)試結(jié)果.等價(jià)類(lèi)劃分可有兩種不同的情況:有效等價(jià)類(lèi)和無(wú)效等價(jià)類(lèi).
02.邊界值分析法 邊界值分析方法是對(duì)等價(jià)類(lèi)劃分方法的補(bǔ)充。測(cè)試工作經(jīng)驗(yàn)告訴我,大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對(duì)各種邊界情況設(shè)計(jì)測(cè)試用例,可以查出更多的錯(cuò)誤. 使用邊界值分析方法設(shè)計(jì)測(cè)試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價(jià)類(lèi)的邊界,就是應(yīng)著重測(cè)試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測(cè)試數(shù)據(jù),而不是選取等價(jià)類(lèi)中的典型值或任意值作為測(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í)曾列出的許多在模塊中常見(jiàn)的錯(cuò)誤. 以前產(chǎn)品測(cè)試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等, 這些就是經(jīng)驗(yàn)的總結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯(cuò)誤的情況. 可選擇這些情況下的例子作為測(cè)試用例.
04.因果圖方法 前面介紹的等價(jià)類(lèi)劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會(huì)產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃分成等價(jià)類(lèi),他們之間的組合情況也相當(dāng)多. 因此必須考慮采用一種適合于描述對(duì)于多種條件的組合,相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來(lái)考慮設(shè)計(jì)測(cè)試用例. 這就需要利用因果圖(邏輯模型). 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.
軟件測(cè)試經(jīng)典面試題(三)
1、你以前工作時(shí)的測(cè)試流程是什么?
參考答案:(靈活回答)
公司對(duì)測(cè)試流程沒(méi)有規(guī)定如何做,但每個(gè)測(cè)試人員都有自己的一套測(cè)試流程。我說(shuō)下我1年來(lái)不斷改正(自己總結(jié),吸取同行的方法)后的流程吧。需求評(píng)審(有開(kāi)發(fā)人員,產(chǎn)品經(jīng)理,測(cè)試人員,項(xiàng)目經(jīng)理)->需求確定(出一份確定的需求文檔)->開(kāi)發(fā)設(shè)計(jì)文檔(開(kāi)發(fā)人員在開(kāi)始寫(xiě)代碼前就能輸出設(shè)計(jì)文檔)->想好測(cè)試策略,寫(xiě)出測(cè)試用例->發(fā)給開(kāi)發(fā)人員和測(cè)試經(jīng)理看看(非正式的評(píng)審用例)->接到測(cè)試版本->執(zhí)行測(cè)試用例(中間可能會(huì)補(bǔ)充用例)->提交bug(有些bug需要開(kāi)發(fā)人員的確定(嚴(yán)重級(jí)別的,或突然發(fā)現(xiàn)的在測(cè)試用例范圍之外的,難以重現(xiàn)的),有些可以直接錄制進(jìn)TD)->開(kāi)發(fā)人員修改(可以在測(cè)試過(guò)程中快速的修改)->回歸測(cè)試(可能又會(huì)發(fā)現(xiàn)新問(wèn)題,再按流程開(kāi)始跑)。
2、當(dāng)開(kāi)發(fā)人員說(shuō)不是BUG時(shí),你如何應(yīng)付?
參考答案: 開(kāi)發(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ù)是什么?如果被用戶(hù)發(fā)現(xiàn)或出了問(wèn)題,會(huì)有什么不良結(jié)果?程序員可能會(huì)給你很多理由,你可以對(duì)他的解釋進(jìn)行反駁。如果還是不行,那我可以給這個(gè)問(wèn)題提出來(lái),跟開(kāi)發(fā)經(jīng)理和測(cè)試經(jīng)理進(jìn)行確認(rèn),如果要修改就改,如果不要修改就不改。其實(shí)有些真的不是bug,我也只是建議的方式寫(xiě)進(jìn)TD中,如果開(kāi)發(fā)人員不修改也沒(méi)有大問(wèn)題。如果確定是bug的話(huà),一定要堅(jiān)持自己的立場(chǎng),讓問(wèn)題得到最后的確認(rèn)。
3、軟件的構(gòu)造號(hào)與版本號(hào)之間的區(qū)別?BVT(BuildVerificationTest)
參考答案:版本控制命名格式: 主版本號(hào).子版本號(hào)[.修正版本號(hào)[.編譯版本號(hào) ]]
Major.Minor [.Revision[.Build]]
應(yīng)根據(jù)下面的約定使用這些部分:
Major :具有相同名稱(chēng)但不同主版本號(hào)的程序集不可互換。例如,這適用于對(duì)產(chǎn)品的大量重寫(xiě),這些重寫(xiě)使得無(wú)法實(shí)現(xiàn)向后兼容性。
Minor :如果兩個(gè)程序集的名稱(chēng)和主版本號(hào)相同,而次版本號(hào)不同,這指示顯著增強(qiáng),但照顧到了向后兼容性。例如,這適用于產(chǎn)品的修正版或完全向后兼容的新版本。
Build :內(nèi)部版本號(hào)的不同表示對(duì)相同源所作的重新編譯。這適合于更改處理器、平臺(tái)或編譯器的情況。 Revision :名稱(chēng)、主版本號(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):這是傳統(tǒng)開(kāi)發(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):能夠模擬用戶(hù)操作完成自動(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)目周期較短且后續(xù)無(wú)延續(xù)性或繼承的情況下,也不推薦使用此方式。3、由開(kāi)發(fā)人員通過(guò)自動(dòng)化測(cè)試工具完成業(yè)務(wù)層的BVT測(cè)試。特點(diǎn):通過(guò)對(duì)業(yè)務(wù)層關(guān)鍵功能的持續(xù)集成測(cè)試,保證系統(tǒng)功能的持續(xù)穩(wěn)定??梢越Y(jié)合DailyBuild,做為Build的一部分,自動(dòng)實(shí)現(xiàn)并輸入BVT報(bào)告。缺點(diǎn):僅對(duì)業(yè)務(wù)規(guī)則實(shí)現(xiàn)的正確性進(jìn)行了測(cè)試,對(duì)表現(xiàn)層無(wú)法測(cè)試到,對(duì)于諸如:前臺(tái)頁(yè)面控件各種事件響應(yīng)、頁(yè)面元素變化等方面的問(wèn)題無(wú)法保證。
看了“軟件測(cè)試經(jīng)典面試題”