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

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

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

　　1)、等價類劃分

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

　　2).邊界值分析法

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

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

　　3).錯誤推測法

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

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

　　4).因果圖方法

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

　　2、軟件的構造號與版本號之間的區別?BVT(BuildVerificationTest)標記

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

　　Major.Minor [.Revision[.Build]]

　　應根據下面的約定使用這些部分：

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

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

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

　　BVT(BuildVerificationTest)：

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

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

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

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

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

　　基于功能的集成：高頻集成\基于進度的集成\基于風險集成\基于事件集成\基于使用的集成\C/S集成

　　2、基于WEB信息管理系統測試時應考慮的因素有哪些?標記

　　參考答案：

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

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

　　4、什么是測試評估?測試評估的范圍是什么?標記

　　參考答案：

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

　　正式驗收測試

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

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

　　正確性：每一項需求都必須準確地陳述其要開發的功能。

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

　　可行性：每一項需求都必須是在已知系統和環境的權能和限制范圍內可以實施的。

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

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

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

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

　　可修改性：每項需求只應在S R S 中出現一次。這樣更改時易于保持一致性。

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

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

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

　　參考答案：su

　　su user1 切換到user1，但切換后的當前目錄還是root訪問的目錄

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

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

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

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

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

　　4、對RUP.CMM,CMMI,XP,PSP.TSP的認識?標記

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

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

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

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

　　CMMI是SEI于2000年發布的CMM的新版本。CMMI不但包括了軟件開發過程改進，還包含系統集成、軟硬件采購等方面的過程改進內容。

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

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

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

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