在軟件測(cè)試的面試中，我們應(yīng)該學(xué)會(huì)做好面試準(zhǔn)備，那么你知道軟件測(cè)試都問(wèn)哪些問(wèn)題嗎?面小編已經(jīng)為你們整理了軟件測(cè)試面試都問(wèn)的問(wèn)題,一起來(lái)看看吧。

　　軟件測(cè)試面試都問(wèn)的問(wèn)題一

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

　　1)、等價(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).

　　2).邊界值分析法

　　邊界值分析方法是對(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ù).

　　3).錯(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è)試用例.

　　4).因果圖方法

　　前面介紹的等價(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è)試用例. 這就需要利用因果圖(邏輯模型). 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

　　2、軟件的構(gòu)造號(hào)與版本號(hào)之間的區(qū)別?BVT(BuildVerificationTest)標(biāo)記

　　參考答案：版本控制命名格式: 主版本號(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)：能夠模擬用戶操作完成自動(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è)試面試都問(wèn)的問(wèn)題二

　　1、集成測(cè)試通常都有那些策略?

　　基于分解的集成:大爆炸集成\自頂向下集成\自底向上集成\ 三明治集成\

　　基于路徑的集成：分層集成

　　基于功能的集成：高頻集成\基于進(jìn)度的集成\基于風(fēng)險(xiǎn)集成\基于事件集成\基于使用的集成\C/S集成

　　2、基于WEB信息管理系統(tǒng)測(cè)試時(shí)應(yīng)考慮的因素有哪些?標(biāo)記

　　參考答案：

　　3、軟件測(cè)試項(xiàng)目從什么時(shí)候開(kāi)始，?為什么?

　　需求分析開(kāi)始。盡早了解被測(cè)項(xiàng)目。

　　4、什么是測(cè)試評(píng)估?測(cè)試評(píng)估的范圍是什么?標(biāo)記

　　參考答案：

　　5、軟件驗(yàn)收測(cè)試除了alpha ,beta測(cè)試以外,還有哪一種?

　　正式驗(yàn)收測(cè)試

　　6、需求測(cè)試注意事項(xiàng)有哪些?

　　完整性：每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，以使開(kāi)發(fā)人員獲得設(shè)計(jì)和實(shí)現(xiàn)這些功能所需的所有必要信息。

　　正確性：每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開(kāi)發(fā)的功能。

　　一致性：一致性是指與其它軟件需求或高層(系統(tǒng)，業(yè)務(wù))需求不相矛盾。

　　可行性：每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。

　　無(wú)二義性：對(duì)所有需求說(shuō)明的讀者都只能有一個(gè)明確統(tǒng)一的解釋?zhuān)捎谧匀徽Z(yǔ)言極易導(dǎo)致二義性，所以盡量把每項(xiàng)需求用簡(jiǎn)潔明了的用戶性的語(yǔ)言表達(dá)出來(lái)。

　　健壯性：需求的說(shuō)明中是否對(duì)可能出現(xiàn)的異常進(jìn)行了分析，并且對(duì)這些異常進(jìn)行了容錯(cuò)處理。

　　必要性："必要性"可以理解為每項(xiàng)需求都是用來(lái)授權(quán)你編寫(xiě)文檔的"根源"。要使每項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入，如Use Case或別的來(lái)源。

　　可測(cè)試性：每項(xiàng)需求都能通過(guò)設(shè)計(jì)測(cè)試用例或其它的驗(yàn)證方法來(lái)進(jìn)行測(cè)試。

　　可修改性：每項(xiàng)需求只應(yīng)在S R S 中出現(xiàn)一次。這樣更改時(shí)易于保持一致性。

　　可跟蹤性：應(yīng)能在每項(xiàng)軟件需求與它的根源和設(shè)計(jì)元素、源代碼、測(cè)試用例之間建立起鏈接鏈，這種可跟蹤性要求每項(xiàng)需求以一種結(jié)構(gòu)化的，粒度好(f i n e - g r a i n e d )的方式編寫(xiě)并單獨(dú)標(biāo)明，

　　軟件測(cè)試面試都問(wèn)的問(wèn)題三

　　1、在RedHat中，從root用戶切到userl用戶，一般用什么命令?

　　參考答案：su

　　su user1 切換到user1，但切換后的當(dāng)前目錄還是root訪問(wèn)的目錄

　　su – user1 切換到user1，并且當(dāng)前目錄切換到user1的根目錄下(/home/user1/)

　　2、Linux中，一般怎么隱藏文件?

　　參考答案：文件名以一個(gè).開(kāi)頭

　　3、如何將自己的本地磁盤(pán)(D)做成FTP供遠(yuǎn)端主機(jī)使用?

　　參考答案：Windows下安裝FTP服務(wù)，并將FTP的根目錄指向D盤(pán)即可。

　　4、對(duì)RUP.CMM,CMMI,XP,PSP.TSP的認(rèn)識(shí)?標(biāo)記

