“邮件收到了”不算完整的测试结果。
注册邮件可能已经到达，却发给了错误的地址；链接可能已经过期；移动端排版可能坏掉；测试环境邮件可能跳到生产站点；翻译后的主题也可能让用户完全看不懂。好的邮件测试要走完用户真正经历的路径，并在失败时留下足够证据。
临时邮箱特别适合这种工作，因为每次运行都能从一个干净地址开始。收件箱可以是临时的，测试结果不能是。
先建立一个小而明确的矩阵
优先覆盖会直接阻断用户的流程：
- 新账号验证；
- 密码重置；
- 团队或工作区邀请；
- 更换邮箱确认；
- 登录链接或一次性验证码；
- 敏感操作后的安全提醒。
每条流程至少测试正常路径、一次过期或重复使用，以及一个收件方错误。它比连续发送几十封相同的正常邮件更容易发现真实缺陷。
每个场景使用一个独立收件箱
共用地址会制造歧义。旧的重置邮件可能被误当成最新邮件，并行测试也可能消费对方的链接。
每个测试用例或每次运行都生成唯一地址，并把它和构建版本、环境、语言及场景一起记录。测试失败后，在保留时间结束前还能根据这个地址检查现场。
不要在预发布环境使用真实客户邮箱。这样既可能误发邮件，也会污染分析数据，后续清理还很麻烦。
先检查信封信息，再检查正文
点击任何链接之前，先确认：
- 收件地址就是本次测试创建的地址。
- 发件域名符合当前环境。
- 主题能说明操作，又没有泄漏敏感信息。
- 到达的邮件数量符合预期。
- 邮件时间晚于触发操作的时间。
这些检查能在正文解析掩盖问题前发现路由错误和重复发送。
按用户看到的方式测试正文
分别在窄屏和宽屏打开邮件。确认主要操作清楚可见，纯文本版本能独立读懂，超长邮箱和 URL 不会撑破布局。
验证码流程要确认最新验证码只能成功一次，用过后立即失效。链接流程则应先确认域名和环境，再打开链接。测试环境邮件跳向生产环境，即使链接能打开，也应该阻止发布。
别忽略那些不起眼但很影响体验的细节：回复地址、客服入口、过期说明、语言，以及邮件中显示的账号或工作区名称。
值得保留的反向测试
比较有价值的反向场景包括：
- 请求第二个验证码，确认第一个已经失效；
- 打开过期链接；
- 同一链接使用两次；
- 使用邮件前先改变账号状态；
- 邀请已经加入团队的地址；
- 输入不支持或格式错误的地址；
- 人为延迟到超过有效期后再投递。
这些场景能暴露竞态和误导性错误提示，而简单检查收件箱永远发现不了。
区分产品故障和投递延迟
邮件没有出现时，尽量保留用户操作、应用入队、邮件服务商接收以及收件箱到达的时间。空收件箱截图只能证明截图那一刻没有看到邮件，不能证明发送方做了什么。
提交模糊的“邮件坏了”之前，先按验证邮件没收到：一步步找出问题所在走一遍。
哪些部分适合自动化
适合自动化的是稳定契约：
- 创建唯一地址；
- 触发产品操作；
- 使用有上限的超时和退避轮询；
- 匹配预期发件人和主题；
- 读取最新的匹配邮件；
- 在产品中验证验证码或链接；
- 保存有用的失败证据；
- 完成清理。
视觉体验、文案质量和特殊客户端表现，仍应保留有重点的人工检查。自动化擅长重复，不擅长判断观感。
可靠的临时邮箱 API 自动化详细说明了轮询和清理方式。
一份真正有用的失败报告
开发者能使用的报告应该包含场景、环境、地址、触发时间、预期发件人、实际看到的邮件、最后轮询时间、响应状态，以及截图或脱敏后的正文片段。不要把仍可使用的验证码和私密链接放进公开问题。
目标不是证明“邮件系统不可靠”，而是明确哪一段契约失败，并给出可以复现的路径。