用临时邮箱做测试：开发和 QA 团队如何检查注册流程

每个会发邮件的产品，都需要有人用新的地址一遍又一遍地注册。开发者会用自己的 Gmail 加上加号标签，QA 测试人员维护一张一次性账户的表格，产品经理则借用同事的收件箱。在一件事上，用临时邮箱测试比这些办法都快：准确看到新用户从你的生产环境或预发布环境的邮件系统收到了什么。

PureTempMail 的邮件服务器由我们自己运营，所以下面提到的限制都是我们的真实配置，不是猜测。本指南会讲清公共临时收件箱在测试计划中的定位、一套五分钟就能完成的手动测试、我们自己检查注册邮件时会用的清单，以及哪些情况下应该换用其他工具。

临时收件箱在各种测试方案中的位置

给测试账户提供邮箱地址，常见的方式有五种。大多数团队在同一个版本的不同阶段会用到其中两三种。

临时收件箱填补了其他方案留下的一个空缺：一封真实的邮件，由你真实的邮件服务商发出，落到一个你不掌控的域名上，几秒内就能在浏览器中看到。这是最接近新客户所见的方式，而且不用再到别处多开一个账户。

用 PureTempMail 进行一次手动测试

这是我们建议的手动检查注册流程的步骤，每一轮大约需要五分钟。

1. 1

   每个测试用户使用一个新邮箱

   在单独的浏览器窗口中打开 PureTempMail。页面加载时会自动创建一个新地址。邮箱按浏览器记忆，所以每个测试用户都要按一次新建；两名测试人员共用一台机器时，可以使用无痕窗口。

2. 2

   把地址记录在测试用例旁边

   使用之前，先把地址粘贴到测试用例或工单里。如果之后有测试人员问为什么重置邮件一直没来，你需要知道它发到了哪个邮箱。

3. 3

   完成注册，并触发所有能触发的邮件

   填完表单，然后请求新用户在第一次会话中可能触发的所有邮件：重新发送验证邮件、忘记密码、魔法链接登录、更改邮箱请求。每一封都是独立的模板，都可能单独出问题。

4. 4

   不用刷新，盯着收件箱

   我们的服务器一接收新邮件，就会通过实时连接把它推送到页面上，所以邮件出现的时间很接近它的真实投递时间。记下每封邮件花了多长时间。工作原理页面解释了投递路径。

5. 5

   用两种视图打开每封邮件

   先用 HTML 阅读，再切换到纯文本。有些客户端和屏幕阅读器会退回到纯文本视图，缺少文本部分或验证码无法阅读的问题，最先会在这里暴露出来。点击每个链接，确认它跳转到哪里。

6. 6

   流程较慢时延长有效期

   滴灌式邮件序列、延迟审批和第二天的提醒邮件都需要更多时间。按 +1 小时把计时器重置为完整的一小时。你可以一直这样做，直到邮箱创建后满 24 小时。

7. 7

   等它过期，然后测试退信

   过期之后，我们的服务器会在 SMTP 阶段以永久性的“No such mailbox”错误拒收发往该地址的邮件。再给它发一封邮件，检查你的应用或邮件服务商是否记录了一次硬退信，并停止给该用户发信。

注册邮件测试清单

这些是我们在任何产品发布前都会对其注册邮件做的检查。每一项在真实收件箱里都很容易发现，在代码评审中却很容易漏掉。

• 验证码或验证链接。邮件能送达，验证码在纯文本中清晰可读，链接只能使用一次，第二次点击时给出明确提示，而不是错误页面。
• 魔法链接和一次性验证码。新链接会让旧链接失效，过期链接会说明下一步该怎么做，在另一个浏览器中打开链接时的表现符合你的预期。
• 密码重置。邮件说明是针对哪个账户的，链接会过期，而且为未注册的地址请求重置时，不会透露该地址是否有账户。
• 欢迎邮件和滴灌邮件。第一封在验证之后才发出，而不是之前；从未确认的用户不会触发后续步骤。
• HTML 和纯文本部分。两部分都存在，内容一致，重要信息不会只放在图片里。在我们的 HTML 视图中远程图片会加载，所以你可以在那里检查图片，再用纯文本查看不带图片的邮件。
• 附件。发票和 PDF 送达时，文件名和内容类型都合理。每封测试邮件的附件请控制在 1 MB 以内，或者改发下载链接，这对真实用户本来也更友好。
• 链接目标。生产环境的邮件中没有指向 localhost、内部主机名或预发布域名的链接，跟踪重定向最终会跳转到正确的页面。
• 退订邮件头。营销邮件和滴灌邮件带有可用的退订链接；对于批量发件方，还要带有 RFC 8058 中描述的一键 List-Unsubscribe 邮件头，Google 的发件人指南要求批量发件方提供它。密码重置等事务性邮件不应因退订而被屏蔽。
• 投递时间。验证邮件如果超过一两分钟才到，就会流失用户。如果某封邮件很慢，检查你的应用是否把邮件排在其他任务后面，或者服务商是否在限制新发件方的发送速度。
• 你自己的频率限制。狂点重新发送按钮。应用应该限制次数并提示用户稍候，而不是发出十个验证码，或者悄无声息地失败。
• 重复使用同一地址。在一次会话中用同一个地址注册两次，检查第二次的表现：给出明确的“已注册”提示，并且不会创建第二个账户。
• 你的一次性域名规则。如果你的产品屏蔽临时地址，确认错误提示清晰，并且不会误伤真实的邮件服务商。下文会详细介绍。

