QA 檢查清單：用一次性信箱測試註冊與 OTP 流程（完整避雷版）

一、測試前準備（環境與資料）

1) 建立測試矩陣：你要覆蓋哪些組合

建議先把測試組合列出來，避免測到一半才發現只測了一種情況：

• 裝置：iOS / Android / Desktop（至少各一）
• 瀏覽器：Chrome / Safari / Edge（至少覆蓋主流）
• 網路狀況：穩定 Wi-Fi / 行動網路 / 低速或高延遲（可用網路調速工具模擬）
• 一次性信箱類型：短時效（類 10 分鐘）/ 可切換或可延長 / 收信專用（receive-only）
• OTP 型式：純數字碼 / 含字母碼 / 驗證連結 / 兩者並存

2) 測試帳號策略：避免污染資料與誤封

• 準備一組「可重複清理」的測試資料（例如固定的姓名、假手機、測試標記）。
• 若系統有防爆破或風控，請先跟後端／資安確認測試白名單方式，避免 QA 測到一半整個網域或 IP 被封。
• 建議每輪測試都用不同的一次性地址，並記錄「使用在哪個測試案例」，方便回溯。

3) 可觀測性準備：沒有記錄就很難定位

至少確認下列資訊是否能取得（透過 log、監控或管理台）：

• 寄信服務供應商回應（是否接受寄送、是否退信）
• 寄送延遲（排隊時間、實際送達時間）
• 退信原因（域名封鎖、SPF/DKIM/DMARC、收件箱拒收、內容被判垃圾）
• OTP 驗證 API 的失敗碼（過期、錯誤次數、重放、已使用等）

二、註冊流程 Checklist（表單到送出）

1) Email 輸入與格式驗證

• 是否正確允許常見 email 格式（含 +tag、含 subdomain、含長 TLD）。
• 是否避免過度嚴格（例如把合法的「+」誤判為不合法）。
• 錯誤提示是否清楚、是否就地顯示、是否有可讀的範例。

2) 一次性信箱的產品策略：允許或限制要一致

很多產品會「想擋一次性信箱」，但又沒有明確策略，導致使用者體驗很混亂。QA 要驗證：

• 若系統要限制一次性信箱：提示文字是否清楚？是否提供替代方案（例如改用企業信箱、或允許某些網域）？
• 若系統允許一次性信箱：不要在流程中途才突然拒絕，應在送出前就能判斷並提示。
• 同一規則在 Web / App / API 是否一致（避免某端可過、某端被擋）。

3) 送出行為：防呆與防連點

• 點擊「註冊／送出」後，按鈕是否有 loading 狀態並避免重複送出？
• 快速連點或返回再送出，是否會造成多封 OTP、或覆蓋掉舊 OTP 但 UI 沒提示？
• 送出成功後是否明確告知「已寄出」並提示可能延遲，避免使用者狂按重送。

三、OTP 寄送 Checklist（寄出、到達、內容正確性）

1) 寄送觸發：每一種入口都要測

• 首次註冊寄送 OTP
• 重送 OTP（Resend）
• 登入時 OTP（若支援無密碼登入）
• 更換裝置、異地登入、敏感操作再次驗證
• 忘記密碼／重設密碼（若同樣走 OTP）

2) 到達時間：以「體感」驗收，而不是只看 log

一次性信箱最常遇到的是延遲或被擋。QA 建議用「計時」的方式驗收：

• 寄出後 UI 是否提示「可能需要一點時間」並提供重送倒數。
• 若 30～60 秒內未到，使用者在 UI 上應該能做什麼？（重送、換信箱、返回修改）
• 若 2～3 分鐘仍未到，是否能給出明確下一步建議，而不是讓使用者無限等待。

3) 信件內容：可讀性與安全資訊

• 主旨是否清楚（使用者一眼知道是驗證碼，不像行銷信）。
• OTP 是否醒目、是否便於複製（尤其在手機上）。
• 是否包含有效時間說明、用途說明（註冊／登入／重設密碼）。
• 是否避免在信件中曝露過多個資（例如完整姓名、敏感資料）。

4) 多語系與格式：台灣常見雷點

• 繁體中文是否有正確斷行、標點、避免簡繁混用。
• 數字 OTP 是否有不必要的空格或分段，導致複製貼上錯誤。
• 深色模式／不同郵件客戶端是否造成字體看不清楚。

四、OTP 驗證 Checklist（輸入、錯誤、過期、重放）

1) OTP 輸入體驗

• 是否支援自動填入（iOS/Android 的 OTP autofill）？
• 多格輸入框是否能順暢貼上整串 OTP？
• 輸入錯誤是否即時提示、是否不清空已輸入內容（避免使用者崩潰）。
• 是否提供「更換 email」的入口（尤其一次性信箱被擋時）。

2) 錯誤訊息：要讓人知道怎麼做，不是只說失敗

OTP 驗證失敗至少要能分清這幾種：

• 碼錯：提示重新輸入，並顯示剩餘嘗試次數（若有限制）。
• 已過期：提示重送，並清楚顯示可以重送的時間點。
• 已使用：提示需重送新碼，避免使用者一直輸入同一組。
• 請求過於頻繁：提示等待多久，以及避免一直點造成更長的鎖定。

