軟件測試經典面試題總結文庫

1、軟件測試經典面試題總結文庫對于軟件測試的人員來說，做好面試準備很重要，那么你了解 那些面試題了嗎 ?下面已經為你們了軟件測試經典面試題 , 希望可以 幫到你。1 、為什么要在一個團隊中開展軟件測試工作 ?參考答案： 因為沒有經過測試的軟件很難在發(fā)布之前知道該軟件的質量， 就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就 需要在團隊中開展軟件測試的工作。 在測試的過程發(fā)現(xiàn)軟件中存在的 問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告 中得出軟件的質量情況。2 、您在以往的測試工作中都曾經具體從事過哪些工作 ?其中最 擅長哪部分工作 ?參考答案： （ 根據(jù)項目經驗不同，靈

2、活回答即可 ）我曾經做過web測試，后臺測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試3 、您所熟悉的軟件測試類型都有哪些 ?請試著分別比較這些不 同的測試類型的區(qū)別與聯(lián)系 （如功能測試、性能測試 ?）參考答案：測試類型有：功能測試，性能測試，界面測試。功能測試在測試工作中占的比例最大， 功能測試也叫黑盒測試。 是把測試對象看作 一個黑盒子。利用黑盒測試法進行動態(tài)測試時，需要測試軟件產品的功能，不需測試 軟件產品的內部結構和處理過程。 采用黑盒技術設計測試用例的方法 有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。性能 測試是通過自動化的測試工具模擬多種

3、正常、 峰值以及異常負載條件 來對系統(tǒng)的各項性能指標進行測試。 負載測試和壓力測試都屬于性能 測試，兩者可以結合進行。 通過負載測試，確定在各種工作負載下系 統(tǒng)的性能， 目標是測試當負載逐漸增加時， 系統(tǒng)各項性能指標的變化 情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點， 來獲得系統(tǒng)能提供的最大服務級別的測試。 界面測試， 界面是軟件與 用戶交互的最直接的層， 界面的好壞決定用戶對軟件的第一印象。 而 且設計良好的界面能夠引導用戶自己完成相應的操作， 起到向導的作 用。同時界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設計合理的 界面能給用戶帶來輕松愉悅的感受和成功的感覺， 相反由于界

4、面設計 的失敗，讓用戶有挫敗感， 再實用強大的功能都可能在用戶的畏懼與 放棄中付諸東流。區(qū)別在于，功能測試關注產品的所有功能上，要考 慮到每個細節(jié)功能， 每個可能存在的功能問題。 性能測試主要關注于 產品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。 界面測試更關注于用戶 體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規(guī)范 （ 快 捷鍵之類的 ） ，是否美觀 （能否吸引用戶的注意力 ） ，是否安全 （盡量在 前臺避免用戶無意輸入無效的數(shù)據(jù)， 當然考慮到體驗性， 不能太粗魯 的彈出警告 ）? 做某個性能測試的時候， 首先它可能是個功能點， 首先 要保證它的功能是沒問題的，然后再考慮該功能點的性能測試

5、4 、您認為做好測試用例設計工作的關鍵是什么 ?參考答案： 白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部 程序邏輯結果黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模 塊輸出和輸入接口。 不可能做到完全測試， 以最少的用例在合理的時 間內發(fā)現(xiàn)最多的問題1 、測試計劃工作的目的是什么 ?測試計劃工作的內容都包括什 么 ?其中哪些是最重要的 ?參考答案：軟件測試計劃是指導測試過程的綱領性文件， 包含了產品概述、 測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、 測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成 員，尤其是測試管理人員， 可以明確測試任務和測試方法，保

6、持測試 實施過程的順暢溝通， 跟蹤和控制測試進度， 應對測試過程中的各種 變更。測試計劃和測試詳細規(guī)格、 測試用例之間是戰(zhàn)略和戰(zhàn)術的關系， 測試計劃主要從宏觀上規(guī)劃測試活動的范圍、 方法和資源配置， 而測 試詳細規(guī)格、 測試用例是完成測試任務的具體戰(zhàn)術。 所以其中最重要 的是測試測試策略和測試方法 （ 最好是能先評審 ）2 、您所熟悉的測試用例設計方法都有哪些 ?請分別以具體的例 子來說明這些方法在測試用例設計工作中的應用。參考答案：01. 等價類劃分劃分等價類 : 等價類是指某個輸入域的子集合 在該子集合中 ,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的 . 并 合理地假定 : 測試某等價類的

