2022年軟件測試面試題大全

一、面試基礎題

簡述測試流程:

1、閱讀相關技術文檔（如產品PRD、UI設計、產品流程圖等）。

2、參加需求評審會議。

3、根據最終確定的需求文檔編寫測試計劃。

4、編寫測試用例（等價類劃分法、邊界值分析法等）。

5、用例評審(主要參與人員：開發、測試、產品、測試leader)。

6、開發提交代碼至SVN或者GIT ，配管搭建測試環境。

7、執行測試用例，記錄發現的問題。

8、驗證bug與回歸測試。

9、編寫測試報告。

10、產品上線。

補充測試用例設計過程：

根據需求得出測試需求

設計測試方案，評審測試方案

方案評審通過后，設計測試用例，再對測試用例進行評審

什么是軟件測試？軟件測試的目的與原則

使用人工或自動手段，來運行或測試某個系統的過程。其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。

軟件測試的目的：

測試是程序的執行過程，目的在于發現錯誤。

一個成功的測試用例在于發現至今未發現的錯誤。

一個成功的測試是發現了至今未發現的錯誤的測試。

確保產品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明。

確保產品滿足性能和效率的要求。

確保產品是健壯的和適應用戶環境的。

問：軟件生存周期及其模型是什么？

軟件生存周期是軟件開發全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發布維護的過程。在經歷需求、分析、設計、實現、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命周期模型"（Life Cycle Model）。

什么是軟件質量？

軟件質量：軟件產品的特性可以滿足用戶的功能、性能需求的能力。

自動化測試腳本開發的主要步驟:

1、通過某些方式定位到我們要執行的對象、目標( Target)

2、對這個對象進行什么操作(command)

3、通過操作對定位到的元素賦值(value)

4、添加斷言操作

目前主要的測試用例設計方法是什么？

白盒測試：

邏輯覆蓋

循環覆蓋

基本路徑覆蓋

黑盒測試：

邊界值分析法

等價類劃分

錯誤猜測法

因果圖法

狀態圖法

測試大綱法

隨機測試場景法

常見的測試用例設計方法都有哪些?請分別以具體的例子來說明這些方法在測試用例設計工作中的應用

1）等價類劃分劃分

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

2）邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設（面試題目：什么樣的工作環境適合你&#from一個常見的軟件測試面試題來自end#lt；結束）計測試用例，可以查出更多的錯誤。

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

3）錯誤推測法

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

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

4）因果圖方法

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

5）正交表分析法

有時候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

6）場景分析方法

指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。

測試的策略有哪些?

黑盒/白盒/灰盒，靜態/動態，手工/自動，冒煙測試，回歸測試，公測（Beta測試的策略）

補充：公測是什么?還有沒有其他的測試策略？測試策略和測試方法以及測試類型有什么區別？

按測試 策略分類：

　　1、靜態與動態測試

　　2、黑盒與白盒測試

　　3、手工和自動測試

　　4、冒煙測試

　　5、回歸測試；

　　按測試階段分類：單元測試、集成測試、系統測試；

　　其他常見測試方法：1、功能測試 2、性能測試 3、壓力測試 4、負載測試 5、易用性測試 6、安裝測試 7、界面測試 8、配置測試 9、文檔測試 10、兼容性測試 11、安全性測12、恢復測試

α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。

β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta 測試不能由程序員或測試員完成。

回歸測試（對軟件的新版本測試時，重復執行上一個版本測試時的用例，是為了驗證缺陷是否真正修復，確認修復后是否影響其它功能）；

冒煙測試：對新版本測試之前，先驗證下軟件的基本功能是否實現，是否具備可測性。

單元測試的策略有哪些？

邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析

正交表測試用例設計方法的特點是什么？

答：用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。

補充：什么時候用系統測試，測試的每個階段是什么，比如單元、集成、系統、公測，每個階段需要什么技術，有什么要求

軟件的安全性應從哪幾個方面去測試？

(1) 用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議

(2) 加密機制

(3) 安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描

(4) 數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理

(5) 防病毒系統

軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。

用戶認證安全的測試要考慮問題：

明確區分系統中不同用戶權限

系統中會不會出現用戶沖突

系統會不會因用戶的權限的改變造成混亂

用戶登陸密碼是否是可見、可復制

是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）

用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統

系統網絡安全的測試要考慮問題

測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上

模擬非授權攻擊，看防護系統是否堅固

采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，

現在最常用的是 NBSI 系列和 IPhacker IP ）

采用各種木馬檢查工具檢查系統木馬情況

采用各種防外掛工具檢查系統各組程序的外掛漏洞

數據庫安全考慮問題：

系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）

系統數據的完整性（我剛剛結束的企業實名核查服務系統中就曾存在數據的不完整，對于這

個系統的功能實現有了障礙）

系統數據可管理性

系統數據的獨立性

系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）

α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環

境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。

β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在

測試現場，Beta 測試不能由程序員或測試員完成。

需求測試的注意事項有哪些？

? ? ? 是否使用了公司的模板

　　文檔內容是否符合規范

