如何為 QA 選擇測試電子郵件帳號

什麼是 QA 測試電子郵件帳號？

測試電子郵件帳號（或稱 QA 測試電子郵件地址）是您的團隊用來接收並檢查自家應用程式所寄出郵件的地址。手動、非敏感的註冊與 OTP 檢查，可使用臨時收件匣。若需要保留郵件、回覆或附件，請選擇公司信箱；若自動化測試必須在無人介入的情況下檢查郵件，則選擇 SMTP 沙盒或託管收件匣 API。

Tmailor 經營這個部落格，以下說明它的定位。Tmailor 是免費、僅收信的臨時郵件服務，支援網頁、Android、iOS 及 Telegram 機器人。它適合第一種情況：由人開啟收件匣、觸發註冊，再閱讀收到的郵件。至於最後一種情況，則由獨立的 Tmailor 臨時郵件 API 讓自動化測試建立僅收信的地址，並從程式碼讀取郵件。郵件自抵達後約保留 24 小時，不收附件，且該地址無法寄信或回覆。如果您是初次接觸拋棄式信箱，建議先從 臨時郵件的運作 開始。

• 不需要有郵件寄達（表單驗證、測試資料、單元測試）：使用保留的範例網域。
• 由人閱讀郵件，且內容不含敏感資料：臨時收件匣是最快的選擇。
• 敏感資料、回覆、附件，或必須保留的證據：使用經核准、由公司控管的信箱；只有在您的郵件系統與應用程式支援時，才加上 Plus 標籤。
• 沒有專人監看：若您能控制應用程式的外寄郵件設定，請使用 SMTP 捕集器；若應用程式必須透過其正常服務供應商寄送，則使用託管收件匣 API。

手動與自動化電子郵件測試：決策樹

四個問題可決定一項檢查需要哪種測試電子郵件帳號：郵件是否必須寄達、由人還是程式碼讀取、是否含有敏感資料，以及您是否能控制應用程式寄出郵件的位置。

1. 考試 這項測試需要有郵件寄達嗎？ 格式檢查、UI 狀態、測試資料與單元測試通常不需要。請使用 example.com、example.org 或 example.net 的地址。這些網域保留給文件與範例使用，因此不會寄到真人手上。避免自行編造隨機網域，因為那些網域可能有人持有。
2. 考試 時有人會讀訊息嗎？ 煙霧測試、手動 UAT、示範與探索性測試都有人參與。回歸測試套件與 CI 工作通常沒有。
3. 若由人閱讀，內容是否含有敏感資料？ 真實的客戶紀錄、憑證、受法規規範的資料，或必須保留作為稽核證據的郵件，都不適合放在臨時收件匣。請改用公司信箱。若答案為否，臨時收件匣就足夠了。
4. 若由程式碼讀取，測試環境能否將郵件寄到測試用 SMTP 伺服器？ 若可以，SMTP 捕集器會擷取所有郵件而不實際投遞。若不行，因為應用程式必須透過其正常的電子郵件服務供應商寄送，請使用託管收件匣，由測試透過 API 讀取。

下表並排比較這五種選項。

電子郵件欄位應該接受或拒絕哪些地址？

將表單驗證與訊息送達分開測試。使用 user@example.com 這類保留地址作為看似有效但不會送達的案例，加入一個帶加號標籤的地址和一個帶子網域的地址，並加入格式錯誤的案例，例如缺少本地部分或缺少網域。預期結果應與你的生產系統實際使用的驗證器保持一致。

何時臨時信箱就足夠

當一個人一次只檢查一個流程，且訊息內容即使一天後遺失也無妨時，臨時信箱就派得上用場。這正是拋棄式信箱在品質保證中的經典用途：你需要一個電子郵件地址來手動測試表單，而不是一個長期使用的帳號。典型案例包括註冊表單的發布前冒煙測試、新手上路郵件的手動 UAT 驗收、帳號建立的銷售示範，或是嘗試各種奇怪輸入並觀察應用程式送出什麼的探索性測試。

它的吸引力在於速度。不必向 IT 申請帳號，也沒有共用信箱需要清理。代價是控制權：訊息保留時間短、沒有附件，而且收件匣是由人閱讀，而非由程式碼讀取。

何時需要 SMTP 擷取器或託管收件匣 API

一旦測試以無人值守的方式執行，收件匣就必須能被程式碼讀取。有兩類工具能滿足這個需求，而它們解決的是不同的問題。

SMTP 擷取器與沙盒 會在測試環境中取代應用程式的外寄郵件伺服器，並保留每封郵件供檢查，而不是實際送出。