3) 過期策略驗收

• OTP 的有效時間是否符合產品設計（例如 5 分鐘、10 分鐘）。
• 過期後輸入舊碼，系統是否回傳正確錯誤原因，而不是模糊的「失敗」。
• 若使用者在 OTP 頁停留很久，UI 是否提醒可能過期，並提供重送入口。

4) 重放攻擊與安全邏輯（QA 也要驗）

• 同一組 OTP 是否只能使用一次（成功後再用必須失敗）。
• 不同裝置同時輸入同一 OTP，是否只允許一次成功，其餘得到合理提示。
• OTP 是否與特定 session／email 綁定，避免 A 的碼拿去驗 B 的帳號也通過。

五、Resend（重送）Checklist：最容易出事故的地方

1) 重送節奏與倒數

• 倒數是否準確、是否跨頁／回到前景仍正確。
• 倒數期間點擊重送是否被正確阻擋，並給出提示。
• 倒數結束後按鈕是否立即可用，不要卡住或需要刷新。

2) 多封 OTP 的處理規則要明確

常見兩種策略：新碼發出後舊碼失效，或允許多碼並存。無論哪種，QA 要驗證：

• 規則是否一致：寄出新碼後，舊碼的驗證結果是否符合策略。
• UI 是否提示「請輸入最新收到的驗證碼」。
• 使用者若晚收到舊信，是否會被誤導（內容是否能辨識時間或版本）。

3) 一次性信箱下的重送風險

• 若一次性網域被封鎖，重送只會讓使用者更挫折；應提供「更換 email」或建議換網域。
• 若信件延遲，重送可能造成多封堆疊；UI 需引導使用者找「最新」的那封。

六、一次性信箱專屬測試案例（建議必做）

案例 1：熱門一次性網域被封鎖

• 預期：系統若有封鎖策略，應在送出前就提示；若無封鎖策略，至少要能正常寄送。
• 驗收：錯誤提示清楚、可返回修改、流程不死鎖。

案例 2：收件延遲（1～3 分鐘才到）

• 預期：UI 要能承接等待狀態，提示使用者不要反覆重送；提供合理的重送倒數與操作選項。
• 驗收：使用者不會陷入「不知道該做什麼」的空白狀態。

案例 3：驗證碼過期後才輸入

• 預期：明確提示過期並引導重送；不要用含糊訊息造成誤會。
• 驗收：重送後的新碼可用、舊碼不可用（依策略一致）。

案例 4：重送後先收到舊信、再收到新信

• 預期：使用者很容易輸入第一封看到的碼；UI 與信件內容應引導使用「最新碼」。
• 驗收：輸入舊碼時提示要明確，避免使用者以為系統壞掉。

案例 5：快速連點與切換分頁

• 預期：後端要有 idempotency 或節流，前端要有防連點。
• 驗收：不會造成寄送風暴、也不會讓 OTP 狀態混亂。

七、驗收標準（Definition of Done）建議

若你需要一套可落地的驗收標準，可以用下面這些作為「可上線」門檻：

• 成功率：在主流裝置與瀏覽器下，註冊＋OTP 完成率穩定，且一次性信箱情境不會出現流程死鎖。
• 可理解性：所有常見失敗原因都有對應提示，使用者看得懂下一步要做什麼。
• 一致性：Web / App / API 行為一致，重送策略一致，舊碼是否失效的規則一致。
• 可恢復性：收不到信、過期、被封鎖時，使用者能在流程內自救（重送、換信箱、返回修改）。
• 安全性：OTP 不可重放、不可跨帳號使用；錯誤次數與節流策略有效且不誤傷正常使用者。

八、常見問題排查（給 QA 與工程師的共同語言）

1) 使用者說「收不到 OTP」

• 先確認：寄送 API 是否成功？寄信供應商是否接受？是否被退信？
• 再確認：是否被一次性信箱網域封鎖？是否寄到垃圾匣？是否延遲到達？
• 最後確認：前端是否提示錯誤的 email？是否誤導使用者一直重送？

2) 使用者說「一直顯示錯誤，但我輸入沒錯」

• 檢查是否輸入了舊碼（重送後舊碼失效但使用者不知道）。
• 檢查是否過期（使用者停在 OTP 頁太久）。
• 檢查是否多裝置同時操作造成狀態混亂。

3) 使用者說「重送按了沒反應」

• 倒數計時是否正確？是否被節流鎖住但 UI 沒提示？
• API 是否回傳成功但 UI 沒更新？或 UI 更新了但實際沒寄出？
• 是否因為一次性網域被封鎖，導致重送其實都失敗？

九、收尾建議：把一次性信箱當成「壓力測試」而不是「特例」

一次性信箱之所以值得納入 QA 流程，是因為它天然就包含了最棘手的變因：網域可能被封、收件延遲更常發生、使用者也更可能在短時間內反覆註冊／重送。你能在這種情境下把流程做得順，對一般使用者來說只會更順。

當你把寄送、接收、驗證、重送、過期、錯誤提示、風控策略都測得紮實，註冊流程不只「能用」，而是「讓人願意完成」。而這，往往就是產品成長的分水嶺。