7、代表值就等于對這一類其它值的測試 . 因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類 , 在每一個等價類 中取一個數(shù)據(jù)作為測試的輸入條件 , 就可以用少量代表性的測試數(shù)據(jù) 取得較好的測試結果 .等價類劃分可有兩種不同的情況 : 有效等價類 和無效等價類 .02. 邊界值分析法邊界值分析方法是對等價類劃分方法的補充。 測試工作經驗告訴我 , 大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上 而不是發(fā)生在輸入輸出范圍的內部 . 因此針對各種邊界情況設計測試 用例,可以查出更多的錯誤 . 使用邊界值分析方法設計測試用例 ,首先 應確定邊界情況 . 通常輸入和輸出等價類的邊界 , 就是應著重測試的 邊界情況.應

8、當選取正好等于 , 剛剛大于或剛剛小于邊界的值作為測 試數(shù)據(jù), 而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù) .03. 錯誤推測法基于經驗和直覺推測程序中所有可能存在的各 種錯誤,從而有針對性的設計測試用例的方法 . 錯誤推測方法的基本 思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況 , 根據(jù)他們選擇測試用例 .例如, 在單元測試時曾列出的許多在模塊中 常見的錯誤 . 以前產品測試中曾經發(fā)現(xiàn)的錯誤等 , 這些就是經驗的總 結. 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況. 輸入表格為空格或輸入表 格只有一行 . 這些都是容易發(fā)生錯誤的情況 .可選擇這些情況下的例子作為測試用例 .

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

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

11、改 ）-回歸測試（可能又會發(fā)現(xiàn)新問題， 再按流程 開始跑）。2 、當開發(fā)人員說不是BUG時，你如何應付？參考答案：開發(fā)人員說不是bug,有2種情況，一是需求沒有確定，所以我可以這么做， 這個時候可以找來產品經理進行確認，需 不需要改動, 3 方商量確定好后再看要不要改。二是這種情況不可能 發(fā)生，所以不需要修改，這個時候，我可以先盡可能的說出是 BUG勺 依據(jù)是什么 ?如果被用戶發(fā)現(xiàn)或出了問題, 會有什么不良結果 ?程序員 可能會給你很多理由,你可以對他的解釋進行反駁。如果還是不行, 那我可以給這個問題提出來 ,跟開發(fā)經理和測試經理進行確認 , 如果 要修改就改，如果不要修改就不改。其實有些真的

12、不是 bug，我也只 是建議的方式寫進TD中，如果開發(fā)人員不修改也沒有大問題。如果 確定是 bug 的話,一定要堅持自己的立場,讓問題得到最后的確認。3 、軟件的構造號與版本號之間的區(qū)別？BVT(BuildVerificatio nTest)參考答案：版本控制命名格式 : 主版本號 . 子版本號 . 修正版本 號 . 編譯版本號 Major.Minor.Revision.Build應根據(jù)下面的約定使用這些部分：Major ：具有相同名稱但不同主版本號的程序集不可互換。 例如, 這適用于對產品的大量重寫,這些重寫使得無法實現(xiàn)向后兼容性。Minor ：如果兩個程序集的名稱和主版本號相同, 而次版本

13、號不 同,這指示顯著增強,但照顧到了向后兼容性。例如,這適用于產品 的修正版或完全向后兼容的新版本。Build ：內部版本號的不同表示對相同源所作的重新編譯。 這適 合于更改處理器、平臺或編譯器的情況。 Revision ：名稱、主版本號 和次版本號都相同但修訂號不同的程序集應是完全可互換的。 這適用 于修復以前發(fā)布的程序集中的安全漏洞。BVT(BuildVerificationTest) ： 作為 Build 的一部分，主要是通過對基本功能、特別是關鍵功 能的測試，保證新增代碼沒有導致功能失效，保證版本的持續(xù)穩(wěn)定。 實現(xiàn)BVT方式是有以下幾種：1、測試人員手工驗證關鍵功能實現(xiàn)的 正確性。特點

14、：這是傳統(tǒng)開發(fā)方法中，通常采用的方式。無需維護測 試腳本的成本，在測試人力資源充足，測試人員熟悉業(yè)務、并對系統(tǒng) 操作熟練情況下效率很高，比較靈活快速。缺點：人力成本較高 ; 對 測試人員能力有一定要求 ; 測試人員面對重復的工作，容易產生疲倦 懈怠，從而影響測試質量。2、借助基于GUI的自動化功能測試工具 來完成，將各基本功能操作錄制成測試腳本， 每次回放測試腳本驗證 功能實現(xiàn)的正確性。特點：能夠模擬用戶操作完成自動的測試，從 UI 入口到業(yè)務實現(xiàn)，每一層的代碼實現(xiàn)都經過驗證 ;節(jié)約人力成本 ; 降低測試人員重復勞動的工作量， 機器不會疲倦 ;缺點：對于 UI 變動 比較頻繁的系統(tǒng)來說， 這種方式的維護成本很高， 實施起來非常困難。 另外，在項目周期較