从验证码到收据：
用两封信检查邮件模板

收到不是通过：先分清三种结果

“发送接口成功”“收件箱出现邮件”和“用户能正确使用邮件”是不同的结果。发送服务接受请求，不代表邮件已经到达；邮件到了，也不代表模板完整或客户端显示一致。

因此，记录里写“网页预览下代码完整可读”，比笼统写“邮件测试通过”更有价值。若连邮件都没出现，先按验证码到达诊断核对地址、有效期和发信限制，不要把投递问题当成样式问题。

准备两类自有样本，不拿真实用户做测试

第一封使用六位测试码，例如 418752，并附上有效期、安全提醒和明确的操作背景。第二封包含订单号、长商品名、金额及付款方式，专门暴露表格挤压与字段缺失。两封都应从你自己的测试环境发出，使用虚构订单，不触发真实扣款。

首页的 PayPal 与 Steam 演示信只说明两类信息如何阅读，与品牌没有关联；它们不是通过你的发信系统投递的证据。不要仿冒这些品牌向他人发送邮件，也不要用演示排版推断对应网站接受临时地址。

先固定条件，再改模板

• 给模板标记版本，固定测试语言、发信配置和样本字段。
• 记录测试地址和发送时间，但不把信箱访问凭证写进工单。
• 准备普通字段和极端字段两组数据，例如短商品名与长商品名。
• 保留发送端生成的 HTML、纯文本版本，方便与接收结果对照。

一次性地址默认保留 3 小时，每次延长追加 3 小时；实际以收件台倒计时为准。长时间回归测试应提前规划地址寿命，不要等到地址失效再判断邮件丢失。

第一封看行动：用户能否立即找到验证码

验证码邮件排版的目标不是让人欣赏品牌，而是减少从“打开邮件”到“回到验证页面”的距离。先看列表中的主题：能否区分登录、注册和敏感操作？发件显示名是否与用户刚才的操作相符？不要在主题里堆放营销语，把关键动作挤到截断位置。

代码要能看，也要能复制

把六位数字作为真实文本，而不是嵌在图片里。选中并复制后，检查是否混入空格、换行或其他字符；视觉上的字距不应改变实际代码。再用带前导零的样本，例如 048193，确认模板没有把它当数字处理而丢掉首位。

有效期应紧邻代码，并与后端实际规则一致。“10 分钟内有效”若从签发时计算，就不能让延迟收到邮件的用户误以为还有完整十分钟。对于操作背景，只展示确实掌握的信息，不编造设备、位置或风险判断。

最后检查安全提醒：不要分享验证码；非本人操作时该怎么做。测试截图中的代码即使已经失效，也应遮盖后再对外分享。验证码邮件的说明越短越明确，越不容易让用户忽略真正需要保护的信息。

第二封看结构：长字段能否保持对应关系

收据邮件测试更像核对一张账单。用虚构订单号 STM-6093-2741-58、商品名 Hollow Lantern: Deluxe Edition、金额 $14.99 和“钱包余额”，检查标签与数值是否始终相邻。再把订单号加长，看看是否把金额列推出屏幕。

先核对事实，再看装饰

金额要明确币种，小数位与结算规则一致；存在税费、折扣或退款时，合计关系也要能解释。付款方式不能暴露完整卡号或支付凭证。缺失的可选字段应该省略或给出明确状态，而不是留下“undefined”或空白标签。

如果模板提供“查看订单”入口，在你自己的测试系统验证目的地址、订单归属与登录要求。这里的演示信假按钮不跳转，不算链接测试。邮件里显示的交易成功，也不能替代支付系统中的订单状态；真实业务仍应以服务端记录为准。

在窄屏检查：不是缩小，而是重新阅读

先在约 390px 宽的视口中检查，再用真实手机复核。按普通人的顺序读一遍：谁发来的、发生了什么、代码或金额在哪里、下一步是什么。不要只看第一屏截图，也要滚到正文底部。

• 长订单号可以在字段内部换行，但不能覆盖标签或遮住相邻金额。
• 商品名允许多行，不应为了整齐而截掉决定购买版本的后半段。
• 按钮文案较长时能自然换行，文字仍位于可点击区域内。
• 放大文字后，表格、说明和操作入口仍按合理顺序出现。

网页收件箱本身也有列表与阅读层，因此要分清是邮件内容溢出，还是承载页面的问题。仅缩窄桌面浏览器不能模拟手机邮件应用的字体替换、自动缩放或深色模式。

关闭图片之后，还剩多少有效信息

图片加载失败时，品牌标志可以消失，代码、金额和操作说明不能跟着消失。为有信息价值的图片写简洁替代文字；纯装饰图片使用空替代文字，避免屏幕阅读器反复读出无意义文件名。重要内容不要只放在背景图中。

隐藏图片，不等于测试纯文本回退

HTML 邮件纯文本回退指的是邮件同时提供的 text/plain 内容，不是浏览器把 HTML 标签去掉后的结果。两种版本都应由发送端检查；需要核对 MIME 结构时，应查看自有发送记录或支持查看原始邮件的客户端。

纯文本版本至少保留操作目的、完整代码与有效期，或订单号、商品、金额和付款方式。必要链接应有能读懂的上下文。不要只写“请查看 HTML 版本”，也不要让文本版继续引用 HTML 里已经修改掉的旧金额或旧期限。

如果网页预览没有提供关闭图片或切换文本版本的入口，就把这项标记为“未验证”，转到其他测试环境完成；不能因为页面看起来正常，就把两项一起勾为通过。

把发现写成记录，而不是一句“有点挤”

一份好记录应该让没有在现场的人，也能重现同一个问题。最低限度包含模板版本、测试条件、样本特征、预期、实际和脱敏证据。不要只贴一张没有环境说明的截图。

把结论写成“通过”“失败”或“未验证”，并标注范围。涉及内容缺失、错误金额或不可用代码的问题，优先于边距不一致；修复完成后重新发送，不要只在浏览器开发工具里改到好看就关闭问题。

网页预览之外，还要去哪里复核

网页预览使用浏览器的渲染能力，而 Gmail、Outlook、Apple Mail 等邮件应用会对 HTML、样式、字体和图片采取不同处理。安全清洁还可能移除脚本、表单或其他危险内容；预览中没有它们，不是客户端兼容性的保证。

根据真实用户分布建立最小客户端矩阵：例如 Gmail 网页版与手机应用、目标 Windows 环境中的具体 Outlook 版本，以及 iPhone 上的 Apple Mail。写清系统和应用版本，别只写“Outlook 已测”。

在这些环境中分别检查浅色与深色、图片受限、放大文字和链接操作。需要无障碍支持时，用实际屏幕阅读器验证阅读顺序。一次性邮箱收到邮件，不代表其他服务商的垃圾邮件判断、域名信誉或认证结果已经通过；投递与发信认证应另设检查项。

结束测试：让样本有一个清楚的结尾

保存必要的脱敏记录后，删除不再需要的测试邮件。删除单封邮件不等于立即注销整个地址，也不等于抹掉发送端日志、工单附件或本地截图；这些副本需要按各自的保留规则处理。

不要把一次性邮箱地址留在生产告警、账单、密码恢复或长期回归脚本里。需要持续收信时，可评估长期转发别名，并验证它是否适合你的流程；关键账户仍应绑定能够长期控制的邮箱。

最后留下的不是两封漂亮截图，而是一组能复测的条件：行动信息是否清楚，交易事实是否完整，哪些客户端已经检查，哪些仍待验证。关于浏览器凭证与数据边界，可继续查看隐私政策。