最全軟體測試面試題

在當今競争激烈的軟體測試職場中，想要擷取一份滿意的offer，就要在面試前做足充分準備，不斷挖掘用人機關崗位需求，才能做到“知己知彼，百戰不殆。”

避免面試過程中間“采坑”，專門為各位即将入行軟體測試的小夥伴們準備了一份最全的面試問題及詳解答案，助你offer手到擒來！

NO.1  你在測試中發現了一個bug，但是項目經理認為這不是一個bug，你應該怎樣解決？

首先，将問題送出到缺陷管理庫裡面進行備案。然後，要擷取判斷的依據和标準：

• 根據需求規格說明書、産品說明、設計文檔等，确認實際結果是否與預期有不一緻的地方，提供缺陷是否确認的直接依據；

• 如果沒有文檔依據，可以根據類似軟體的一般特性來說明是否存在不一緻的地方，來确認是否是缺陷；

• 根據使用者的一般使用習慣，來确認是否是缺陷；

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

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

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

NO.2  給你一個網站，你如何測試？

首先，查找需求說明、網站設計等相關文檔，挖掘測試點

制定測試計劃，确定測試範圍和測試政策，一般包括以下幾個部分：功能性測試、UI測試、性能測試、資料庫測試、安全性測試、相容性測試、使用者體驗測試

測試用例設計：

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

• 連結有效測試。連結是否正确跳轉，是否存在空頁面和無效頁面，是否有不正确的出錯資訊傳回。

• 送出功能的測試。

• 多媒體元素是否可以正确加載和顯示。

• 多語言支援是否能夠正确顯示選擇的語言等。

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

• 頁面是否風格統一，美觀

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

• 控件是否正常使用

• 對于必須但未安裝的控件，是否提供自動下載下傳并安裝的功能

• 文字檢查

性能測試一般從以下兩個方面考慮：

壓力測試；負載測試、強度測試、穩定性測試

資料庫測試要具體決定是否需要開展。資料庫一般需要考慮連接配接性，對資料的存取操作，資料内容的驗證等方面。

安全性測試：

• 基本的登入功能的檢查

• 是否存在溢出錯誤，導緻系統崩潰或者權限洩露

• 相關開發語言的常見安全性問題檢查，例如SQL注入等

• 如果需要進階的安全性測試，确定獲得專業安全公司的幫助，外包測試，或者擷取支援

相容性測試，根據需求說明的内容，确定支援的平台組合：

• 浏覽器的相容性；

• 作業系統的相容性；

• 軟體平台的相容性；(第三方軟體)

• 資料庫的相容性

開展測試，并記錄缺陷。合理的安排調整測試進度，提前擷取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等内容）。

定期評審，對測試進行評估和總結，調整測試的内容。

NO.3  一台用戶端有三百個客戶與三百個用戶端有三百個客戶對伺服器施壓，有什麼差別?

• 300個使用者在一個用戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生幹擾，而産生一些異常。

• 300個使用者在一個用戶端上，需要更大的帶寬。

• IP位址的問題，可能需要使用IP Spoof來繞過伺服器對于單一IP位址最大連接配接數的限制。

• 所有使用者在一個用戶端上，不必考慮分布式管理的問題；而使用者分布在不同的用戶端上，需要考慮使用控制器來整體調配不同客戶機上的使用者。同時，還需要給予相應的權限配置和防火牆設定。

NO.4  什麼是測試用例？什麼是測試腳本？兩者的關系是什麼？

• 為實施測試而向被測試系統提供的輸入資料、操作或各種環境設定以及期望結果的一個特定的集合。

• 測試腳本是為了進行自動化測試而編寫的腳本。

• 測試腳本的編寫必須對應相應的測試用例

NO.5  簡述什麼是靜态測試、動态測試、黑盒測試、白盒測試、α測試、β測試

• 靜态測試是不運作程式本身而尋找程式代碼中可能存在的錯誤或評估程式代碼的過程。  

• 動态測試是實際運作被測程式，輸入相應的測試執行個體，檢查運作結果與預期結果的差異，判定執行結果是否符合要求，進而檢驗程式的正确性、可靠性和有效性，并分析系統運作效率和健壯性等性能。

• 黑盒測試一般用來确認軟體功能的正确性和可操作性，目的是檢測軟體的各個功能是否能得以實作,把被測試的程式當作一個黑盒，不考慮其内部結構，在知道該程式的輸入和輸出之間的關系或程式功能的情況下，依靠軟體規格說明書來确定測試用例和推斷測試結果的正确性。

• 白盒測試根據軟體内部的邏輯結構分析來進行測試,是基于代碼的測試，測試人員通過閱讀程式代碼或者通過使用開發工具中的單步調試來判斷軟體的品質，一般黑盒測試由項目經理在程式員開發中來實作。

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

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

NO.6  如何測試一個紙杯？

• 功能度：用水杯裝水看漏不漏；水能不能被喝到

• 安全性：杯子有沒有毒或細菌

• 可靠性：杯子從不同高度落下的損壞程度

• 可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用

• 相容性：杯子是否能夠容納果汁、白水、酒精、汽油等

• 易用性：杯子是否燙手、是否有防滑措施、是否友善飲用

• 使用者文檔：使用手冊是否對杯子的用法、限制、使用條件等有較長的描述

• 疲勞測試：将杯子盛上水（案例一）放24小時檢查洩漏時間和情況；盛上汽油（案例二）放24小時檢查洩漏時間和情況等

• 壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透

如何找到并發數、平均響應時間、tps的最佳平衡點？

先回顧下基礎，性能測試常用的名額有三個：并發、響應時間、tps

并發：跑道裡參加賽跑的人數（這裡的并發是廣義的并發，即同一個時間段内對系統發起的請求數量）

響應時間：也就是平均每個事務的處理時間

tps：每秒處理的事務數

需求名額：分為單名額和多名額

單名額：一般是單測試tps，或者根據并發測試響應時間，或者根據響應時間測試并發，隻考慮單名額的很少

多名額：要同時考慮多個名額，比如tps + 響應時間(<1s)

這個題，意思就是要找到這三個名額同時最佳值的點，即：不能隻追求并發數大，而忽略tps，是以，這是一個多名額性能需求，假設是這樣的：要求響應時間1秒以内，并發數要盡可能的多，tps要盡可能的大。

是不是依舊有點懵逼？先畫一個簡單的示意圖，友善大家了解：

随着并發數增加，響應時間肯定是越來越高，是以，上面紅線是響應時間；

随着并發數增加，tps是先升高到峰值，然後下降（也可能是一直平穩，或者平穩一段時間再下降），是以，上面藍線是tps；

紫色表示并發使用者數；

該怎麼去找這個最佳平衡點呢？

1. 盡可能多的做不同并發數下的壓測，記錄下響應時間（1s以内）和最大tps，當然，伺服器端，各個伺服器的資源使用率在可接受範圍内（每個公司不一樣，我們是90%以内）；

2. 然後根據擷取到的不同并發下的名額資料（并發數、tps、響應時間），畫出上圖，關注右側的交點，即tps下降的地方和響應時間的交點，這個點的tps最大，如果響應時間在1s以内，此時并發數也是比較大的，這個點就可以認為是三個名額都不錯的平衡點（當然，我這裡把tps放在第一位優先考慮了，這個就看大家最在乎哪個名額了，排個優先級）。

如果響應時間大于1s，最佳平衡點就往左找，找到響應時間為1秒的點，此時對應的tps和并發值，就是最佳平衡點。總之，測試采樣越多，擷取的平衡點就越準确。