初級軟體測試必問面試題
1、你的測試職業發展是什麼？
測試經驗越多，測試能力越高。所以我的職業發展是需要時間積累的，一步步向著高階測試工程師奔去。而且我也有初步的職業規劃，前 3 年積累測試經驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務。
優勢在於我對測試堅定不移的信心和熱情，雖然經驗還不夠，但測試需要的基本技能我有信心在工作中得以發揮。
2. 什麼是黑盒？什麼是白盒？黑盒和白盒的測試方法分別有哪些？
- 黑盒: 黑盒測試也稱功能測試或資料驅動測試。把程式看作一個不能開啟的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，對程式介面進行測試。“黑盒” 法著眼於程式外部結構、不考慮內部邏輯結構、針對軟體介面和軟體功能進行測試
- 常用的黑盒測試方法：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法。
- 白盒測試: 也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試
- 常用白盒測試方法
- 靜態測試：不用執行程式的測試;
- 動態測試：需要執行程式碼，通過執行程式找到問題;
- 邏輯覆蓋包括: 語句覆蓋、判定覆蓋、條件覆蓋、判定 / 條件覆蓋、條件組合覆蓋和路徑覆蓋
-
- 語句覆蓋每條語句至少執行一次。
-
- 判定覆蓋每個判定的每個分支至少執行一次。
-
- 條件覆蓋每個判定的每個條件應取到各種可能的值。
-
- 判定 / 條件覆蓋同時滿足判定覆蓋條件覆蓋。
-
- 條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
-
- 路徑覆蓋使程式中每一條可能的路徑至少執行一次。
3. 測試流程：
需求測試 -> 概要設計測試 -> 詳細設計測試 -> 單元測試 -> 整合測試 -> 系統測試 -> 驗收測試
4. app 測試效能指標
- 記憶體
- cpu
- 流量
- 啟動速度
5. web 測試和 app 測試不同點
系統架構方面：
- web 專案，一般都是 b/s 架構，基於瀏覽器的
- app 專案，則是 c/s 的，必須要有客戶端，使用者需要安裝客戶端。
- web 測試只要更新了伺服器端，客戶端就會同步會更新。App 專案 則需要客戶端和伺服器都更新。
效能方面:
- web 頁面主要會關注響應時間
- 而 app 則還需要關心流量、電量、CPU、GPU、Memory 等。
相容方面：
- web 是基於瀏覽器的，所以更傾向於瀏覽器和電腦硬體，電腦系統方面的相容
- app 測試則要看解析度，螢幕尺寸，作業系統、網路。
- web 測試是基於瀏覽器的所以不必考慮安裝解除安裝。
- 而 app 是客戶端的，則必須測試安裝、更新、解除安裝。除了常規的安裝、更新、解除安裝還要考慮到異常場景: 包括安裝時的中斷、弱網、安裝後刪除安裝檔案 。
6. 缺陷按優先順序分為哪些型別？ p1-p5 面試重點
- 缺陷必須立即解決
- 缺陷要求正常排隊等待修復
- 缺陷可以在方便時被糾正
- 下一個版本修復
- 不修復
7. 測試用例的內容是什麼？ 面試重點
- 用例編號
- 測試概述或用例標題
- 測試步驟
- 預期結果
- 輸入資料
- 優先順序
- 前置條件等
8. 測試結束的標準是什麼？ 面試重點
- 全部測試用例都被執行完成
- 未修改 bug 都被確認或置為應有狀態，暫緩修改的問題都有詳盡的解析
- 測試報告編寫完成
- 測試收尾工作結束
- 測試總結完成
- 專案處於試執行或上線階段
- 在測試計劃中定義結束的標準：在一定效能下平穩執行多少天、本版本沒有嚴重 bug，普通 buh 數量在多少個以下，bug 修復百分之多少以上
- ；實際測試達到上述要求，由專案、開發、測試經理共同簽字，認同測試結束，版本即可釋出。
9、你為什麼選擇軟體測試行業
因為之前瞭解軟體測試這個行業，覺得他的發展前景很好。
10、根據你以前的工作或學習經驗描述一下軟體開發、測試過程，由哪些角色負責，你做什麼
要有架構師、開發經理、測試經理、程式設計師、測試員。我在裡面主要是負責所分到的模組執行測試用例。
11、根據你的經驗說說你對軟體測試 / 質量保證的理解
軟體質量保證與測試是根據軟體開發階段的規格說明和程式的內部結構而精心設計的一批測試用例 (即輸入資料和預期的輸出結果)，並根據這些測試用例去執行程式，以發現錯誤的過程。它是對應用程式的各個方面進行測試以檢查其功能、語言有效性及其外觀排布。
12、軟體測試的流程是什麼？
需求調查：全面瞭解系統概況、應用領域、軟體開發週期、軟體開發環境、開發組織、時間安排、功能需求、效能需求、質量需求及測試要求等。根據系統概況進行專案所需的人員、時間和工作量估計以及專案報價。
制定初步的專案計劃。
測試準備：組織測試團隊、培訓、建立測試和管理環境等。
測試設計：按照測試要求進行每個測試項的測試設計，包括測試用例的設計和測試指令碼的開發等。
測試實施：按照測試計劃實施測試。
測試評估：根據測試的結果，出具測試評估報告。
13、你對 SQA 的職責和工作活動 (如軟體度量) 的理解?
SQA 就是獨立於軟體開發的專案組，通過對軟體開發過程的監控，來保證軟體的開發流程按照指定的 CMM 規程 (如果有相應的 CMM 規程), 對於不符合項及時提出建議和改進方案，必要時可以向高層經理彙報以求問題的解決。通過這樣的途徑來預防缺陷的引入，從而減少後期軟體的維護成本。SQA 主要的工作活動包括制定 SQA 工作計劃，參與階段產物的評審，進行過程質量、功能配置及物理配置的審計等；對專案開發過程中產生的資料進行度量等等。
14、說說你對軟體配置管理的理解
專案在開發過程中要用相應的配置管理工具對配置項 (包括各個階段的產物) 進行變更控制，配置管理的使用取決於專案規模和複雜性及風險的水平。軟體的規模越大，配置管理就越顯得重要。還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標準，隨後的工作便基於此標準，並只有經過授權後才能變更這個標準。配置管理工具主要有 CC，VSS,CVS,SVN 等。
15、怎樣寫測試計劃和測試用例
簡單點，測試計劃裡應有詳細的測試策略和測試方法，合理詳盡的資源安排等，至於測試用例，那是依賴於需求 (包括功能與非功能需求) 是否細化到功能點，是否可測試等。
16、什麼是相容性測試？相容性測試側重哪些方面？
相容測試主要是檢查軟體在不同的硬體平臺、軟體平臺上是否可以正常的執行，即是通常說的軟體的可移植性。
相容的型別，如果細分的話，有平臺的相容，網路相容，資料庫相容，以及資料格式的相容。
相容測試的重點是，對相容環境的分析。通常，是在執行軟體的環境不是很確定的情況下，才需要做相容。根據軟體執行的需要，或者根據需求文件，一般都能夠得出使用者會在什麼環境下使用該軟體，把這些環境整理成表單，就得出做相容測試的相容環境了。
相容和配置測試的區別在於，做配置測試通常不是 Clean OS 下做測試，而相容測試多是在 Clean OS 的環境下做的。
17、我現在有個程式，發現在 Windows 上執行得很慢，怎麼判別是程式存在問題還是軟硬體系統存在問題？
–1、檢查系統是否有中毒的特徵；
–2、檢查軟體 / 硬體的配置是否符合軟體的推薦標準；
–3、確認當前的系統是否是獨立，即沒有對外提供什麼消耗 CPU 資源的服務；
–4、如果是 C/S 或者 B/S 結構的軟體，需要檢查是不是因為與伺服器的連線有問題，或者訪問有問題造成的；
–5、在系統沒有任何負載的情況下，檢視效能監視器，確認應用程式對 CPU / 記憶體的訪問情況。
18、測試的策略有哪些？
黑盒 / 白盒，靜態 / 動態 ## 標題，手工 / 自動，冒煙測試，迴歸測試，公測（Beta 測試的策略）
19、你覺得 bugzilla 在使用的過程中，有什麼問題？
–介面不穩定；
–根據需要配置它的不同的部分，過程很煩瑣。
–流程控制上，安全性不好界定，很容易對他人的 Bug 進行誤操作；
–沒有綜合的評分指標，不好確認修復的優先順序別。
20、描述測試用例設計的完整過程？
–1、需求分析 + 需求變更的維護工作；
–2、根據需求得出測試需求；
–3、設計測試方案，評審測試方案；
–4、方案評審通過後，設計測試用例，再對測試用例進行評審；
21、單元測試的策略有哪些？
邏輯覆蓋、迴圈覆蓋、同行評審、桌前檢查、程式碼走查、程式碼評審、景泰資料流分析
22、LoadRunner 分哪三部分？
使用者動作設計；場景設計； 測試資料分析；
23、LoadRunner 進行測試的流程?
–1、 熟悉業務流程，測試規劃
–2、 建立虛擬使用者指令碼
–3、 建立執行場景
–4、 執行測試指令碼
–5、 監視場景
–6、 分析測試的結果
以上，最好是結合一個案例，根據以上流程來介紹。
24、軟體的評審一般由哪些人參加？其目的是什麼？
在正式的會議上將軟體專案的成果（包括各階段的文件、產生的程式碼等）提交給使用者、客戶或有關部門人員對軟體產品進行評審和批准。其目的是找出可能影響軟體產品質量、開發過程、維護工作的適用性和環境方面的設計缺陷，並採取補救措施，以及找出在效能、安全性和經濟方面的可能的改進。
人員：使用者、客戶或有關部門開發人員，測試人員，需求分析師都可以，就看處於評審那個階段
25、Beta 測試與 Alpha 測試有什麼區別？
–Beta testing(β測試), 測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場
–Alpha testing (α測試), 是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試
26、你認為做好測試計劃工作的關鍵是什麼？
軟體測試計劃就是在軟體測試工作正式實施之前明確測試的物件，並且通過對資源、時間、風險、測試範圍和預算等方面的綜合分析和規劃，保證有效的實施軟體測試；
做好測試計劃工作的關鍵 ：目的，管理，規範
（1）、明確測試的目標，增強測試計劃的實用性編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試專案，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確
（2）、堅持 “5W” 規則，明確內容與過程 “5W” 規則指的是 “What（做什麼）”、“Why（為什麼做）”、“When（何時做）”、“Where（在哪裡）”、“How（如何做）”。利用“5W” 規則建立軟體測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文件和軟體的存放位置（Where）。
（3）、採用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完成後，如果沒有經過評審，直接傳送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
（4）、分別建立測試計劃與測試詳細規格、測試用例應把詳細的測試技術指標包含到獨立建立的測試詳細規格文件，把用於指導測試小組執行測試過程的測試用例放到獨立建立的測試用例文件或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
27、你認為做好測試用例工作的關鍵是什麼？
需求和設計文件的理解程度，對系統的熟悉程度
28、簡述一下缺陷的生命週期？
提交 -> 確認 -> 分配 -> 修復 -> 驗證 -> 關閉
29、軟體的安全性應從哪幾個方面去測試？
(1) 使用者認證機制：如資料證照、智慧卡、雙重認證、安全電子交易協議
(2) 加密機制
(3) 安全防護策略：如安全日誌、入侵檢測、隔離防護、漏洞掃描
(4) 資料備份與恢復手段：儲存裝置、儲存優化、儲存保護、儲存管理
(5) 防病毒系統
30、你覺得軟體測試通過的標準應該是什麼樣的？
缺陷密度值達到客戶的要求
31、一套完整的測試應該由哪些階段組成？
需求評審（有開發人員，產品經理，測試人員，專案經理）－>需求確定 (出一份確定的需求文件)－> 開發設計文件（開發人員在開始寫程式碼前就能輸出設計文件）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交 bug（有些 bug 需要開發人員的確定（嚴重級別的，或突然發現的在測試用例範圍之外的，難以重現的），有些可以直接錄製進 TD）－>開發人員修改（可以在測試過程中快速的修改）－>迴歸測試（可能又會發現新問題，再按流程開始跑）
32、如何理解壓力、負載、效能測試測試？
效能測試是一個較大的範圍，實際上效能測試本身包含了效能、強度、壓力、負載等多方面的測試內容。
壓力測試是對伺服器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的使用者數量、或者幾個使用者進行大資料量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是效能測試的重要部分。100 個使用者對系統進行連續半個小時的訪問可以看作壓力測試，那麼連續訪問 8 個小時就可以認為負載測試，1000 個使用者連續訪問系統 1 個小時也可以看作是負載測試。
實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體效能的高度上來對系統進行測試。
33、如何編寫提交給使用者的測試報告？
---- 根據內部測試報告進行編寫，一般可以摘錄；
---- 不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；
---- 報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的； - 報告上面的內容儘量要真實可靠；
---- 整個測試報告要仔細審閱，力爭不給專案帶來負面作用，尤其是效能測試報告。
34、您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
1 ．等價類劃分
劃分等價類: 等價類是指某個輸入域的子集合. 在該子集合中, 各個輸入資料對於揭露程式中的錯誤都是等效的. 併合理地假定: 測試某等價類的代表值就等於對這一類其它值的測試. 因此, 可以把全部輸入資料合理劃分為若干等價類, 在每一個等價類中取一個資料作為測試的輸入條件, 就可以用少量代表性的測試資料. 取得較好的測試結果. 等價類劃分可有兩種不同的情況: 有效等價類和無效等價類.
2．邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我, 大量的錯誤是發生在輸入或輸出範圍的邊界上, 而不是發生在輸入輸出範圍的內部. 因此針對各種邊界情況設計測試用例, 可以查出更多的錯誤.
使用邊界值分析方法設計測試用例, 首先應確定邊界情況. 通常輸入和輸出等價類的邊界, 就是應著重測試的邊界情況. 應當選取正好等於, 剛剛大於或剛剛小於邊界的值作為測試資料, 而不是選取等價類中的典型值或任意值作為測試資料.
3．錯誤推測法
基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況, 根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模組中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為 0 的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
4．因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法, 都是著重考慮輸入條件, 但未考慮輸入條件之間的聯絡, 相互組合等. 考慮輸入條件之間的相互組合, 可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類, 他們之間的組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合, 相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合於檢查程式輸入條件的各種組合情況.
35、你對測試最大的興趣在哪裡？為什麼？
最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。做測試，有部分是和人的性格有關，有部分需要後天的努力。但除了性格有關的我沒有把握，其他點我都很有信心做好它。
36、當開發人員說不是 BUG 時，你如何應付？
開發人員說不是 bug，有 2 種情況，一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3 方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先儘可能的說出是 BUG 的依據是什麼？如果還是不行，那我可以給這個問題提出來, 跟開發經理和測試經理進行確認, 如果要修改就改, 如果不要修改就不改。其實有些真的不是 bug，我也只是建議的方式寫進 TD 中，如果開發人員不修改也沒有大問題。如果確定是 bug 的話，一定要堅持自己的立場，讓問題得到最後的確認。
37、寫出 bug 報告當中一些必備的內容。
硬體平臺和作業系統
測試應用的硬體平臺（Platform），通常選擇 “PC”。
測試應用的作業系統平臺（OS）。
a) 版本 提交缺陷報告時通過該欄位標識此缺陷存在於被測試軟體的哪個版本。
b) Bug 報告優先順序
c) Bug 狀態
d) Bug 的編號
e) 發現人
f) 提交人
g) 指定處理人
h) 概述
i) 從屬關係
j) 詳細描述
k) 嚴重程度
l) 所屬模組
m) 附件
n) 提交日期
38、開發人員老是犯一些低階錯誤怎麼解決？
從兩個方面入手：
一方面從開發管理入手，也就是從根源來解決問題。可以制定規範的開發流程，甚至可以制定懲罰制度，還有就是軟體開發前做好規劃設計。
另一方面就是加強測試，具體做法就是加強開發人員的自己測試，把這些問題 “消滅” 在開發階段，這是比較好的做法。
39、簡述一下 c/s 模式或者 b/s 模式？
C/S 模式：客戶端 / 伺服器模式。工作原理：Client 向 Server 提交一個請求；Server 則使用一些方法處理這個請求，並將效果返回給 Client。
B/S 結構，即 Browser/Server(瀏覽器 / 伺服器)結構，主要是利用了不斷成熟的 WWW 瀏覽器技術，結合瀏覽器的多種 Script 語言 (VBScript、JavaScript…) 和 ActiveX 技術，用通用瀏覽器就實現了原來需要複雜專用軟體才能實現的強大功能，並節約了開發成本，是一種全新的軟體系統構造技術。