軟體測試面試題 ,這是乙份集錦，也是乙份軟體測試人員學習的好工具書，非常實用。
01. 為什麼要在乙個團隊中開展軟體測試工作？
因為沒有經過測試的軟體很難在發布之前知道該軟體的質量，就好比 iso 質量認證一
樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測試的工作。在測試的
過程發現軟體中存在的問題，及時讓開發人員得知並修改問題，在即將發布時，從測試報告
中得出軟體的質量情況。
02. 您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？
我曾經做過 web 測試，後台測試，客戶端軟體，其中包括功能測試，效能測試，使用者
體驗測試。最擅長的是功能測試
03. 您所熟悉的軟體測試型別都有哪些？請試著分別比較這些不同
04. 的測試型別的區別與聯絡（如功能測試、效能測試……）
測試型別有：功能測試，效能測試，介面測試。
功能測試在測試工作中佔的比例最大，功能測試也叫黑盒測試。是把測試物件看作乙個
黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的
內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯
誤推測、因果圖和綜合策略。
效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各
項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。通過負載
測試，確定在各種工作負載下系統的效能，目標是測試當負載逐漸增加時，系統各項效能指
標的變化情況。壓力測試是通過確定乙個系統的瓶頸或者不能接收的效能點，來獲得系統能
提供的最大服務級別的測試。
介面測試，介面是軟體與使用者互動的最直接的層，介面的好壞決定使用者對軟體的第一印
象。而且設計良好的介面能夠引導使用者自己完成相應的操作，起到嚮導的作用。同時介面如
同人的面孔，具有吸引使用者的直接優勢。設計合理的介面能給使用者帶來輕鬆愉悅的感受和成
功的感覺，相反由於介面設計的失敗，讓使用者有挫敗感，再實用強大的功能都可能在使用者的
畏懼與放棄中付諸東流。
區別在於，功能測試關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的
功能問題。效能測試主要關注於產品整體的多使用者併發下的穩定性和健壯性。介面測試更關
注於使用者體驗上，使用者使用該產品的時候是否易用，是否易懂，是否規範（快捷鍵之類的），
是否美觀（能否吸引使用者的注意力），是否安全（盡量在前台避免使用者無意輸入無效的資料，
當然考慮到體驗性，不能太粗魯的彈出警告）？做某個效能測試的時候，首先它可能是個功
能點，首先要保證它的功能是沒問題的，然後再考慮該功能點的效能測試
04．您認為做好測試用例設計工作的關鍵是什麼？
白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程式邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模組輸出和輸入介面。不可能做到完全測
試，以最少的用例在合理的時間內發現最多的問題
05. 請試著比較一下黑盒測試、白盒測試、單元測試、整合測試、系統測試、驗收測試的區
別與聯絡。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要
求。白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規
格要求，所有內部成分是否以經過檢查。
軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做乙個黑
盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，
檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或資料驅動測試。黑盒
測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？
2、在介面上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有資料結構錯誤或外部資訊（例如資料檔案）訪問錯誤？
4、效能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做乙個
開啟的盒子，它允許測試人員利用程式內部的邏輯結構及有關資訊，設計或選擇測試用例，
對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀
態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程式模組進行
如下檢查：
1、對程式模組的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取「真」與取「假」的兩種情況都能至少測一遍。
3、在迴圈的邊界和執行的界限內執行迴圈體。
4、測試內部資料結構的有效性，等等。
單元測試（模組測試）是開發者編寫的一小段**，用於檢驗被測**的乙個很小的、
很明確的功能是否正確。通常而言，乙個單元測試是用於判斷某個特定條件（或者場景）下
某個特定函式的行為。
單元測試是由程式設計師自己來完成，最終受益的也是程式設計師自己。可以這麼說，程式設計師有
責任編寫功能**，同時也就有責任為自己的**編寫單元測試。執行單元測試，就是為了
證明這段**的行為和我們期望的一致。
整合測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴充套件。它的最簡單的形式是：
兩個已經測試過的單元組合成乙個元件，並且測試它們之間的介面。從這一層意義上講，組
件是指多個單元的整合聚合。在現實方案中，許多單元組合成元件，而這些元件又聚合成程
序的更大部分。方法是測試片段的組合，並最終擴充套件程序，將您的模組與其他組的模組一起
測試。最後，將構成程序的所有模組一起測試。
系統測試是將經過測試的子系統裝配成乙個完整系統來測試。它是檢驗系統是否確實能
提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）
系統測試的目的是對最終軟體系統進行全面的測試，確保最終軟體系統滿足產品需求並
且遵循系統設計。
驗收測試是部署軟體之前的最後乙個測試操作。驗收測試的目的是確保軟體準備就緒，
並且可以讓終端使用者將其用於執行軟體的既定功能和任務。
驗收測試是向未來的使用者表明系統能夠像預定要求那樣工作。經整合測試後，已經按照設計
把所有的模組組裝成乙個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步
驗證軟體的有效性，這就是驗收測試的任務，即軟體的功能和效能如同使用者所合理期待的那
樣。 06. 測試計畫工作的目的是什麼？測試計畫工作的內容都包括什麼？其中哪些是最重要
的？軟體測試計畫是指導測試過程的綱領性檔案，包含了產品概述、測試策略、測試方法、
測試區域、測試配置、測試週期、測試資源、測試交流、風險分析等內容。借助軟體測試計
劃，參與測試的專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試
實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計畫和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計畫主要從巨集觀上規劃
測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
所以其中最重要的是測試測試策略和測試方法（最好是能先評審）
07. 您認為做好測試計畫工作的關鍵是什麼？
1. 明確測試的目標，增強測試計畫的實用性
編寫軟體測試計畫得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試
計畫的價值取決於它對幫助管理測試專案，並且找出軟體潛在的缺陷。因此，軟體測試計畫
中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實
用性，便於使用，生成的測試結果直觀、準確
2．堅持「5w」規則，明確內容與過程
「5w」規則指的是「what （做什麼）」、「why （為什麼做）」、「when （何時做）」、「where
（在**）」、「how （如何做）」。利用「5w」規則建立軟體測試計畫，可以幫助測試團隊理
解測試的目的（why ），明確測試的範圍和內容（what ），確定測試的開始和結束日期（when ），
指出測試的方法和工具（how ），給出測試文件和軟體的存放位置（where ）。
3．採用評審和更新機制，保證測試計畫滿足實際需求
測試計畫寫作完成後，如果沒有經過評審，直接傳送給測試團隊，測試計畫內容的可能不准
確或遺漏測試內容，或者軟體需求變更引起測試範圍的增減，而測試計畫的內容沒有及時更
新，誤導測試執行人員。
4. 分別建立測試計畫與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立建立的測試詳細規格文件，把用於指導測試小組執
行測試過程的測試用例放到獨立建立的測試用例文件或測試用例管理資料庫中。測試計畫和
測試詳細規格、測試用例之間是戰略和戰術的關係，測試計畫主要從巨集觀上規劃測試活動的
範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
08. 您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試
用例設計工作中的應用。
1．等價類劃分
劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對於揭露程
序中的錯誤都是等效的.並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.
因此,可以把全部輸入資料合理劃分為若干等價類,在每乙個等價類中取乙個資料作為測試的
輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.等價類劃分可有兩種不同
的情況:有效等價類和無效等價類.
2．邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生
在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計
測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,
就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試資料,
而不是選取等價類中的典型值或任意值作為測試資料.
3．錯誤推測法
基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例
的方法.
錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情
況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模組中常見的錯誤. 以前產
品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為 0 的情況.
輸入**為空格或輸入**只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的
例子作為測試用例.
4．因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條
件之間的聯絡, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要
檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的
組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個
動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成
的就是判定表. 它適合於檢查程式輸入條件的各種組合情況.
09. 請以您以往的實際工作為例，10. 詳細的描述一次測試用例設計的完整的過程。
就說最近的這次**功能的測試吧
首先：得到相關文件（需求文件和設計文件），理解需求和設計設計思想後，想好測試
策略（測試計畫簡單點就ok 了），考慮到測試環境，測試用例，測試時間等問題。
第二步：設計測試用例，測試策略是：把**部分的功能點測試完，然後在進行系統測
試（另外個模組呢有另乙個測試人員負責，可以進行聯調測試），**模組的測試基本是功
能測試和介面測試（使用者併發的可能性很小，所以不考慮）：這次的**的輸入資料呢是使
用資料庫中的某張表記錄，如果表中某一資料記錄中新加進來的（還沒有被處理的，有個標
志位），**啟動後會立刻去刷那張表，得到多條資料，然後在進行處理。處理過程中，會
經歷3 個步驟，**才算完成了它的任務。有 3 個步驟呢，就可以分別對這 3 個步驟進
行測試用例的設計,盡量覆蓋到各種輸入情況（包括資料庫中的資料，使用者的輸入等），得出
了差不多50 個用例。介面測試，也就是使用者看的到的地方，包括傳送的郵件和使用者填寫資
料的頁面展示。
了，只有有機器能空於下來做該功能測試就可以做了），因為**本身的環境搭建和其他的
系統有點不同，它需要的測試環境比較麻煩，需要web 伺服器（apache,tomcat ），不過這次
需求呢，**部分只用到了tomcat，所以只要有tomcat 即可
第四步：執行測試
軟體測試面試題
1 軟體測試的目的是盡可能多的找出軟體的缺陷。y 2 beta 測試是驗收測試的一種。y acceptance testing 驗收測試是部署軟體之前的最後乙個測試操作。驗收測試的目的是確保軟體準備就緒，並且可以讓終端使用者將其用於執行軟體的既定功能和任務。3 驗收測試是由終端使用者來實施的。n 是...
軟體測試面試題
1.您認為做好測試用例設計工作的關鍵是什麼？白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程式邏輯結果 黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模組輸出和輸入介面。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題 2.測試計畫工作的目的是什麼？測試計畫工作的內容都包括什麼？其...
軟體測試面試題
11.需求測試注意事項有哪些？乙個良好的需求應當具有一下特點 完整性 每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要資訊。正確性 每一項需求都必須準確地陳述其要開發的功能。一致性 一致性是指與其它軟體需求或高層 系統，業務 需求不相矛盾。可行性 每一項需求...