招募表單測試案例怎麼設計

招募表單測試案例是圍繞申請流程設計的一組輸入與期望結果。表單越長，測試的難點就越不落在單一欄位的格式，而是落在步驟之間、欄位之間的組合。以下說明怎麼挑出真正值得測的分支、必填規則為什麼會變動，以及中斷與重複提交該怎麼處理。

招募表單為什麼容易漏測?

因為它的欄位不是彼此獨立的，而是彼此牽動。上一頁選了「有工作經驗」，下一頁才會出現工作經歷區塊；選擇某個地區，之後的地址與學歷選項都會跟著換一組。這種連動讓欄位的可能組合數量遠大於欄位本身，逐欄位測試自然覆蓋不到。

第二個原因是多步驟。資料分散在不同步驟中，中途離開、返回修改、跳回前面補資料都會讓狀態變化。若測試只在一次連續填完的情況下驗證，這些路徑完全不會被走到。

第三個原因是規則寫在流程層而不是欄位層。必填、格式與上限常常依前面的答案決定，若測試只看單一畫面，會誤以為規則永遠相同。

不必窮舉所有組合，但至少要覆蓋四類會讓流程走不同路徑的申請者。

四類之外的變化通常是這四類的細節差異，可以放在同一組用例中做資料變體。把重點放在分支而不是把所有欄位組合都寫成用例，才不會讓測試量爆炸而覆蓋面反而變窄。

還要補一類「刻意不完整」的用例：只填到一半就送出、跳過選填區塊、到達最後一步前返回修改。這些不是異常情況，而是真實申請流程裡很常見的行為。

還有一個常見的失效模式：欄位在兩個步驟裡同時出現，例如地址先在聯絡資料步驟填一次、又在申請資料步驟填一次。兩處若各自驗證、各自保存，就會出現兩邊不一致卻都不報錯的情況。測試時應該刻意在其中一處修改，觀察另一處是否同步。

因為表單的邏輯是條件式的。選了「在學」時，畢業年份可能不需要填；選了「已畢業」時它就變成必填。選了某個地區，某些欄位的格式與長度上限跟著換。選了「無工作經驗」時，整段工作經歷的必填範圍就整體消失。

這意味著必填規則必須與觸發它的答案一起測試，而不是單獨測。只測「畢業年份為空時會報錯」是不夠的，還要測「在學時畢業年份為空不該報錯」。前者測的是規則存在，後者測的是規則條件正確。

設計用例時可以這樣組織：每個條件式規則至少兩筆用例，一筆讓條件成立、一筆讓條件不成立，並確認兩邊的行為互斥。這樣規則的邊界就會被完整走過。

重複提交要分兩種情況。一種是同一次填寫被送了兩次，系統應該只建立一筆申請；另一種是同一個人在不同時間送了兩次，這可能需要合併、可能需要允許，端視流程而定。兩者混在一起，會讓行為變得無法預測。

草稿恢復驗的是中斷後能不能接續。至少要測三件事：中斷後重新進入，已填的內容還在不在；若草稿有保存期限，過期後的提示是否清楚；若草稿與正式提交同時存在，兩者的關係是否明確。

還有一個容易漏掉的環節是「編輯已提交的申請」。若流程允許修改，修改後的版本與原版本怎麼區分、是否需要重新送出，都屬於這一類用例。表單越複雜，這條路徑越容易被忽略，卻也越容易出錯。

表單用例需要的是「能走完整條路徑」的輸入，而不是一堆邊界值。邊界值適合用來測單一欄位的驗證，流程用例則需要一份欄位彼此相稱的紀錄，否則會在中途被不相關的規則擋下，測不到真正想測的那一段。

這也是為什麼流程用例通常以整條紀錄為單位。用一整條彼此對應的紀錄走到最後一步，遠比用零散的值拼湊更有意義。

在本站的職業檔案產生器裡產生的職業檔案欄位齊全、彼此對應，適合拿來當招募表單的填入內容；同一筆紀錄的職位、經歷、學歷與技能互相一致，填到流程後段時不會因為矛盾而被擋下。若你的用例重點在履歷檔案本身的解析，可以讀履歷解析測試夾具怎麼組織；想先理解一份完整紀錄的欄位結構，職業檔案測試資料是起點。

用例清單建議按流程階段分組，每個階段內部再按分支分組。這樣當某個階段的規則改動時，受影響的用例範圍一目瞭然，不必重新翻整份清單。

跨欄位的組合要挑有代表性的，而不是全排列。挑選原則有兩個：一是條件分支處（規則會改變的地方），二是資料依賴處（一個欄位的合法值取決於另一個欄位）。這兩類佔了實際缺陷的多數。

期望結果要寫成可觀察的行為，而不是實作細節。例如「儲存後在清單中出現一筆」比「呼叫了某個內部函式」更適合當作期望值，因為前者在重構後依然有效。這類用例在版控裡怎麼維持穩定，可以參考可重現的測試資料。

先把現有表單的條件式規則列出來，逐條確認是否都有成立與不成立兩筆用例。接著補上四類分支各一筆完整流程用例，並實際跑一次中斷恢復。

本文提到的表單用例與填入內容都是占位文本，只供流程測試與示範使用，不代表任何人的申請資料。