手動軟體測試面試：10 道面試 問題與實用解答

先從這十道問題開始，並根據你能誠實說明的工作經驗調整範例答案。回答軟體測試面試問題時，請連結需求、輸入、預期結果，以及你選擇該做法的理由。

1. 你會如何測試數量欄位？

範例回答：「我會先確認允許的值和提交行為，再測試可接受的數量、不可接受的數量，以及邊界。若整數範圍是 1–10，我會測試 0、1、10 和 11，並明確列出預期結果。」

2. 等價類別劃分和邊界值分析有何不同？

「等價類別劃分會將預期受到相似處理的輸入分組；邊界值分析則針對有序分區的邊界進行測試。以數量為例，我會選 5 作為一般的有效值，再檢查 1 和 10 附近的接受條件在哪裡改變。」

3. 測試案例應包含哪些內容？

「我需要提供足夠的細節，讓另一位測試人員能重複執行檢查。以結帳為例，我會列出起始購物車、帳戶狀態、數量、操作和預期訂單總額，再對照受測版本記錄實際結果。」

4. 你會如何測試彼此交互作用的業務規則？

「我會先列出條件和預期動作，再選擇要測試的組合。如果結帳需要商品有庫存且付款獲得核准，我會一起涵蓋這兩個條件，也包括商品有庫存但付款遭拒的情況。」

5. 什麼時候狀態會影響測試？

「我會在不同的起始狀態下測試相同操作。從準備就緒的購物車提交訂單可能有效；付款處理中再次提交，則應依照已協議的重複提交規則處理。」

6. 缺陷修復後要測試什麼？

「確認測試會檢查修復是否有效；回歸測試則會檢查其他地方是否受到不利影響。修正數量 10 被拒絕的問題後，我會重跑該失敗案例，並根據變更挑選附近的數量和結帳檢查。」

7. 你會如何回報間歇性失敗？

「我會記錄條件、嘗試次數、時間戳記和證據。如果結帳在十次嘗試中失敗兩次，我會如實回報這項觀察，保留成功和失敗的操作序列，並避免把推測的原因說成已確認的事實。」

8. 嚴重程度和優先級有何不同？

「嚴重程度關乎影響；優先級關乎何時修復。我會描述受影響的購買流程和可用的替代做法，再和團隊討論排程，而不會把自己的初步評級當成最後定論。」

9. 如果需求不清楚怎麼辦？

「我會提出具體問題：輸入 2.0 算不算整數數量？我會記錄協議好的解讀，並以此作為測試預期，而不是默默選擇自己偏好的行為。」

10. 如果時間太少怎麼辦？

「我會先處理可能阻礙購買或造成錯誤扣款的失敗，再說明哪些部分尚未測試。我的進度更新會列出受測版本、結果、缺口和建議，讓發布負責人做決定。」

先把範圍轉換成可觀察的行為，再談測試技術。範例需求：必填的數量欄位接受 1 到 10（含兩端）的整數。有效提交會在購物車中加入正好該數量的商品。無效提交會顯示數量驗證訊息，且購物車維持不變。假設每個案例的庫存充足，購物車一開始都是空的。

在這個練習中，先約定空白輸入、小數（例如 1.5）和文字（例如「two」）都會被拒絕。至於 2.0、前置零或前後空格等表示方式是否接受，則需要另外訂定格式規則。不要默默把這些選擇視為整數範圍需求的一部分。

將數字分成三個等價類別：小於 1 的整數、介於 1 到 10 的整數，以及大於 10 的整數。挑選代表值後，再著重測試接受條件的邊界。下表包含中間值、邊界檢查和輸入格式檢查。

口頭回答範例：「我會重設購物車，輸入 10 並提交一次，確認購物車中有 10 件商品。接著重設購物車並測試 11，預期會出現驗證訊息且購物車不變。這樣能檢查上限的接受邊界，也不會把畫面上顯示的值誤認為更新成功。」

如果介面不允許輸入字母，請記錄這個行為並測試支援的操作方式；不要聲稱自己提交了無法輸入的內容。如果面試官將庫存改為八件，先停下來釐清庫存規則如何與數量上限交互作用。

