OTP 自動化測試處理的是那串幾位數字或英數混合的代碼：寄到信箱、由人輸入、幾分鐘內有效。把它自動化的難點不在解析，而在時序——信什麼時候到、你怎麼確定拿到的是最新那一封、失敗時又該怎麼判斷原因。以下依序說明。
端到端測試要從哪裡取得驗證碼？
流程通常固定：觸發一次寄送，到測試信箱取得最新的一封，從信裡取出那段代碼，貼回表單送出。三個步驟看起來都很簡單，真正的變數在第一與第二步之間。
第一步的問題是「哪一個信箱」。如果測試共用一個信箱，你就無法保證剛收到的那封信屬於這一條測試；並行執行時尤其明顯，兩個測試會互相搶信。
第二步的問題是「哪一封是最新」。收件匣裡可能躺著上一輪留下的舊信，也可能因為重試而出現兩封內容相同的信。只按「收件匣第一封」取，等於把結果交給排序運氣。
因此實務上的作法會加上兩個條件：每個測試使用獨立地址，以及按收件者或主旨等可辨識的欄位挑信。這兩個條件讓「取最新」變成一個有依據的動作，而不是猜測。
為什麼逾時、舊信與限流會出現？
逾時來自非同步的本質。應用程式把信交給寄信伺服器之後就繼續往下跑，真正的投遞時間不受測試控制。偶爾慢一點是正常的，問題在於等待時間一旦被寫死，測試就會在慢的時候失敗、在快的時候浪費。
舊信干擾來自狀態沒有被清乾淨。上一輪的信還留在同一個地址裡，這一輪的解析就會抓到過期的代碼；而過期的代碼通常只會回一個「驗證碼錯誤」，讓人往錯的方向查。
重發限流來自產品設計。同一支手機或同一個信箱短時間內重複要求寄送，系統本來就應該擋下來；這不是障礙，而是必須被保留的保護機制，因為它同時擋掉了濫用。
三者常常同時出現：因為等了太久所以重寄，重寄觸發限流，限流讓第二封信根本沒寄出，最後測試收到的仍然是舊信。這也是為什麼診斷時要一次看完整條時間軸，而不是只看最後的失敗訊息。
重發限流為什麼不該為了測試而關掉？
關掉限流等於把測試環境改成一個永遠不會遇到限流的環境，那麼上線之後第一次遇到限流就會是使用者的問題。限流是功能的一部分，測試應該驗證的是「被限流時系統怎麼回應」，而不是讓它消失。
比較好的作法是準備兩種資料：一種是正常情況，驗證碼可以在預期時間內取得；另一種是刻意觸發限流，確認畫面出現清楚的說明與可行的等待或替代路徑。後者往往比前者更有價值，因為它覆蓋的是使用者最容易放棄的時刻。
另外要避免的是「重試到底」。當第一次取信失敗，直接重寄一封，很容易在幾秒內把配額用光。應該先確認前一封是不是晚到，再決定要不要重寄。
還有一種失敗模式很難從錯誤訊息看出來：流程拿到的其實是上一輪的代碼。如果那個代碼還沒失效，整個流程會走完，測試顯示通過，但實際上這次寄出的驗證碼從頭到尾沒有被使用過。要擋掉這種假通過，斷言裡就必須比對「剛剛那一封」與「實際填入的那一串」是不是同一個，而不是只確認流程沒有報錯。
人工兜底什麼時候必須保留？
當流程涉及真實的裝置、真實的簡訊通道，或需要通過無法在測試環境重現的關卡時，全自動就會變成一個脆弱的假象。這種情況下保留一段人工確認，比強行自動化更誠實。
還有一種情況是驗證碼的來源不穩定。若某個外部通道的回應時間與失敗率本來就高，那麼自動化的價值會被不穩定抵銷；此時可以自動化前段、人工確認後段，並在文件裡寫明哪一段是自動、哪一段是人為。
判斷標準很簡單：如果這條自動化測試每週都要有人手動重跑才會過，那它其實已經不是自動化測試，而是一份需要人照顧的腳本。
在本站的臨時信箱裡觀察整條流程
在本站的臨時信箱裡產生一個地址、實際觸發一次寄送，就能看到驗證碼在收件匣裡被單獨標示出來的樣子；把它和自動化流程拿到的結果對照，很容易看出解析邏輯漏掉了什麼。若你要測的是「沒收到信」這條分支，先讀信箱驗證測試會有現成的案例清單。
本工具產生的地址僅用於測試與接收註冊驗證信，不能用來冒充他人身分，也不得作為任何帳號的長期聯絡方式；請勿把這類地址用於規避網站的驗證或風控規則。
給開發者：解析的健壯性與逾時策略
把上面的問題收斂成幾條可以直接照著做的原則：
- 按可辨識的欄位挑信，不要按收件匣順序。主旨、收件者或信中的識別碼都可以，重點是讓選擇有依據。
- 每個測試一個地址。這是同時解決舊信干擾與並行搶信的最簡單方法。
- 輪詢到出現為止並設上限。上限讓失敗快速發生，並且要在逾時訊息裡寫清楚已經等了多久、查到幾封信。
- 解析要多寫幾種樣式。同一段代碼在純文字與另一種信件格式裡的呈現方式不同，只認一種寫法會在更換模板時壞掉。
- 一次執行只取一次碼。重複取信會拿到不同的代碼，讓失敗難以重現。
- 保留失敗當下的原始郵件。沒有原始內容的失敗回報，幾乎無法隔天重現。
下一步
先替驗證碼流程加上獨立地址與有上限的輪詢，這兩步就能讓大部分不穩定的測試安靜下來。接著可以讀測試環境擷取郵件，把整條寄信路徑收進自己的環境；上線前要做的整體檢查則整理在事務郵件測試清單。