　　所有的需求是分級是否清析適當？

　　所有的需求是否具有一致性

　　需求是否可行（即，該需求組合有解決方案）

　　需求可否用己知的約束來實現

　　需求是否足夠（即，可以把它送到一個規范的開發組織，并有一個生產出所需要產品的合理的可能性）

　　所有的其它需求是交叉引用是否正確

　　用戶描述是否清楚

　　是否用客戶的語言來描述需求

　　每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現時也能理解

　　是否所有的需求都是可驗證的

　　是否每條需求都具有獨立性，即使發生了變化也不會影響其它需求

　　性能指標是否明確

　　非功能性需求是否得到充分表現

　　是否完整列出適用的標準或協議

　　標準和協議之間是否存在沖突

問：你在測試中發現了一個? bug ，但是開發經理認為這不是一個? bug ，你應該怎樣解決。

將問題提交到缺陷管理庫里面進行備案。

要獲取判斷的依據和標準：? ? 根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；? ? 如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；? 根據用戶的一般使用習慣，來確認是否是缺陷；

與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；

合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。

等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。

問：給你一個網站，你如何測試？

1、查找需求說明、網站設計 m 等相關文檔，分析測試需求。

2、制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：

? ? 功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試

3、設計測試用例：

? ? 功能性測試可以包括，但不限于以下幾個方面：

? ? 鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。提交功能的測試。

? ? 多媒體元素是否可以正確加載和顯示。多語言支持是否能夠正確顯示選擇的語言等。

? ? 界面測試可以包括但不限于一下幾個方面：

頁面是否風格統一，美觀

文字檢查

對于必須但為安裝的空間，是否提供自動下載并安裝的功能

控件是否正常使用

頁面布局是否合理，重點內容和熱點內容是否突出? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別? ?

300 個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生干擾，而產生一些異常。300 個用戶在一個客戶端上，需要更大的帶寬。IP 地址的問題，可能需要使用 IP Spoof 來繞過服務器對于單一 IP 地址最大連接數的限制。所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火墻設置。

你工作中遇到最具價值的bug，就是重大bug咯，例如app性能測試測哪些，那你就看一看性能測試的視頻咯

軟件的安全性應從哪幾個方面 去測試？

軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。

用戶認證安全的測試要考慮問題：

明確區分系統中不同用戶權限

系統中會不會出現用戶沖突

系統會不會因用戶的權限的改變造成混亂

用戶登陸密碼是否是可見、可復制

是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）

用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統

系統網絡安全的測試要考慮問題

測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上

模擬非授權攻擊，看防護系統是否堅固

采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，

現在最常用的是 NBSI 系列和 IPhacker IP ）

采用各種木馬檢查工具檢查系統木馬情況

采用各種防外掛工具檢查系統各組程序的外掛漏洞

數據庫安全考慮問題：

系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）

系統數據的完整性（我剛剛結束的企業實名核查服務系統中就曾存在數據的不完整，對于這個系統的功能實現有了障礙）

系統數據可管理性

系統數據的獨立性

系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）

軟件質量保證體系是什么 國家標準中與質量保證管理相關的幾個標準是什么? ? 他們的編號和全稱是什么? ?

SQA 由一套軟件工程過程和方法組成，以保證（軟件的）質量。SQA 貫穿整個軟件開發過程，(它)應包括需求文檔評審、代碼控制、代碼評審、變更管理、配置管理、版本管理和軟件測試。

測試人員在軟件開發過程中的任務是什么？

1、尋找 Bug；

2、避免軟件開發過程中的缺陷；

3、衡量軟件的品質；

4、關注用戶的需求。

總的目標是：確保軟件的質量。

在您以往的工作中，一條軟件缺陷（或者叫 Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

一條 Bug 記錄最基本應包含：編號、Bug 所屬模塊、Bug 描述、Bug 級別、發現日期、發現人、修改日期、修改人、修改方法、回歸結果等等；

要有效的發現 Bug 需參考需求以及詳細設計等前期文檔設計出高效的測試用例，然后嚴格執行測試用例，對發現的問題要充分確認

肯定，然后再向外發布如此才能提高提交 Bug 的質量。

黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點！

黑盒測試的優點有：

? ? ? 比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關；從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。

黑盒測試的缺點有：

? ? ? 不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；自動化測試的復用性較低。

白盒測試的優點有：

? ? 幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。

白盒測試的缺點有：

? ? ? 程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基于代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。

什么是系統瓶頸？

參考答案：

瓶頸主要是指整個軟硬件構成的軟件系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。

嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，內存也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求。在用戶極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響用戶工作。

因此我們測試系統瓶頸主要是實現下面兩個目的：

-發現“表面”的瓶頸。主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然后解決瓶頸，這是性能測試的基本目標。

-發現潛在的瓶頸并解決，保證系統的長期穩定性。主要是考慮用戶在將來擴展系統或者業務發生變化時，系統能夠適應變化。滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟件生命周期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化。

————————————————

版權聲明：本文為CSDN博主「平安喜樂_」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/hard_days/article/details/110388559