軟件測試主管面試題

時間：2022-11-25 07:15:18 面試技巧我要投稿

相關推薦

軟件測試主管面試題

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

軟件測試主管面試題

　　軟件測試主管面試題1

　　1、如何理解強度測試?

　　參考答案：

　　強度測試是為了確定系統在最差工作環境的工作能力,也可能是用于驗證在標準工作壓力下的各種資源的最下限指標。

　　它和壓力測試的目標是不同的,壓力測試是在標準工作環境下,不斷增加系統負荷,最終測試出該系統能力達到的最大負荷(穩定和峰值),而強度測試則是在非標準工作環境下,甚至不斷人為降低系統工作環境所需要的資源,如網絡帶寬,系統內存,數據鎖等等,以測試系統在資源不足的情況下的工作狀態,通過強度測試,可以確定本系統正常工作的最差環境.

　　強度測試和壓力測試的測試指標相近,大多都是與時間相關的指標,如并發量(吞吐量),延遲(最大\最小\平均)以及順序指標等

　　強度測試需要對系統的結構熟悉,針對系統的特征設計強度測試的方法

　　2、如何理解壓力、負載、性能測試測試?

　　參考答案：

　　性能測試是一個較大的范圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。

　　壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問可以看作壓力測試，那么連續訪問8個小時就可以認為負載測試，1000個用戶連續訪問系統1個小時也可以看作是負載測試。

　　實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體性能的高度上來對系統進行測試。

　　3、什么是系統瓶頸?

　　參考答案：

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

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

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

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

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

　　軟件測試主管面試題2

　　1、文檔測試主要包含什么內容?

　　參考答案：

　　在國內軟件開發管理中，文檔管理幾乎是最弱的一項，因而在測試工作中特別容易忽略文檔測試也就不足為奇了。要想給用戶提供完整的產品，文檔測試是必不可少的。文檔測試一般注重下面幾個方面：文檔的完整性：主要是測試文檔內容的全面性與完整性，從總體上把握文檔的質量。例如用戶手冊應該包括軟件的所有功能模塊。

　　描述與軟件實際情況的一致性：主要測試軟件文檔與軟件實際的一致程度。例如用戶手冊基本完整后，我們還要注意用戶手冊與實際功能描述是否一致。因為文檔往往跟不上軟件版本的更新速度。

　　易理解性：主要是檢查文檔對關鍵、重要的操作有無圖文說明，文字、圖表是否易于理解。對于關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明了。

　　文檔中提供操作的實例：這項檢查內容主要針對用戶手冊。對主要功能和關鍵操作提供的應用實例是否豐富，提供的實例描述是否詳細。只有簡單的圖文說明，而無實例的用戶手冊看起來就像是軟件界面的簡單拷貝，對于用戶來說，實際上沒有什么幫助。

　　印刷與包裝質量：主要是檢查軟件文檔的商品化程度。有些用戶手冊是簡單打印、裝訂而成，過于粗糙，不易于用戶保存。優秀的文檔例如用戶手冊和技術白皮書，應提供商品化包裝，并且印刷精美。

　　2、功能測試用例需要詳細到什么程度才是合格的?

　　參考答案：

　　這個問題也是測試工程師經常問的問題。有人主張測試用例詳細到每個步驟執行什么都要寫出來，目的是即使一個不了解系統的新手都可以按照測試用例來執行工作。主張這類寫法的人還可以舉出例子：歐美、日本等軟件外包文檔都是這樣做的。

　　另外一種觀點就是主張寫的粗些，類似于編寫測試大綱。主張這種觀點的人是因為軟件開發需求管理不規范，變動十分頻繁，因而不能按照歐美的高標準來編寫測試用例。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。

　　實際上，軟件測試用例的詳細程度首先要以覆蓋到測試點為基本要求。舉個例子：“用戶登陸系統”的測試用例可以不寫出具體的執行數據，但是至少要寫出五種以上情況()，如果只用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面(如果組合情況較多時可以采用等價劃分)。

　　另一個影響測試用例的就是組織的`開發能力和測試對象特點。如果開發力量比較落后，編寫較詳細的測試用例是不現實的，因為根本沒有那么大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善。測試對象特點重點是指測試對象在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。

　　因此，測試用例的編寫要根據測試對象特點、團隊的執行能力等各個方面綜合起來決定編寫策略。最后要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時，不斷地提高自身能力。