我们的限制，以及它们对测试意味着什么

这些是我们服务器上的实际配置。请据此安排测试。

有效期

从创建起一小时。+1 小时会把它重置为完整的一小时，最长到创建后 24 小时。够一次会话使用，但不适合下个迭代还要复用的测试账户。

邮件数量

每个邮箱最多 50 封邮件、5 MB。达到任一上限后新邮件都会被拒收，所以针对单个地址的负载测试很快就无法继续计数。请为每个测试用户新开一个邮箱。

邮件大小

每封邮件最大 1 MB，包括附件。只保留前 10 个附件。

只收不发

该地址不能发信或回复。需要用户通过邮件回复的流程（例如客服工单往来）无法在这里完成端到端测试。

域名

所有地址共用一个域名。如果你的产品屏蔽已知的临时邮箱域名，它也会屏蔽我们的域名，这在你恰好想测试这种行为时很有用。

新建邮箱

同一个 IP 地址每分钟最多新建五个邮箱。共用一条办公网络的 QA 团队会共享这个额度。

删除

过期后，每五分钟运行一次的清理任务会删除邮箱及其中的邮件和附件。如果需要为缺陷报告留证据，请在计时结束前截图。

自动化

没有可供脚本访问邮箱的公开 API。PureTempMail 是为在浏览器前查看的人设计的，所以自动化测试套件应该使用下文介绍的工具。

检查测试邮件的 SPF、DKIM 和 DMARC

一封显示正常的邮件，仍然可能身份验证失败，对真实用户来说会落进垃圾邮件箱。要检查这一点，把同一封邮件发到一个能显示原始内容的邮箱（例如 Gmail 的显示原始邮件），然后把邮件头粘贴到我们的邮件头分析工具中。它会显示 SPF、DKIM 和 DMARC 是否通过，标出在另一个域名上的 Reply-To，并显示投递在哪里变慢。分析在你的浏览器中运行，所以邮件头不会发送给我们。

测试你自己的一次性域名屏蔽

很多团队在注册表单中加了一次性邮箱检查，却从来没用真实的临时地址测试过。临时收件箱就是最直接的测试输入。

• 检查提示措辞。拒绝提示应该告诉用户改用什么，例如“请使用个人或工作邮箱”。只写一句“邮箱无效”，会让诚实的用户去找一个根本不存在的拼写错误。
• 检查误判。试试小型地区性服务商和公司自定义域名的地址。按模式匹配的屏蔽列表有时会误伤它们。
• 检查每个入口。同一条规则应该同时作用于注册表单、更改邮箱设置、邀请和 API，否则用户只会绕到你遗漏的那条路上。
• 先想清楚你是否真的需要屏蔽。我们的文章网站为什么要屏蔽一次性邮箱介绍了值得屏蔽的成本因素，以及屏蔽只会让你失去诚实用户的情况。

什么时候不该用公共临时收件箱

以下情况请改用其他工具。

• 任何带有真实机密或客户数据的内容。生产环境令牌、真实发票、管理员邀请。请使用只有你的团队能读取的沙盒。
• 自动化测试和 CI。在开发和 CI 中，让应用把邮件发到 Mailpit 这样的本地捕获工具；当测试必须在已部署的环境中运行时，使用 Mailtrap 或 Mailosaur 等托管沙盒。较早的本地捕获工具 MailHog 已不再维护，通常用 Mailpit 替代。
• 带有真实用户数据副本的预发布环境。问题在于这些复制过来的数据。请先清洗数据，并把预发布环境的邮件导向捕获工具，确保测试永远不会给真实客户发邮件。
• 需要长期保留的测试账户。给销售用的演示账户，或给应用商店审核用的账户，都需要一个下个月还能用的地址。请使用团队邮箱的加号地址，或你自有测试域名上的全收地址。
• 绝不能真正投递的测试数据。对于种子数据和单元测试，请使用 RFC 2606 中保留的域名，例如 example.com 和 .test 顶级域名。发往它们的邮件按设计不会送达任何地方。

资料来源

• Mailpit on GitHub，面向开发者的邮件测试工具和 API，以及它关于替代 MailHog 的说明。
• Mailtrap Email Sandbox 文档。
• GitHub 上的 Mailosaur 客户端库。
• RFC 8058，Signaling One-Click Functionality for List Email Headers。
• Google，电子邮件发件人指南。
• RFC 2606，Reserved Top Level DNS Names。
• 邮箱有效期、容量和数量限制、频率限制、过期后的 SMTP 拒收以及清理时间，均来自 PureTempMail 自己的服务器配置，常见问题中也有汇总。