先写一份可核对的预期，再打开收件箱
2026 年，邮件模板常由多个服务拼接：订单服务给出金额，预约服务提供时间，本地化层选择语言，邮件供应商再替换变量。如果测试人员只是扫一眼“看起来像确认信”，很容易漏掉数据层的错误。先准备一份独立于邮件模板的预期，才能避免拿错误结果互相印证。
使用合成订单，不输入真实姓名、地址、支付凭据或客户资料。给本轮测试一个无敏感含义的标识，例如 QA-260101；记录项目数、单价、折扣、税额、应付合计、币种、预约地点和用户语言。金额预期应从业务规则或测试夹具计算，而不是复制邮件中的数字。
示例夹具：两件商品，每件 49.90 CNY，优惠合计 9.80 CNY，本例规则为含税价、无运费，预期支付 90.00 CNY。另建不含税、含运费样本，不把这个示例当作通用计价规则。
用在线收信测试邮箱接收本轮通知，并把测试标识写入允许修改的订单备注或测试环境主题。一次只改变一个维度：先验证默认语言，再换语言；先验证普通日期，再测夏令时。若同时改变地址、货币和模板版本，即使出现问题也难以定位原因。
金额验收：符号、小数位与总额要分别看
只出现“$”不足以说明币种正确，因为多个货币共用这个符号。对于跨地区订单，应按产品规范显示明确的币种信息。中文页面生成的邮件也可能使用账户语言或订单地区决定格式，先确认选择规则，不能默认浏览器语言就是唯一依据。
检查金额时，分别核对原始数值、最小货币单位和展示格式。有的后端以“分”储存，有的接口返回十进制字符串，直接把整数传给模板会造成百倍误差；反过来，模板多除一次也会让金额缩小。日元等币种的常见小数位规则与人民币不同，不能给所有货币强行补两位。
- 逐项核对数量、单价、优惠与合计，确认优惠是整单还是逐项应用。
- 用零金额、带折扣与退款通知检查负号及“应付／已退”语义。
- 对照产品规定的舍入阶段：逐行舍入与合计后舍入可能相差一个最小单位。
- 检查小数点、千位分隔符与不换行空格，尤其在复制金额后是否仍可辨认。
不要用“视觉上相加差不多”作为通过条件。将邮件里的字段逐项抄到验收记录，与预期夹具比对。若 HTML 正确而纯文本漏了币种，也应单独报告，因为依赖文本阅读的用户看到的是另一份通知。
预约时间：写了“下午三点”，仍可能少一个条件
预约和旅行通知通常至少涉及三个时区：事件发生地、账户偏好与服务器时区。“2026 年 11 月 1 日 01:30”在某些实行夏令时的地区会重复出现，仅写本地时间并不足以唯一确定时刻。测试需要同时保留原始时间戳、时区标识与展示结果，避免把服务器 UTC 时间当作本地时间直接渲染。
选择一例接近午夜的事件，验证换算后日期是否改变；再选择业务覆盖地区的夏令时切换样本。对于美国纽约，2026 年 11 月 1 日回拨附近的重复时段尤其适合检查偏移处理。具体时区规则应以所用运行时的时区数据库为准，不要在模板里全年硬编码 UTC−5。
邮件正文可以写事件当地时间，并明确城市或时区；跨时区用户是否同时看到账户时间，则由产品规范决定。若附带日历邀请，还要单独检查日历数据：正文看起来正确，不代表日历事件的 DTSTART、TZID 或 UTC 值也正确。
时间不止在正文出现。主题、摘要预览、取消截止日期和按钮下方的小字都要核对同一事件。如果邮件在不同语言里同时出现“明天”和绝对日期，应确认相对词是否受队列延迟影响；一封延迟跨日的通知可能保留已经不准确的“明天”。
链接、图片与纯文本回退，不应共用一个通过结论
在授权测试环境中检查按钮的可见文字与实际目的地。先看域名和环境是否正确，再检查路径、订单标识与语言参数。测试链接可能包含会话令牌，工单中只记录脱敏后的结构。不要把生产退订、付款或确认按钮当成普通预览链接随意点击。
图片加载失败时，核心信息应仍可从文字理解。试着不加载远程图片，看标题、金额和操作说明是否还存在；替代文本应说明图片用途，不应用一长串促销词。临时收件箱可能会清洁 HTML、屏蔽不安全内容或无法保留 CID 内嵌图，所以这里发现的图片缺失需要结合原始 MIME 与其他客户端复核。
纯文本不是把 HTML 标签删掉就一定能用。若被测系统提供 multipart/alternative，应查看其中独立的文本部分，检查链接是否保留完整、项目是否分行、金额是否带币种、按钮文字后是否有可访问的 URL。本收件页优先展示 HTML，不能把它的画面直接当成文本部分验收证据；必要时从测试发信日志或邮件沙箱导出原始 MIME 检查。
手机上的窄视口能发现长订单号、长姓名与 URL 换行问题，但网页阅读区不是 Gmail、Outlook 或 Apple Mail 的完整模拟。需要验收这些客户端的排版时，用授权的专用测试账户逐个补测；需要了解两种工具的分工，可以先读临时邮箱与邮件沙箱对比。
发布前，给“内容正确”一个明确的范围
把每个样本的模板版本、语言、币种、时区、测试标识和预期写在同一行，再记录实际结果及证据位置。一次通过只能说明当前样本下观察到的行为，不证明所有地区和客户端都已覆盖。发布说明中应保留未测范围，例如“未验收日历附件”或“纯文本部分待原始 MIME 复核”。
问题归属也要具体：变量未替换交给模板层，金额计算错误回到业务服务，日期偏移错误检查时区数据与格式化调用，只有单个客户端错位才进入客户端兼容排查。模板里出现未经转义的用户输入，则应作为安全问题在受控环境处理，而不是把包含恶意内容的样本发送给真实用户。
最后，确认通知出现的时机合理：取消后不应再发送“即将开始”的提醒，退款后不应仍显示“待付款”。这需要结合事件与队列记录，不仅是看一封信。若问题是新旧通知先后颠倒，可接着使用验证码时序文章中的三个时间点记录方法；涉及退信和投递名词时，再查收信术语表。