　　參考答案：軟件過(guò)程標(biāo)準(zhǔn)：CMMI、PSP、TSP、RUP、軟件工程規(guī)范國(guó)家標(biāo)準(zhǔn);(AP、XP、ASD等開(kāi)發(fā)過(guò)程思想好像還不能稱(chēng)其為標(biāo)準(zhǔn))

　　RUP(Rational Unified Process)是Rational公司提出的一套開(kāi)發(fā)過(guò)程模型，它是一個(gè)面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程。它描述了一系列相關(guān)的軟件工程流程，它們具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。RUP 為在開(kāi)發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計(jì)的時(shí)間安排和預(yù)算內(nèi)開(kāi)發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。RUP具有兩個(gè)軸，一個(gè)軸是時(shí)間軸，這是動(dòng)態(tài)的。另一個(gè)軸是工作流軸，這是靜態(tài)的。在時(shí)間軸上，RUP劃分了四個(gè)階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個(gè)階段都使用了迭代的概念。在工作流軸上，RUP設(shè)計(jì)了六個(gè)核心工作流程和三個(gè)核心支撐工作流程，核心工作流軸包括：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計(jì)工作流、實(shí)現(xiàn)工作流、測(cè)試工作流和發(fā)布工作流。核心支撐工作流包括：環(huán)境工作流、項(xiàng)目管理工作流和配置與變更管理工作流。RUP 匯集現(xiàn)代軟件開(kāi)發(fā)中多方面的最佳經(jīng)驗(yàn)，并為適應(yīng)各種項(xiàng)目及組織的需要提供了靈活的形式。作為一個(gè)商業(yè)模型，它具有非常詳細(xì)的過(guò)程指導(dǎo)和模板。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要花費(fèi)比較大的成本。尤其對(duì)項(xiàng)目管理者提出了比較高的要求。

　　CMM(Capability Maturity Model能力成熟度模型) 由美國(guó)卡內(nèi)基-梅隆大學(xué)的軟件工程研究所(簡(jiǎn)稱(chēng)SEI)受美國(guó)國(guó)防部委托，于1991年研究制定，初始的主要目的是為了評(píng)價(jià)美國(guó)國(guó)防部的軟件合同承包組織的能力，后因?yàn)樵谲浖髽I(yè)應(yīng)用CMM模型實(shí)施過(guò)程改進(jìn)取得較大的成功，所以在全世界范圍內(nèi)被廣泛使用，SEI同時(shí)建立了主任評(píng)估師評(píng)估制度，CMM的評(píng)估方法為CBA-IPI。CMM的本質(zhì)是軟件管理工程的一個(gè)部分。它是對(duì)于軟件組織在定義，實(shí)現(xiàn)，度量，控制和改善其軟件過(guò)程的進(jìn)程中各個(gè)發(fā)展階段的描述。他通過(guò)5個(gè)不斷進(jìn)化的層次來(lái)評(píng)定軟件生產(chǎn)的歷史與現(xiàn)狀：初始層是混沌的過(guò)程;可重復(fù)層是經(jīng)過(guò)訓(xùn)練的軟件過(guò)程;定義層是標(biāo)準(zhǔn)一致的軟件過(guò)程;管理層是可預(yù)測(cè)的軟件過(guò)程;優(yōu)化層是能持續(xù)改善的軟件過(guò)程。

　　CMM/PSP/TSP即軟件能力成熟度模型/ 個(gè)體軟件過(guò)程/群組軟件過(guò)程，是1987年美國(guó) Carnegie Mellon 大學(xué)軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發(fā)表的研究成果"承制方軟件工程能力的評(píng)估方法"。

　　CMMI是SEI于2000年發(fā)布的CMM的新版本。CMMI不但包括了軟件開(kāi)發(fā)過(guò)程改進(jìn)，還包含系統(tǒng)集成、軟硬件采購(gòu)等方面的過(guò)程改進(jìn)內(nèi)容。

　　CMMI糾正了CMM存在的一些缺點(diǎn)，使其更加適用企業(yè)的過(guò)程改進(jìn)實(shí)施。CMMI適用SCAMPI評(píng)估方法。需要注意的是，SEI沒(méi)有廢除CMM模型，只是停止了CMM評(píng)估方法：CBA-IPI?，F(xiàn)在如要進(jìn)行CMM評(píng)估，需使用SCAMPI方法。但CMMI模型最終代替CMM模型的趨勢(shì)不可避免。

　　XP (極限編程)規(guī)定了一組核心價(jià)值和方法，可以讓軟件開(kāi)發(fā)人員發(fā)揮他們的專(zhuān)長(zhǎng)：編寫(xiě)代碼。XP 消除了大多數(shù)重量型過(guò)程的不必要產(chǎn)物，通過(guò)減慢開(kāi)發(fā)速度、耗費(fèi)開(kāi)發(fā)人員的精力(例如干特圖、狀態(tài)報(bào)告，以及多卷需求文檔)從目標(biāo)偏離。

　　XP 的核心價(jià)值：交流、簡(jiǎn)單、反饋、勇氣。

　　
看了“軟件測(cè)試面試都問(wèn)的問(wèn)題”