• Mailpit 是一款免費的開源工具，由你自己架設運行。它預設會擷取郵件，並提供網頁介面與 REST API 供整合測試使用。
• MailHog 的運作方式相同，但較為老舊。Mailpit 的維護者表示它已不再維護，因此採用前請先確認其狀態。
• Mailtrap Email Sandbox 是同一概念的託管版本，提供 SMTP 與 API 存取。它與 Mailtrap 的正式寄送產品是分開的。
• Ethereal 是免費的模擬 SMTP 服務，主要搭配 Nodemailer 使用。訊息會被攔截供預覽，永遠不會實際寄出。

託管收件匣 API 會在廠商網域上提供測試用的真實地址，因此你的應用程式會透過平常的服務供應商寄信，測試再透過 API 讀取結果。Tmailor 自家的 Temp Mail API 就是這樣運作，並提供 Python、Node.js 與 PHP 的官方 SDK。

• Mailosaur 提供測試用電子郵件地址、API，以及可搭配 Cypress、Playwright、Selenium 等框架的用戶端函式庫。它也涵蓋簡訊驗證碼。
• MailSlurp 透過其 API 與 SDK 依需求建立收件匣。測試可以等待訊息送達，再擷取驗證碼、連結與附件。

廠商的功能與方案會變動，因此在把測試套件綁定到某一項之前，請先在各官方網站確認最新細節。

何時該改用搭配 Plus 標籤的公司信箱

Plus 標籤讓同一個公司信箱能接受多種地址變化。寄到公司網域 qa+signup 或 qa+reset 的郵件都會進入 qa 信箱，你可以依標籤篩選。Google Workspace 支援這項功能，Microsoft 也說明 Exchange Online 的 plus addressing 預設為開啟，除非管理員將其關閉。

當流程涉及真實客戶資料、執行時間超過一天、需要回覆或附件，或會產生稽核人員可能索取的證據時，請採用這個做法。但要留意其限制。標籤只是同一個信箱的變化形式，並非各自獨立的收件匣，因此平行進行的測試可能讀到彼此的訊息。有些註冊表單會拒絕加號，有些應用程式則會把帶標籤的變體視為同一個帳號。這兩種行為都值得各自設計一個測試案例。

如何用臨時信箱執行手動註冊測試

使用臨時信箱進行測試的手動註冊測試需要三樣東西：一個全新地址、你正在測試的版本，以及收件匣以外可記錄收到哪些郵件的地方。請只在你擁有或獲授權測試的系統上執行。

1. 開啟收件匣。 在網頁 上建立免費的臨時收件匣，或使用 Tmailor 應用程式或 Telegram 機器人，複製地址。在桌機上，Tmailor 瀏覽器擴充功能 也能將它填入測試版本的電子郵件欄位。
2. 在你的測試版本上註冊。 在預備或 QA 環境中使用該地址，並記下你提交表單的時間。
3. 留意郵件是否送達。 檢查收到的是哪一封郵件、寄件人名稱與寄件地址、主旨，以及花了多久時間。
4. 完成這個步驟。 點擊連結或輸入驗證碼。確認帳號狀態只變更一次，且重複使用同一連結會失敗並顯示清楚的訊息。
5. 把證據記錄在別處。 將連結、驗證碼、時間戳記與截圖複製到你的測試案例中。訊息自抵達起只保留約 24 小時，因此收件匣並不是你的測試紀錄。
6. 如果你要重考，請儲存存取權杖。 這個 token 之後可重新開啟同一個地址，例如重跑密碼重設流程。它無法還原已過期的訊息，而遺失的 token 也無法找回。

當一次工作階段需要同時扮演多個角色，例如免費用戶、試用用戶與受邀隊友時，多重收件匣檢視 可在同一個瀏覽器分頁中並排保留最多五個地址。每個角色各有自己的地址，因此你能看出哪封郵件屬於哪個帳號。

此檢視仍屬手動操作。收件匣是由人在瀏覽器中建立，而非由程式碼配置，因此無法取代託管收件匣 API 來進行平行無人值守的執行。

每次測試用一個收件匣還是一個地址？

單一共用收件匣適合快速煙霧測試，但很快就會變得雜亂。一旦多個測試同時執行，相似的主旨行會讓人難以分辨哪封郵件屬於哪個腳本，除錯也變成猜測。

每個測試案例用一個地址就能解決這個問題。日誌、截圖和郵件都能對應得上，缺少的訊息只指向單一情境，而非全部情境。關於如何管理多個臨時郵件收件匣 的指南會更詳細地介紹這個工作流程。

