- 相關(guān)推薦
常見(jiàn)軟件測試面試題
在各領(lǐng)域中，我們很多時(shí)候都會(huì )有考試，接觸到試題，試題可以幫助主辦方了解考生某方面的知識或技能狀況。還在為找參考試題而苦惱嗎？以下是小編整理的常見(jiàn)軟件測試面試題，希望能夠幫助到大家。
常見(jiàn)軟件測試面試題
問(wèn)題一：為什么要在一個(gè)團隊中開(kāi)展軟件測試工作?
任何軟件在開(kāi)發(fā)過(guò)程中都會(huì )留下缺陷，帶有缺陷的軟件產(chǎn)品如果提交出去，可能會(huì )給公司帶來(lái)不可估量的損失，我們必須在客戶(hù)之前發(fā)現盡可能多的問(wèn)題，從而保障客戶(hù)滿(mǎn)意。而發(fā)現問(wèn)題的這個(gè)過(guò)程稱(chēng)之為測試。
問(wèn)題二：簡(jiǎn)述你在以前的工作中做過(guò)哪些事情，比較熟悉什么。
此問(wèn)題每個(gè)人都不一樣。我自己的答案如下。
我主要的工作是系統測試和自動(dòng)化測試，也曾少量涉及性能測試。在系統測試中，主要是對BOSS系統的業(yè)務(wù)邏輯功能，以及軟交換系統的Class 5特性進(jìn)行測試。性能測試中，主要是進(jìn)行的壓力測試，在各個(gè)不同數量請求的情況下，獲取系統響應時(shí)間以及系統資源消耗情況。自動(dòng)化測試主要是通過(guò)自己寫(xiě)腳本以及一些第三方工具的結合來(lái)測試軟交換的特性測試。
問(wèn)題三：你所了解的的軟件測試類(lèi)型都有哪些，簡(jiǎn)單介紹一下。
1. 基本功能驗證。主要是對發(fā)布的版本進(jìn)行一些最主要功能的測試。英文常見(jiàn)叫法是Smoking Test,Basic Verification Test或者Sanity Check。
2. 功能測試。主要是依據需求或者需求分析文檔，對所發(fā)布的版本進(jìn)行測試，看看是否滿(mǎn)足需求，是否出現了不必要的功能。
3. 單元測試。是開(kāi)發(fā)人員進(jìn)行的測試之一，一般是開(kāi)發(fā)人員對很小的模塊，比如函數進(jìn)行測試，一般來(lái)說(shuō)，開(kāi)發(fā)人員還需要開(kāi)發(fā)相應的測試樁來(lái)進(jìn)行此類(lèi)測試。
4. 集成測試。在大型的開(kāi)發(fā)過(guò)程中，軟件是模塊化進(jìn)行開(kāi)發(fā)的，將不同的模塊揉合在一起的話(huà)，需要進(jìn)行的測試就是集成測試。
5. 系統測試。當軟件提交給測試組后，是對整個(gè)系統的所有功能進(jìn)行測試，一般來(lái)說(shuō)，功能測試是系統測試的一個(gè)部分。
6. 壓力測試。主要是在很大性能的情況下，這個(gè)性能已經(jīng)接近了系統的極限，看看系統運轉的情況。
7. 負載測試。主要是用各種不同的性能去檢測系統，采集各個(gè)數據在這些性能情況下的數據。
8. 黑盒測試。指系統對你來(lái)說(shuō)是完全不透明的，只給你留下了輸入和最終輸出，這個(gè)是功能測試的方法之一。
9. 灰盒測試。指在了解部分系統內部工作機制的情況下，對于系統進(jìn)行的覆蓋性測試。
10. 白盒測試。主要是在單元測試和集成測試的情況下，開(kāi)發(fā)人員已知代碼，對這一段的代碼進(jìn)行全路徑的覆蓋測試。
11. 界面測試。主要是看用戶(hù)界面的友好性和易用性，是否有文字或者排版錯誤，是否有輸入限制等等。
12. 回歸測試。一般是系統發(fā)現BUG，開(kāi)發(fā)人員修改后，和BUG直接相關(guān)以及可能相關(guān)的功能進(jìn)行的測試。
13. 安裝和卸載的測試。
14. 恢復測試。主要是一個(gè)系統在發(fā)生了災難的情況下，從錯誤中是否容易恢復。
15. 兼容性測試。一個(gè)系統在不同的語(yǔ)言，操作系統下的系統測試。
16. 安全測試。系統在遇到攻擊或者類(lèi)似情況下的表現。
17. Alpha測試。系統在給最終用戶(hù)前，測試人員在實(shí)驗室中模擬最終用戶(hù)的測試。
18. Beta測試。由部分最終用戶(hù)通過(guò)使用來(lái)進(jìn)行的測試。
19. 比較測試。和其他具有相同或者類(lèi)似功能的系統進(jìn)行對比的測試。
20. 驗收測試。一般是最終用戶(hù)在接受產(chǎn)品前，依據自己所提出的要求進(jìn)行的測試，很多情況下，驗收測試可能委托第三方機構完成。
問(wèn)題四：測試計劃工作的目的是什么?測試計劃文檔的內容應該包括什么?其中哪些是最重要的?
軟件測試計劃是指導測試過(guò)程的綱領(lǐng)性文件。
包含了產(chǎn)品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風(fēng)險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實(shí)施過(guò)程的順暢溝通，跟蹤和控制測試進(jìn)度，應對測試過(guò)程中的各種變更。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術(shù)的關(guān)系，測試計劃主要從宏觀(guān)上規劃測試活動(dòng)的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務(wù)的具體戰術(shù)。所以其中最重要的是測試測試策略和測試方法(最好是能先評審)。
問(wèn)題五：你認為做好測試計劃工作的關(guān)鍵是什么?
1. 明確測試的目標，增強測試計劃的實(shí)用性
編寫(xiě)軟件測試計劃得重要目的就是使測試過(guò)程能夠發(fā)現更多的軟件缺陷，因此軟件測試計劃的價(jià)值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實(shí)可行，測試工具并且具有較高的實(shí)用性，便于使用，生成的測試結果直觀(guān)、準確
2. 堅持“5W”規則，明確內容與過(guò)程
“5W”規則指的是“What(做什么)”、“Why(為什么做)”、“When(何時(shí)做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”規則創(chuàng )建軟件測試計劃，可以幫助測試團隊理解測試的目的(Why)，明確測試的范圍和內容(What)，確定測試的開(kāi)始和結束日期(When)，指出測試的方法和工具(How)，給出測試文檔和軟件的存放位置(Where)。
3. 采用評審和更新機制，保證測試計劃滿(mǎn)足實(shí)際需求
測試計劃寫(xiě)作完成后，如果沒(méi)有經(jīng)過(guò)評審，直接發(fā)送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒(méi)有及時(shí)更新，誤導測試執行人員。
4. 分別創(chuàng )建測試計劃與測試詳細規格、測試用例
應把詳細的測試技術(shù)指標包含到獨立創(chuàng )建的測試詳細規格文檔，把用于指導測試小組執行測試過(guò)程的測試用例放到獨立創(chuàng )建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術(shù)的關(guān)系，測試計劃主要從宏觀(guān)上規劃測試活動(dòng)的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務(wù)的具體戰術(shù)。
軟件測試面試題
1、等價(jià)類(lèi)劃分
常見(jiàn)的軟件測試面試題劃分等價(jià)類(lèi)：等價(jià)類(lèi)是指某個(gè)輸入域的子集合。在該子集合中，各個(gè)輸入數據對于揭露程序中的錯誤都是等效的。并合理地假定：測試某等價(jià)類(lèi)的代表值就等于對這一類(lèi)其它值的測試。因此，可以把全部輸入數據合理劃分為若干等價(jià)類(lèi)，在每一個(gè)等價(jià)類(lèi)中取一個(gè)數據作為測試的輸入條件，就可以用少量代表性的測試數據。取得較好的測試結果。等價(jià)類(lèi)劃分可有兩種不同的情況：有效等價(jià)類(lèi)和無(wú)效等價(jià)類(lèi)。
2、邊界值分析法
邊界值分析方法是對等價(jià)類(lèi)劃分方法的補充。測試工作經(jīng)驗告訴我，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價(jià)類(lèi)的邊界，就是應著(zhù)重測試的邊界情況。應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價(jià)類(lèi)中的典型值或任意值作為測試數據。
3、錯誤推測法
基于經(jīng)驗和直覺(jué)推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。
錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據他們選擇測試用例。例如，在單元測試時(shí)曾列出的許多在模塊中常見(jiàn)的錯誤。以前產(chǎn)品測試中曾經(jīng)發(fā)現的錯誤等，這些就是經(jīng)驗的總結。還有，輸入數據和輸出數據為0的情況。輸入表格為空格或輸入表格只有一行。這些都是容易發(fā)生錯誤的情況�？蛇x擇這些情況下的例子作為測試用例。
4、因果圖方法
前面介紹的等價(jià)類(lèi)劃分方法和邊界值分析方法，都是著(zhù)重考慮輸入條件，但未考慮輸入條件之間的聯(lián)系，相互組合等�？紤]輸入條件之間的相互組合，可能會(huì )產(chǎn)生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價(jià)類(lèi)，他們之間的組合情況也相當多。因此必須考慮采用一種適合于描述對于多種條件的組合，相應產(chǎn)生多個(gè)動(dòng)作的形式來(lái)考慮設計測試用例。這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。
5、正交表分析法
有時(shí)候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時(shí)，這些測試用例并沒(méi)有明顯的優(yōu)先級上的差距，而測試人員又無(wú)法完成這么多數量的測試，就可以通過(guò)正交表來(lái)進(jìn)行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。
6、場(chǎng)景分析方法
指根據用戶(hù)場(chǎng)景來(lái)模擬用戶(hù)的操作步驟，這個(gè)比較類(lèi)似因果圖，但是可能執行的深度和可行性更好。
軟件測試工程師面試題
1、怎么來(lái)設計測試方案
根據測試需求（涉及功能需求和非功能性需求），辨認測試要點(diǎn)，辨認測試環(huán)境規定，安排測試輪次，根據項目籌劃和開(kāi)發(fā)籌劃做整體的測試安排。
被測試的特性：通過(guò)對需求規格闡明書(shū)進(jìn)行分析，列出本次測試需要進(jìn)行測試的各部分特性（如要測試的功能需求、性能需求、安全性需求等等）。
不被測試的特性：由于資源、進(jìn)度等方面因素，本次測試不列入測試范疇的特性。
測試組網(wǎng)圖：進(jìn)行本次系統測試所需要的軟硬件設備、配備數據已及互相間的邏輯、物理連接。此后測試執行時(shí)需要根據這個(gè)組網(wǎng)圖來(lái)進(jìn)行環(huán)境的搭建。
2、如果給你一種B/S系統你怎么來(lái)進(jìn)行測試
此題答案還可用于回答測試流程，測試流程題亦可參照15題。
閱讀系統需求，充足理解需求，記錄問(wèn)題，并與項目需求人員充足溝通。
編寫(xiě)測試需求，涉及系統功能和非功能測試要點(diǎn)、測試類(lèi)型、測試進(jìn)度質(zhì)量規定等。
制定測試籌劃，涉及熟悉測試業(yè)務(wù)、設計測試用例、執行測試用例、進(jìn)行測試小結、編寫(xiě)測試報告，任務(wù)顆粒度一般應不不小于5人天
編寫(xiě)測試用例，根據測試方案設計用例，即便沒(méi)有明確的性能和安全測試規定，也應辨認進(jìn)行此兩項測試。
執行軟件測試。
進(jìn)行測試小結，如果測試持續時(shí)間較長(cháng)，每個(gè)版本間隙總結本輪測試。
編寫(xiě)測試報告，總結測試過(guò)程，匯總度量數據。
3、怎么進(jìn)行工作流的測試
把握需求，找準結點(diǎn)，理清流程，畫(huà)出流轉圖，弄清節點(diǎn)間的數據流轉，設計測試用例的時(shí)候必須覆蓋所有也許的流程。
工作流：
如果問(wèn)到有無(wú)做過(guò)，根據對工作流的理解狀況回答，如果比較理解，可以把參與的某個(gè)項目中說(shuō)上某些有工作流的，如果不是很理解就說(shuō)沒(méi)有做過(guò)，但是學(xué)習過(guò)有關(guān)知識。
4、做性能測試的時(shí)候都需要關(guān)注哪些參數
并發(fā)訪(fǎng)問(wèn)量，服務(wù)器響應時(shí)間（最小、平均、最大）
并發(fā)性能測試的過(guò)程是一種負載測試和壓力測試的過(guò)程，即逐漸增長(cháng)負載，直到系統的瓶頸或者不能接受的性能點(diǎn)，通過(guò)綜合分析交易執行指標和資源監控指標來(lái)擬定系統并發(fā)性能的過(guò)程。
負載測試（Load Testing）是擬定在多種工作負載下系統的性能，目的是測試當負載逐漸增長(cháng)時(shí)，系統構成部分的相應輸出項，例如通過(guò)量、響應時(shí)間、CPU負載、內存使用等來(lái)決定系統的性能。
負載測試是一種分析軟件應用程序和支撐架構、模擬真實(shí)環(huán)境的使用，從而來(lái)擬定可以接受的性能過(guò)程。壓力測試（Stress Testing）是通過(guò)擬定一種系統的瓶頸或者不能接受的性能點(diǎn)，來(lái)獲得系統能提供的最大服務(wù)級別的測試。
疲勞測試是采用系統穩定運營(yíng)狀況下可以支持的最大并發(fā)顧客數，持續執行一段時(shí)間業(yè)務(wù)，通過(guò)綜合分析交易執行指標和資源監控指標來(lái)擬定系統解決最大工作量強度性能的過(guò)程。
疲勞強度測試可以采用工具自動(dòng)化的方式進(jìn)行測試，也可以手工編寫(xiě)程序測試，其中后者占的比例較大。
一般狀況下以服務(wù)器可以正常穩定響應祈求的最大并發(fā)顧客數進(jìn)行一定期間的疲勞測試，獲取交易執行指標數據和系統資源監控數據。如浮現錯誤導致測試不能成功執行，則及時(shí)調節測試指標，例如減少顧客數、縮短測試周期等。尚有一種狀況的疲勞測試是對目前系統性能的評估，用系統正常業(yè)務(wù)狀況下并發(fā)顧客數為基本，進(jìn)行一定期間的疲勞測試。
大數據量測試可以分為兩種類(lèi)型：針對某些系統存儲、傳播、記錄、查詢(xún)等業(yè)務(wù)進(jìn)行大數據量的獨立數據量測試；與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數據量測試方案。大數據量測試的核心是測試數據的準備，可以依托工具準備測試數據。
5、客戶(hù)沒(méi)給性能指數，怎么開(kāi)展性能測試
如果客戶(hù)沒(méi)有提出明確的性能指標，可以按照慣例和經(jīng)驗設立，需要和PM協(xié)商，一般由PM確認，QA負責給出建議。
舉例說(shuō)一種Server端程序，規定峰值時(shí)CPU和MEM消耗在75％如下，而一種頁(yè)面的訪(fǎng)問(wèn)響應時(shí)間一般覺(jué)得顧客的忍耐時(shí)間是3－5秒以?xún)�，這些要參照實(shí)際的應用來(lái)擬定顧客規模、操作頻率、同步在線(xiàn)數等。
6、有無(wú)做過(guò)接口測試，是如何做的
通過(guò)編寫(xiě)測試程序，獲得接口指針，逐個(gè)調用接口函數驗證其對的性，及失敗操作
7、測試過(guò)程中是如何來(lái)保證軟件質(zhì)量的
測試用例編寫(xiě)完畢后要加強評審的力度，保證測試用例覆蓋所有需求點(diǎn)
執行測試過(guò)程中注意做小結檢查覆蓋狀況、審視所提缺陷質(zhì)量，復測時(shí)應注意有關(guān)模塊的測試
測試時(shí)間寬裕的話(huà)可以做交叉測試，用以保證測試質(zhì)量。
8、測試方案都寫(xiě)什么內容
1概述
2被測對象分析
3應測試的特性
4不被測試的特性
5總體設計措施
6測試模型
6.1測試組網(wǎng)圖
6.2構造/對象關(guān)系圖
6.3測試原理
6.4操作規程
7測試需求
7.1環(huán)境需求
7.2被測對象需求
7.3測試工具需求
7.4測試代碼需求
7.5數據需求
7.6其他需求
8測試設計
8.1工具設計
8.2測試代碼設計
8.3用例設計
8.3.1設計原則
8.3.2測試項目
9.附錄
�。y試方案規定根據《SRS》上的每個(gè)需求點(diǎn)設計出涉及需求點(diǎn)簡(jiǎn)介，測試思路和具體測試措施三部分的方案）以往華為測試方案
目錄如下：
第1章技術(shù)方案
1.1.測試需求描述
1.1.1.測試類(lèi)型分析
1.1.2.測試內容
1.2.缺陷分類(lèi)
1.3.缺陷級別
第2章SOW及規格的應答
2.1.測試需求應答
2.2.交付件應答
2.2.1.軟件交付件應答
2.2.2.非軟件交付件應答
2.3.項目里程碑項目完畢時(shí)間應答
2.4.質(zhì)量目的應答
2.5.驗收原則應答
2.6.限制應答
2.6.1.合伙供應商人員組織應答
2.6.2.硬件設備應答
2.6.3.合伙項目開(kāi)發(fā)場(chǎng)地應答
第3章類(lèi)似項目成功案例
第4章項目具體工作籌劃
第5章項目估算
9、測試方案和測試籌劃的區別
測試方案是技術(shù)性的；測試籌劃更多是管理性的。
測試籌劃重要要考慮測試的技術(shù)可行性、核心技術(shù)、資源投入、進(jìn)度安排、風(fēng)險管理、配備管理、輸入輸出等。測試籌劃更多地供高層管理者決策時(shí)做參照；同步對后續測試工作開(kāi)展起指引作用。
在某些小項目中，也許只需要一種測試方案，測試籌劃內容相對較少，可以與測試方案合并進(jìn)行；而某些大項目中，也許要設計數十個(gè)測試方案，這就需要一種提綱挈領(lǐng)的東西了，這就是測試籌劃的作用。
10、測試用例是根據什么寫(xiě)的
系統測試用例根據需求和設計編寫(xiě)
�。ㄈA為的SDV測試用例是根據《測試方案》和測試方略來(lái)編寫(xiě)的）
11、是怎么來(lái)設計測試用例的？
答：先熟悉系統需求，把握測試要點(diǎn)，設計用例的原則一方面是要覆蓋每個(gè)需求點(diǎn)，可以通過(guò)填寫(xiě)需求跟蹤矩陣來(lái)保證覆蓋。
黑盒測試的測試用例設計措施：等價(jià)類(lèi)劃分法、邊界值分析法、錯誤推測法、因果圖。
軟件測試工作的面試題目
1、什么是兼容性測試？兼容性測試側重哪些方面？
2、我現在有個(gè)程序，發(fā)現在Windows上運行得很慢，怎么判別是程序存在問(wèn)題還是軟硬件系統存在問(wèn)題？
3、檢查系統是否有中毒的特征；
4、檢查軟件/硬件的配置是否符合軟件的推薦標準；
5、確認當前的系統是否是獨立，即沒(méi)有對外提供什么消耗CPU資源的服務(wù)；
6、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服務(wù)器的連接有問(wèn)題，或者訪(fǎng)問(wèn)有問(wèn)題造成的；
7、在系統沒(méi)有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪(fǎng)問(wèn)情況。
8、測試的策略有哪些？黑盒/白盒，靜態(tài)/動(dòng)態(tài)，手工/自動(dòng)，冒煙測試，回歸測試，公測（Beta測試的策略）
9、正交表測試用例設計方法的特點(diǎn)是什么？
10、用最少的實(shí)驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；
11、對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來(lái)；但是更深的缺陷，更復雜的缺陷，還是無(wú)能為力的；
12、具體的環(huán)境下，正交表一般都很難做的。大多數，只在系統測試的時(shí)候使用此方法。
13、描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程？標記就是Bugzilla的狀態(tài)轉換圖。
14、你覺(jué)得bugzilla在使用的過(guò)程中，有什么問(wèn)題？標記界面不穩定； 根據需要配置它的不同的部分，過(guò)程很煩瑣。流程控制上，安全性不好界定，很容易對他人的Bug進(jìn)行誤操作；沒(méi)有綜合的評分指標，不好確認修復的優(yōu)先級別。
15、描述測試用例設計的完整過(guò)程？需求分析 + 需求變更的維護工作；根據需求， 得出測試需求；設計測試方案，評審測試方案；方案評審通過(guò)后，設計測試用例，再對測試用例進(jìn)行評審；
【常見(jiàn)軟件測試面試題】相關(guān)文章：
軟件測試簡(jiǎn)歷07-14
軟件測試總結05-20
軟件測試的簡(jiǎn)歷模板08-22
軟件測試實(shí)習總結09-24
軟件測試實(shí)習報告07-06
軟件測試個(gè)人總結07-22
軟件測試實(shí)習日記07-28