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

　　軟件測試面試都問的問題一

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

　　1)、等價類劃分

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

　　2).邊界值分析法

　　邊界值分析方法是對等價類劃分方法的補(bǔ)充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計測試用例,可以查出更多的錯誤.

　　使用邊界值分析方法設(shè)計測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價類的邊界,就是應(yīng)著重測試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).

　　3).錯誤推測法

　　基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè)計測試用例的方法.

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

　　4).因果圖方法

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

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

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

　　Major.Minor [.Revision[.Build]]

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

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

　　軟件測試面試都問的問題二

　　1、集成測試通常都有那些策略?

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

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

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

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

　　參考答案：

　　3、軟件測試項目從什么時候開始，?為什么?

　　需求分析開始。盡早了解被測項目。

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

　　參考答案：

　　5、軟件驗收測試除了alpha ,beta測試以外,還有哪一種?

　　正式驗收測試

　　6、需求測試注意事項有哪些?

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

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

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

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

　　無二義性：對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達(dá)出來。

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

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

　　可測試性：每項需求都能通過設(shè)計測試用例或其它的驗證方法來進(jìn)行測試。

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

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

　　軟件測試面試都問的問題三

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

　　參考答案：su

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

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

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

　　參考答案：文件名以一個.開頭

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

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

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

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

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

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

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

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

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

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

　　XP 的核心價值：交流、簡單、反饋、勇氣。

　　
看了“軟件測試面試都問的問題”