有些流程需要在幾天後再次使用相同地址，例如試用轉為付費，或用戶流失後回訪。可重複使用的臨時郵箱 可透過其 Access Token 讓地址保持可用，但郵件不會保留。請在每個步驟執行時儲存你需要的連結和代碼，並將任何依賴舊郵件的步驟移到公司信箱。如果測試人員在建立個人化地址前先登入 免費的 Tmailor 帳號，每個地址都會儲存在「已建立的電子郵件」下，因此遺失 token 不再代表遺失地址。

註冊與新手引導郵件該檢查什麼

先盤點流程中可能寄出的每一封郵件，再決定每個測試應斷言什麼。團隊往往要等到測試中途才發現額外的郵件，因為成長實驗或安全變更新增了一封沒人記錄下來的郵件。

典型註冊流程中的郵件

• 驗證連結或一次性驗證碼
• 歡迎郵件及任何快速入門流程
• Magic-link 登入
• 密碼重設
• 電子郵件地址變更，同時寄到舊地址與新地址
• 新裝置或新地點安全警示
• 未完成註冊提醒

針對每一個項目，寫下觸發條件、預期時間點，以及會改變它的條件，例如方案、地區或語言。請依產品文件記載的需求設定允許的送達時間範圍，不要假設有通用的門檻；即時驗證訊息與排定的歡迎流程需要不同的預期。有了這些預期之後，每個測試才有具體的依據可供檢驗。

每封測試郵件該驗證的重點

• 寄件人與收件人： 寄件人名稱與地址、Reply-To，以及確切的收件地址。
• 主旨與內文： HTML 與純文字兩種版本，並確認名稱、方案細節與語言正確。
• 連結： 連結的目的地，以及是否指向正確的環境。測試環境的郵件卻連到正式環境，這是真正的錯誤。
• 驗證碼： 格式、長度、有效期限說明文字，以及所標示的有效期限是否與伺服器實際執行的相符。
• 時間： 從觸發到訊息送達花了多久。
• 附件： 如果流程會寄送 PDF 或發票，請在公司信箱或測試工具中測試。Tmailor 不會接收附件。

關於呈現效果有一點要注意。臨時信箱只顯示某一個網頁檢視器如何呈現你的 HTML，並不會告訴你同一封郵件在 Gmail、Outlook、Apple Mail、深色模式或小螢幕手機上的樣貌，因此若這些很重要，請另行規劃呈現效果的檢查。

電子郵件變更與帳號復原流程

復原流程出錯的方式比註冊流程更不明顯。請檢查：變更電子郵件時是否向新地址寄送確認信、向舊地址寄送通知；已使用過的重設連結是否無法重複使用；較舊的重設連結在較新的連結寄出後是否失效；以及在第二台裝置開啟連結時，使用者是否會進入合理的狀態。OTP 流程值得另行進行風險審查；OTP 風險清單涵蓋了品質管理（QA）和 UAT 的風險清單，涵蓋指標、重送視窗和所有權。

如何測試 OTP 與驗證的邊緣情況

請針對延遲送達、重送、過期與錯誤的驗證碼，以及在另一台裝置開啟連結等情況，測試 OTP 與驗證流程。每個案例都應同時檢查伺服器端的結果與顯示給使用者的訊息。請只在你自己擁有或獲授權測試的系統上執行這些測試。好的 OTP 測試會刻意中斷流程：

• 送達緩慢： 先等待一段時間再查看收件匣，並確認介面有說明目前狀況，且提供明確的重送方式。
• 重送行為： 要求第二組驗證碼，檢查第一組是否失效或仍被接受。
• 過期： 在驗證碼標示的有效期限過後輸入，確認錯誤訊息與實際發生的情況相符。
• 錯誤的驗證碼： 確認嘗試次數上限與冷卻時間的說明文字對使用者而言是否合理。
• 跨裝置魔法連結： 在筆電上請求連結，在手機上開啟，然後查看使用者最後會去哪裡。

想更全面了解哪些驗證碼會送達臨時信箱、哪些不會，請參考這份關於 臨時郵件的 OTP 代碼 的指南。

如果你的產品刻意拒絕拋棄式信箱網域，請直接測試這條路徑。確認拒絕訊息清楚，且真實或公司管理的地址仍能完成註冊。不要為了繞過封鎖而改用其他臨時網域，無論是在自己的產品還是別人的產品上。確認封鎖有效才是測試；破解封鎖不是。這篇關於 網站封鎖臨時郵箱網域的原因說明，說明 的說明涵蓋了這些過濾機制背後的原因。

當電子郵件測試無人值守執行時會有什麼變化

當沒有人在旁監看時，測試需要一個能透過程式碼讀取的收件匣。這代表需要 SMTP 捕手的 API 或託管的收件匣 API。Tmailor 網頁收件匣不是這樣的工具，但 Tmailor 臨時郵件 API 是：測試可以建立僅接收的地址、列出並讀取訊息，並取得 API 找到的一次性驗證碼或驗證連結。MCP 伺服器讓 Claude、Cursor 或 VS Code Copilot 等 AI 代理，也能對你擁有或獲准測試的註冊流程執行同樣的操作。