本文術語參照ISTQB CTFL v4.0.1 大綱，由 Foundation Level 大綱團隊撰寫，並在此註明 ISTQB 與大綱作者為來源及著作權所有者。本指南中的需求範例和回答均為面試範例。

將決定結果的條件，與導向該結果的操作順序分開檢視。範例假設：購物車中有一件有效商品；付款前會先檢查庫存；只有在有庫存時才會提出付款請求；只有付款獲得核准後才會確認訂單。付款遭拒時，購物車仍可供再次嘗試。

整理精簡決策表時，若付款不可能發生，就標示為「未提出」。這樣不會假裝不可能的組合也需要測試結果。

接著描述狀態：準備就緒、付款處理中、付款失敗，以及已確認。依序走過「準備就緒 → 付款處理中 → 付款失敗 → 付款處理中 → 已確認」。每個步驟都檢查畫面上的狀態，以及是否已建立訂單。

付款處理中再次點擊需要另外訂定規則。假設協議好的行為是在顯示進度時忽略重複提交。預期結果是提出一次付款請求，最後建立一筆訂單，而不是兩筆。說明你需要哪些證據才能在提供的測試環境中確認結果；只有按鈕停用，無法證明下游實際發生了什麼。

回答軟體測試相關面試問題時，請說清楚兩者的關係：條件表整理各種選擇，狀態序列則揭露依賴先前事件的行為。在判定結果為缺陷前，請面試官確認重試和重複提交的預期。

先說明原本的失敗，再描述這次變更可能影響的範圍。範例：版本 Q-17 會拒絕數量 10，儘管需求允許該值。版本 Q-18 已包含修復。首先，在 Q-18 上以相同的起始條件重做記錄的步驟，並檢查購物車結果，而不只是確認錯誤訊息消失。

接著選取一組聚焦的回歸測試：

• 測試 1 和 10 是否為可接受端點，並測試 0 和 11 是否為遭拒的相鄰值。
• 測試 5，確認修復不會意外地只接受端點。
• 將既有購物車品項的數量從 9 改為 10，並確認數量與總額。
• 移除該品項再重新加入，檢查相關的購物車流程。
• 依協議完成數量為 10 的結帳流程，並確認訂單數量。

如果開發人員變更了購物車編輯共用的驗證器，該流程就值得特別留意。如果變更範圍單純，可以討論縮小測試範圍，同時仍考量失敗的影響。詢問變更了哪些元件，不要只從工單標題猜測。

為每項檢查記錄結果，並連結到修復和版本。如果數量 10 現在可用，但 11 也能成功，請回報新的失敗；原本的症狀消失，不足以作為結束所有測試的理由。回答最後說明剩餘範圍和任何受阻的檢查。

提供一份面試官可以直接交給隊友的報告。缺陷報告範例：數量需求仍是 1–10（含兩端），但測試環境會拒絕上限值。以下識別資訊和觀察結果都屬於這個範例。

ID：QTY-24
標題：加入有庫存的商品時，數量 10 遭拒
觀察日期：2026-11-05
回報人：Alex，手動測試人員
狀態：開啟
版本：Q-17
環境：QA 商店，桌面瀏覽器；已附上確切版本
參考：需求 QTY-01；測試案例 QTY-BOUNDARY-10
前置條件：購物車為空；已登入測試帳戶；商品庫存為 20
資料：數量 10；商品 TEST-MUG

步驟：
1. 開啟 TEST-MUG 商品頁面。
2. 在數量欄位輸入 10。
3. 選取「加入購物車」一次。
4. 檢查驗證訊息和購物車。

預期結果：沒有數量驗證錯誤；購物車中有 10 件 TEST-MUG。
實際結果：出現數量驗證錯誤；購物車仍為空。
重現情況：3 次嘗試均失敗；每次都重設購物車。
影響：顧客無法一次加入允許的最大數量。
觀察到的替代做法：分兩次各加入 5 件，購物車數量會達到 10。
建議嚴重程度：依本團隊的影響程度量表為中等。
建議優先級：在大量訂單促銷前於分流會議中檢視。
證據：錯誤訊息截圖、工作階段錄影和時間戳記已附上。

