不可靠的電子郵件測試版本很簡短：建立一個地址，等待五秒，讀取第一封訊息，並期望它屬於本次執行。
可靠的版本仍然簡單，但它將投遞視為非同步。它會建立唯一地址、記錄開始時間、在截止時間內輪詢、匹配目標訊息、驗證產品操作，並在發生錯誤時提供足夠的上下文。
將 API 金鑰保留在 URL 之外
在 X-API-Key 標頭中傳送 GPTMail 金鑰。不要將其放在 ?api_key= 查詢參數中。URL 常會被瀏覽器歷史、存取日誌、監控系統與來源資料所保存。
X-API-Key: YOUR_API_KEY將金鑰儲存在 CI 的祕密管理器中，並在日誌中遮蔽。公開的每日金鑰方便探索；受控的自動化測試套件應使用可追蹤配額與使用情況的金鑰。
目前的端點與回應範例維護於 GPTMail API 文件頁面。
每次執行使用一個地址
為每個可獨立執行的測試產生新地址。不要依賴整個測試套件共用的收件匣來判斷正確性。
記錄地址、情境 ID、環境與測試開始時間。這些資訊可讓你在不記錄訊息機密的情況下，拒絕過時訊息並診斷衝突。
以截止時間輪詢，而非固定等待
電子郵件的投遞時間會變化。固定的五秒等待在投遞快速時浪費時間，投遞緩慢時則不穩定。
使用受限迴圈：
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)截止時間屬於測試合約。密碼重設流程可能需要不同於大量電子報預覽的限制。保持限制明確，以免緩慢的依賴無聲地延長整個 CI 工作。
精確匹配
「收件匣中的第一封訊息」不是有效的選擇器。匹配多個訊號：
- 收件者等於本次執行所建立的地址；
- 建立時間晚於觸發時間；
- 寄件者屬於預期的服務；
- 主旨或訊息類型符合流程；
- 訊息 ID 尚未被使用過。
當寄件者可能發出多個代碼時，選擇最新的匹配訊息。將其 ID 保留在測試輸出中，以防重試意外重用。
僅在列表匹配後才讀取
收件匣列出應作為低成本的探索步驟。僅對選定的候選者取得完整訊息。這可減少不必要的工作，並避免解析不相關的促銷郵件。
驗證業務結果，而不僅僅是六位數字的存在。提交代碼或開啟預期的連結，然後斷言帳號達到正確狀態。
將速率限制視為訊號
如果 API 回傳配額或速率限制回應，停止當前嘗試並顯示重置資訊。過度重試會把明確的容量訊號變成噪音，並可能延遲不相關的測試。
在測試執行器限制併發，特別是當套件一次建立大量地址時。小型工作池比數百個同時輪詢迴圈更易除錯。
清理時不隱藏失敗
清理應在取得證據後執行。成功時，刪除訊息或讓短期保留自行處理。失敗時，將地址與訊息 ID 保留在受保護的 CI 產物中，足夠長的時間供調查，之後再刪除。
絕不要在公開的建置日誌中印出驗證代碼、私人連結或完整的 HTML 內容。
使重試具備冪等性
將測試以新執行與新地址重試。不要假設對相同帳號與收件匣重複相同請求會從乾淨狀態開始。寄件者可能會使舊代碼失效、限制重複請求，或拒絕重複的邀請。
若網路請求逾時，需區分「未收到回應」與「操作未發生」。在執行破壞性重試前，先檢查可觀測的狀態。
回報失敗點
有用的自動化失敗會指出以下階段之一：
- 地址產生失敗；
- 產品操作在郵件排入佇列前失敗；
- 在截止時間前未收到匹配的訊息；
- 訊息已到達但內容不匹配；
- 驗證操作失敗；
- 清理失敗。
此分類將間歇性的「電子郵件測試失敗」轉化為團隊可負責的工作。
欲了解更大的測試矩陣，請閱讀 真實電子郵件測試計畫。若需投遞診斷，請使用 驗證電子郵件未送達：找出斷點。