無論你選擇哪種工具，以下幾個習慣能讓無人值守的電子郵件測試保持穩定：

• 讓每次測試執行都使用專屬地址和關聯 ID，這樣先前執行延遲送達的郵件就不會誤觸錯誤的斷言。
• 使用專門等待郵件送達的機制並搭配合理的退避策略，與整體測試逾時分開，並記錄每封郵件所花的時間。
• 依收件人和主旨精確比對訊息，而不是只讀「最新一封郵件」。
• 在 CI 日誌中遮蔽驗證碼與魔法連結，因為日誌的保存時間往往比收件匣還長。

也要清楚說明通過考試能證明什麼。「應用程式產生並交接了電子郵件」、「一個託管的測試網域透過公開電子郵件基礎設施接收了郵件」以及「Gmail 將郵件放進收件匣，而非垃圾郵件」是三個不同的事實。SMTP 捕手能證明前者，託管收件匣 API 能證明前兩者，而第三者兩者都無法證明。關於在 GitHub Actions、GitLab CI 和 CircleCI 上的管線設定，請參考 CI/CD 管線中電子郵件測試 的指南。

妥善保管測試資料並遵守規則

在臨時測試收件匣中使用合成身分和非敏感內容，並只針對你擁有或獲授權評估的系統執行註冊測試。將 QA 帳戶排除在生產環境分析之外，遵守速率限制，並將受監管的資料、憑證、附件及保留證據移至經核准的公司管控系統。

• 臨時信箱裡不放真實資料。 切勿將真實的客戶紀錄、憑證、API 金鑰或受監管資料轉送到臨時信箱地址。請使用名稱明顯虛構的合成使用者。
• 只測試你獲准測試的範圍。 請針對你自己的產品或你獲授權測試的系統執行註冊測試，並尊重該服務的速率限制和條款。不要用臨時信箱在第三方網站上大量建立帳號。容量與負載測試應該在你自己的預備環境中進行，並使用 SMTP 捕手或託管的收件匣 API。
• 讓 QA 流量不影響生產數據。 清楚標示測試帳號，並將它們排除在分析和成長儀表板之外。避免從生產寄送網域大量寄送測試郵件，因為退信和客訴可能會損害其聲譽。
• 把政策寫下來。 說明哪些流程可以使用臨時信箱、哪些需要公司信箱、測試資料保存多久，以及誰有存取權限。當界線已白紙黑字寫明，安全與合規審查就會進行得更快。

當資安人員詢問供應商如何處理資料時，請檢視它收集了什麼、訊息保存多久，以及存取機制如何運作。這份關於 臨時郵件與線上隱私 的概述從使用者角度涵蓋了這些問題。哪些流程可以使用拋棄式信箱的決定權，仍屬於你自己的法律、隱私和安全團隊。

需要預先規劃的限制

Tmailor 網頁收件匣適合手動快速檢查非敏感的收件郵件（自動化則要靠臨時郵件 API）。在選擇它之前，請先判斷工作流程是否需要對外寄送動作、附件、長期保存的證據，或可長期復原的地址。只要有任何這類需求，就應改用公司管控的信箱或專業測試工具；以下清單說明了原因。

• Tmailor 僅能接收郵件。它可以檢查註冊、驗證和 OTP 等收件郵件，但無法處理回覆流程，也無法處理任何從該地址發出的郵件。
• Tmailor 不接收附件，因此發票、合約或文件投遞類郵件需要公司信箱或測試工具。
• 訊息自抵達起約保留 24 小時。請匯出後續深入調查所需的連結、驗證碼和時間戳。
• 存取權杖是重新開啟一個位址，而非過期訊息，且遺失的權杖無法恢復。
• 網頁收件匣需由人工閱讀。無人值守的收件匣讀取需要 SMTP 捕手或託管收件匣 API，例如 Tmailor 臨時郵件 API。
• 有些服務會封鎖拋棄式信箱網域。如果你測試的流程是刻意如此，請改用真實或公司控制的地址來驗證。

選擇合適的測試收件匣

請依測試必須證明的內容來選擇收件匣。不需要實際投遞時，使用保留的範例網域；手動且非敏感的檢查，使用臨時信箱；需保留或涉及敏感資訊的流程，使用公司信箱；能控制外寄設定時，使用 SMTP 捕手；無人值守的端對端測試，則使用託管收件匣 API。

對於手動案例，臨時收件匣，並從你接下來要上線的註冊流程開始。臨時信箱還有許多 除了品質保證 等用途。