實際撰寫報告時，請取代環境佔位文字，並附上所引用的證據。帳戶資料和錄影內容應符合團隊的處理規範。請另行說明推測的原因：「可能是上限比較問題」只是線索，不是觀察到的結果。

結合情境討論影響和排程。替代做法可能減輕眼前的影響，但即將到來的促銷活動可能讓修復更加急迫。其他團隊可能使用不同的評級標籤。先說明顧客所受影響及時間因素，再對應到當地量表。如果開發人員無法重現問題，應一併比較版本、資料、帳戶和操作順序，再變更工單狀態。

把不確定之處轉化為明確的決策請求。範例：「工單寫著顧客可以重試付款，但沒說付款遭拒後購物車預留是否仍有效。重試時應重新檢查庫存嗎？」將回答記錄在需求旁，並更新預期結果。在得到答案前，請將預期標記為未解決，而不是把檢查算作通過。

期限迫近時，根據可能造成的傷害及受影響功能安排測試順序。以結帳為例，先檢查訂單建立、付款失敗、重複提交和數量總額。若還有時間，再檢查影響較低的呈現細節。如果設定相依性阻礙高風險檢查，請升級回報阻礙，同時執行有用且獨立的測試。

發布進度更新應簡短，並包含四個部分：測試了什麼、發生了什麼、哪些仍未知，以及需要做出什麼決定。

範例：「在 Q-18 上，可接受和遭拒的數量檢查均已通過；一次核准的結帳建立了預期訂單。付款遭拒後的重試目前受阻，因為測試付款設定無法使用。我建議恢復該設定，並在發布前完成重試檢查。如果現在繼續發布，重試流程仍是明確的風險，需由發布負責人決定是否接受。」

不要把「已執行的檢查沒有失敗」說成「系統沒有缺陷」。請區分通過、失敗、受阻和未執行的檢查。回答涉及意見不合的測試面試問題時，說明你會如何與開發人員比對證據，並將尚未釐清的業務行為交由負責的決策者處理。最後提出實際的下一步，例如安排缺少的設定，或釐清重試規則。

使用 SayNow AI 練習清楚說明你的測試決策。其 AI 模擬面試提供包含問題和追問的語音對話，結束後會提供分數，以及針對流暢度、內容架構、情境契合度和目標達成情況的建議。

開啟求職面試情境前，先準備一個經過技術確認的指南範例。口頭回答時，先說決策，再解釋相關需求並給出預期結果。回顧過往經歷時，例如調查有爭議的缺陷，可使用 STAR 架構。對話追問模糊之處時，直接回答，不要從頭重講整個故事。

練習後，從回饋中選一項調整：提早說明預期結果、縮短背景，或更清楚交代自己的行動。記住這項調整，再練習一次。SayNow AI 不會檢查技術正確性；請另外依據需求，並向有經驗的測試人員確認你的測試推理。請讓口說分數維持在適當定位，作為練習回饋。

在求職面試情境中練習說明你的面試回答。

最後再練習一次，並改變條件，而不是背熟每一句話。請練習夥伴改變數量上限、取消替代做法，或詢問支援失敗報告的證據是什麼。你的任務是調整測試預期，並說明其影響。

用這份清單檢視回答：

• 聽者能否辨識需求和任何假設？
• 你是否提供具體測試資料和可觀察的預期結果？
• 別人能否根據報告所述的起始條件重現缺陷？
• 你是否說明變更後所選測試為何重要？
• 你是否區分觀察到的結果、推測的原因和未解決的問題？
• 你是否說明下一步行動，以及誰需要這項資訊？

準備軟體測試職位的面試問題時，除了技術範例，也要準備一則專案故事。描述你自己的貢獻，以及你實際觀察到的結果。參考相關的行為面試和 STAR 指南，讓故事聚焦。

有力的手動軟體測試面試問題回答，會將明確需求連結到有目的的輸入、預期結果，以及有理有據的下一步決策。練習數量範例，將缺陷報告改寫為你能誠實討論的經歷，並說明所選檢查完成後仍存在的風險。