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

　　軟件測試經典面試題(一)

　　1、為什么要在一個團隊中開展軟件測試工作?

　　參考答案：

　　因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測試報告中得出軟件的質量情況。

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

　　參考答案：(根據項目經驗不同，靈活回答即可)

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

　　3、您所熟悉的軟件測試類型都有哪些?請試著分別比較這些不同的測試類型的區別與聯系(如功能測試、性能測試„„)

　　參考答案：

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

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

　　4、您認為做好測試用例設計工作的關鍵是什么?

　　參考答案：

　　白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果 黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題

　　軟件測試經典面試題(二)

　　1、測試計劃工作的目的是什么?測試計劃工作的內容都包括什么?其中哪些是最重要的?

　　參考答案：

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

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

　　參考答案：

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

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

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

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

　　軟件測試經典面試題(三)

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

　　參考答案：(靈活回答)

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

　　2、當開發人員說不是BUG時，你如何應付?

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

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

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

　　Major.Minor [.Revision[.Build]]

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

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

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

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

　　BVT(BuildVerificationTest)：

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

　　
看了“軟件測試經典面試題”