1. 测试准备
使用非生产环境与合成用户，确认收件地址仍在有效期内。
记录构建号、模板版本、语言、触发时间与预期结果。
为本次用例设置唯一事件号，便于从日志追到收件箱。
开发与 QA 检查清单
发送前、到达后，把测试邮件逐项验清
一封邮件“能收到”还不够。用这份清单同时检查业务触发、收件身份、内容层级、行动入口、时序、失败路径和隐私边界，让发布结论可复现。
覆盖范围
六组检查，组成一次完整回归
卡片不是静态装饰。按测试顺序从左到右执行，任何阻断项失败都不应只靠“再发一次”放行。
2. 触发与投递
业务动作只生成一封目标正确的邮件，没有重复或误发。
队列成功执行，发送商事件能对应同一消息 ID。
到达耗时在预期范围，延迟与退信有可理解的状态。
3. 主题与预览
发件人名称和地址可识别，Reply-To 指向预期渠道。
主题明确且变量完整，不泄露环境名、对象或占位符。
预览文字补充主题，不重复标题，也不露出 CSS 或退订碎片。
4. 正文与行动
标题、说明、主按钮层级清楚，用户无需猜下一步。
按钮文字具体，目标域名正确，跟踪参数不破坏跳转。
图片有替代文字，关闭图片后仍能理解核心任务。
5. 验证码与安全
代码位数、有效期与页面提示一致，醒目但不写入主题。
重发产生的新旧代码关系符合规则，过期代码明确失败。
日志和错误提示不暴露完整验证码、令牌或恢复链接。
6. 兼容与收尾
桌面与窄屏均无横向溢出，深浅模式下文字仍可读。
纯文本版本表达同一动作，长链接与长单词可换行。
测试数据按计划删除，临时地址不留在生产账户资料中。
身份和触发条件要能复现
测试前先写清“谁在什么状态下做了什么动作”，并列出应该发送和不应该发送的条件。只测成功路径会漏掉通知偏好关闭、账户已验证、重复事件去重等重要分支。
收件地址应从当前测试工具栏复制，避免手工输入。换地址后要同步更新测试用户，旧信件不会迁移，新旧地址混用会让结果失去可信度。
验证码与重置链接需要成组测试
检查代码长度、字符集、有效期、使用一次后失效和重发规则。页面说 10 分钟而后端 5 分钟过期，属于业务缺陷，不是文案小问题。
同时验证错误代码、过期代码、连续输入和频繁重发的反馈。链接式验证要核对协议、主机名、环境、一次性令牌和跳转后的最终页面，不能只确认按钮能点击。
HTML、图片和纯文本分别检查
在邮件正文中确认容器宽度、标题换行、按钮高度、段落间距和图片缩放。长姓名、长项目名、法语或葡语按钮比中文更容易撑破布局，应使用最长合理样本回归。
关闭图片后，品牌和核心任务仍应可辨认；纯文本版本应保留验证码、期限、链接和支持信息。不要把所有内容塞进图片，也不要让隐藏预览文本出现在正文首行。
链接、附件和回复行为不能只看外观
逐个打开主按钮、次要链接、帮助入口和退订入口，确认目标域、路径、参数与登录状态正确。测试环境链接不应误指生产写操作，生产模板也不应带测试域。
附件要核对文件名、类型、大小和权限；危险类型应被阻止或隔离。回复邮件时检查 Reply-To 是否进入预期支持渠道，避免回复到无人监控的发信地址。
语言、时区和无障碍保持一致
主题、预览、正文、按钮和错误提示必须是同一语言，日期、金额和时区按用户地区格式化。缺失翻译时应使用受控兜底，而不是在一封邮件中随机混合语言。
标题层级应连续，链接文字要描述目的，图片应有合适替代文本。颜色不能是表达状态的唯一手段，浅色文字在白底和深色文字在彩底都要有足够对比。
失败、延迟和重复也是产品体验
模拟队列延迟、服务商临时拒绝和永久退信，观察是否按策略重试并避免重复通知。用户界面应给出可操作状态，而不是把所有失败都写成“网络错误”。
若测试邮件未到达，沿应用、队列、发送平台、DNS 和接收端证据逐层诊断。保留首次失败证据，再验证修复，不要因为某次重发成功就删除原始线索。
发布门槛按风险分级
| 级别 | 示例 | 发布门槛 | 失败处理 |
|---|---|---|---|
| 阻断 | 邮件未生成、目标错、验证码不可用、主链接错误 | 必须全部通过 | 停止发布并修复根因 |
| 高 | 重复发送、期限不一致、移动端正文裁切 | 需修复或由负责人书面接受 | 建立明确期限和回归用例 |
| 中 | 预览重复、次要链接标签不清、长文本换行差 | 评估受众与频率 | 进入最近迭代并保留证据 |
| 低 | 不影响任务的轻微视觉偏差 | 不阻断核心流程 | 记录模板与客户端范围 |
把检查结果变成可追踪证据
记录用例编号、环境、模板版本、语言、收件地址前缀、触发和到达时间、消息 ID、结果与缺陷链接。截图应覆盖主题和关键正文，但要遮蔽令牌与真实个人数据。
修复后用同一条件回归，并补测最接近的失败路径。若需要帮助定位投递问题，可使用邮件送达诊断指南或联系 support@msgtmp.com。