信箱驗證測試的目標不是「點一次連結成功」而已，而是確認這條流程在最壞的情況下依然不會把帳號帶到錯誤的狀態。驗證信會過期、會被點兩次、會在不同瀏覽器被打開，也會有同一個信箱同時對應兩個帳號的狀況。以下把這些情況整理成一組可以照著跑的測試清單。
信箱驗證出現在哪些地方？
同一個機制在產品裡通常出現三次以上，而每次的風險都不一樣。
註冊驗證確認這個地址真的屬於填寫的人。它決定帳號能不能啟用，也決定後續通知要寄到哪裡。
變更信箱要同時處理新舊兩個地址：新地址必須收得到驗證信，舊地址通常要收到一封通知，讓原本的所有者知道這件事正在發生。這是防範帳號被盜的最後一道關卡，也是最少被測試的一條。
重設密碼與驗證共用同一套寄信機制，但它的驗證信就是帳號的鑰匙。這條路徑的每一次失誤都可能直接等於帳號遺失。
三條路的驗證信長得很像，所以模板、連結與狀態經常被共用；一旦共用，某一條路的行為改變就會同時影響另外兩條，這也是為什麼測試必須分開做。
一條驗證流程該準備哪些案例？
| 案例 | 輸入 | 預期結果 |
|---|---|---|
| 正常點擊 | 最新一封驗證信 | 狀態改為已驗證，可以繼續使用 |
| 重複點擊 | 同一封信任意點兩次 | 第二次不報錯，結果維持已驗證 |
| 過期連結 | 超過有效期限的信 | 明確提示已失效，並提供重新寄送 |
| 換瀏覽器 | 在另一個瀏覽器開啟連結 | 驗證仍然成立，不依賴原本的工作階段 |
| 同信箱兩個帳號 | 兩個帳號填同一個地址 | 行為一致且可預期，不出現互相覆蓋 |
| 信件沒到 | 完全沒有收到信 | 有重寄入口，且不會卡在無法前進的畫面 |
最後一列最常被漏掉。多數團隊只測「信到了會怎樣」，卻沒有測「信沒到會怎樣」；而真實世界裡，使用者第一次遇到的往往正是後者。
為什麼一定要測「驗證信沒到」這條路？
因為它是使用者的第一反應。信被歸進垃圾郵件、地址打錯一個字、寄送端延遲、對方拒收，任何一種都會讓人停在同一個畫面。如果畫面沒有提供重寄或其他出路，使用者只能離開。
測試這條路徑同時會逼出幾個設計問題：重寄有沒有次數限制？限制到了以後畫面怎麼說？地址明顯打錯時能不能直接修改，還是必須重新註冊？這些都不是後端邏輯，而是產品在關鍵時刻的態度。
更進一步，還要測「信到了但內容不對」。變數沒有被換成實際值、連結指向錯誤的環境、按鈕文字與實際動作不符，這些錯誤比收不到信更難被察覺，因為流程表面上走得完。
過期、重複點擊與併發點擊該怎麼判定？
原則是：驗證這件事必須是冪等的。同一個連結被開啟多次，結果應該一樣；兩次請求同時到達，也不應該產生兩個已驗證狀態。判斷方式不是看畫面顯示什麼，而是看後端最後留下幾筆紀錄。
過期則是另一種狀況。過期本身是設計，不是故障；重點在於系統要能明確說出「這個連結已經不能用」，並讓使用者有一條順暢的路可以重新取得。含糊的錯誤訊息會讓人反覆重試同一個失效的連結。
還有一個容易忽略的組合是「過期後又收到新的信」。舊連結仍然應該失效，不能因為新信寄出就讓舊連結復活；否則補寄機制反而擴大了可被利用的範圍。
判斷併發時還有一個實用的技巧：把兩次請求的結果都留下來，而不是只看最後的狀態。因為「兩次都成功」與「一次成功一次被忽略」在最終狀態上長得一模一樣，只有在回應層才看得出差別。
在本站的臨時信箱裡怎麼跑這些案例
在本站的臨時信箱裡，你可以一次產生多個地址，把六個案例分配到不同地址上跑，就不會出現兩條測試互相取走對方信件的狀況。要理解這些地址的壽命與限制，可以先讀臨時信箱是什麼。
這裡產生的地址僅供測試與驗證流程演練，不得當作真實聯絡方式或身分證明，也請不要用來繞過任何網站的驗證規則。測試完成後就把案例結果記錄下來，別讓地址成為流程裡唯一記得這件事的地方。
給開發者：驗證其實是一個狀態機
把驗證想成一條流程，而不是一連串的判斷，程式碼會清楚很多。狀態至少要有未驗證、已驗證，以及換綁中的中間狀態；換綁之所以需要中間狀態，是因為新地址還沒有確認之前，舊地址不能被直接丟掉。
幾條實務建議：
- 權杖一次性、有期限。用掉就失效，並在期限後自動失效；不要提供可以重複使用的長期連結。
- 先寫狀態轉移表，再寫程式。哪些狀態可以轉到哪些狀態，寫成表之後，測試案例幾乎就自動列出來了。
- 併發點擊要收斂。兩次請求同時到達時，只有一次應該真正改變狀態，另一次應該得到相同的結果而不是錯誤。
- 不要只測 happy path。正常路徑在開發過程中每天都被走過，最容易出問題的一直是那些沒有人手動走過的岔路。
- 換綁時通知舊地址。這一步是防盜用的關鍵，也應該有對應的測試案例。
下一步
先替你的驗證流程補上「信件沒到」與「重複點擊」這兩個案例，它們的投入最小、擋掉的問題最多。流程中如果會出現驗證碼，可以接著讀OTP 自動化測試；上線前想再做一次總檢查，可以參考事務郵件測試清單。