事務郵件測試清單：註冊、找密與訂單通知上線前該檢查什麼

事務郵件是那些非寄不可的信：註冊確認、密碼重設、訂單成立、付款成功、發票開立。它們不像行銷信可以補寄，出錯時使用者通常正處於最需要完成的動作上。以下是一份可以逐項打勾的上線前清單，以及幾條只有踩過才會記得的細節。

事務郵件和其他信件差在哪裡？

差在觸發原因與期待。行銷信由你決定何時寄，事務信由使用者的行為觸發：他按下註冊、他忘記密碼、他完成付款。使用者在那一刻正在等這封信，所以延遲的體感比行銷信強得多。

第二個差別是可預期性。事務信的內容、收件者與時機幾乎是固定的，因此可以寫成明確的測試；也因為固定，模板一旦壞掉會影響所有人，而不是像行銷信那樣只影響某一批名單。

第三個差別是保存價值。訂單與發票常常被使用者當成憑證留下來，這表示內容必須正確到可以對帳，而不是「大致看得懂」。

上線前該逐項檢查什麼？

最後一列最常被跳過。付款成功的事件、佇列重試、使用者連點兩次送出，都可能讓同一封信寄出兩次；使用者的第一反應通常是「是不是被扣了兩次錢」。

為什麼重複觸發一定要測？

因為重試是系統的正常行為，不是異常。佇列在沒有收到確認時會重送，網路中斷會讓同一個事件被處理兩次，使用者也可能在沒看到回應時再按一次。

要讓這條路安全，關鍵是把「寄送」與「事件」的關係定義清楚。同一個事件只應該對應一封信；當系統無法確定前一封是否已寄出，寧可先記錄再判斷，也不要直接重寄。

測試的方式很簡單：刻意讓同一個事件被處理兩次，然後確認信箱裡只有一封信。這條案例的投入很小，但擋掉的客訴很具體。

寄不出去的時候會發生什麼？

寄送失敗通常不會直接讓流程中斷，因為多數系統在背景處理寄信。這代表使用者可能看到「已寄出」的提示，實際上信從來沒有離開。這種落差是最難排查的一類問題。

因此需要一個地方記錄每一次寄送的結果：觸發了什麼、寄給誰、成功或失敗、失敗的原因。當使用者回報沒收到信，這份紀錄就是唯一能回答問題的依據。

另一個要處理的是「延遲」與「退信」。信被拒收或地址不存在時，系統應該有機會讓使用者修正，而不是讓他一直等一封永遠不會來的信。

在本站的臨時信箱裡做最後一輪人工確認

自動化測試能確認信件內容正確，但排版、按鈕與在不同收信端的外觀，仍然需要有人看一次。在本站的臨時信箱裡產生地址，把主要幾種事務信都實際寄一輪，就能看出哪裡的字被截斷、哪個連結不好點。

要理解收件端的行為，可以先讀臨時信箱原理。這些地址僅供測試與接收註冊驗證信，不得視為真實身分，也不能用來冒充他人或寄送任何未經同意的內容。

給開發者：冪等、重試與日誌

• 寄送要有冪等鍵。同一個事件重複處理時，系統應該認得出來，而不是再寄一封。
• 重試要有上限與退避。失敗後立刻連投會讓對方更難接受，也會把自己送進對方的阻擋名單。
• 變數缺失要有兜底。模板變數沒有帶到時，寧可顯示一段安全文字，也不要讓信中出現未替換的符號。
• 連結要指向對應環境。測試信裡的連結連回正式環境，是最容易造成真實副作用的一種失誤。
• 日誌不要留敏感內容。一次性連結、驗證碼與完整地址都應該避免寫進日誌；記錄事件識別碼就足夠追查。
• 退訂要真的可用。行銷性質的信件提供退訂，且退訂後確實停止寄送，這件事需要測試而不只是實作。

為什麼要在上線前測多語系，又該留下什麼紀錄？

事務信一旦寄出就收不回來。同一封信在不同語言下可能換行位置不同，日期與金額的寫法也不同：有的地區習慣年月日，有的習慣月日年；小數點與千分位的符號甚至互換。這些差異在測試環境裡很容易被忽略，因為測試資料通常只有一種語言、一種幣別。

做法是把最關鍵的兩三種語言各寄一封，並刻意使用會邊界化的數字，例如金額剛好進位、姓名特別長、地址多行折行。真正會壞掉的地方不是翻譯本身，而是翻譯之後的長度變化。

另一件同樣要事先決定的是「出事時你手上要有什麼」。至少要有三樣：這次寄送的識別碼、當時使用的模板版本、以及收件端回應的結果。缺了任何一項，排查就會變成猜測。實務上最容易缺的是模板版本，因為模板常常被直接改動而沒有留下對應的紀錄。

把這三樣綁在同一個事件識別碼上，客訴進來時就能在一分鐘內回答「這封信到底有沒有離開我們的系統」。這也是把可重現的測試資料放進流程的理由：當每一次測試都能被重新產生，你才有辦法回頭重現那封出問題的信。

下一步

先從「重複觸發」與「變數缺失」這兩條案例開始補，它們的發生頻率高、修正成本低。要讓驗證碼相關的流程也穩定下來，可以接著讀OTP 自動化測試；想把整條寄信路徑收進自己的環境，則可以參考測試環境擷取郵件。