从“没收到”
定位到具体环节
验证码邮件的问题往往只暴露成一句“没收到”，但它背后至少有请求、生成、排队、投递、收件与消费多个环节。真正有效的排查，不是连续重发，而是为每个环节留下同一条可关联的时间线。
先给结论：一次偶发超时不等于邮件系统不可用，连续点击发送也不能证明问题已经消失。2026 年更可靠的做法，是把每次验证码触发看成一条短事务，用关联标识、阶段时间和明确结果描述它。
1. 先建立五节点投递模型
第一节点是用户触发请求。页面是否真的提交成功、接口是否返回可接受状态、前端是否误把失败画成成功，都应在这里确认。第二节点是业务系统生成验证码并创建邮件任务；如果模板渲染失败，消息甚至不会进入发送队列。
第三节点是邮件服务接受任务并尝试投递，第四节点是目标收件系统接收并展示，最后一个节点是用户打开邮件并提交验证码。把链路拆开以后，“邮件没到”才可能被改写成“任务在 14:03:21 入队，14:03:58 被接收，前端列表到 14:04:20 才刷新”。后者才是能修的问题。
发送接口返回成功，只代表任务被接受，不代表目标邮箱已经展示邮件。测试记录应分别保留“请求成功”和“收件可见”的时间。
2. 用同一时钟记录四个时间点
每轮只使用一个新地址，并记录触发、接口响应、邮件可见与验证码提交四个时间点。团队跨时区协作时统一记录 UTC，同时在界面截图中保留本地时区说明。精确到秒通常足够，不必追求毫秒级截图。
如果使用 RelayTmp 做短期测试，可以先在一次性收件箱复制当前地址，再开始本轮注册。不要在测试中途换地址；换地址后旧任务的邮件不会迁移到新收件箱。一次用例结束后再创建下一个身份，结果更容易对应。
| 节点 | 记录内容 | 可回答的问题 |
|---|---|---|
| 触发 | 动作、时间、用例编号 | 用户是否真的发起请求 |
| 响应 | 状态、关联标识、耗时 | 业务端是否接受任务 |
| 可见 | 主题、发件人、抵达时间 | 邮件何时进入收件视图 |
| 消费 | 提交时间、成功或失败 | 代码是否仍然有效 |
3. 给重发设置可解释的等待窗口
等待窗口应来自产品目标，而不是测试人员的耐心。若团队约定 95% 的验证码在 60 秒内可见，可以在 60 秒记录一次未到状态，再到 120 秒进行最终判定。窗口内允许手动刷新收件箱，但不要再次触发发送。
只有上一窗口结束后才进入重发用例。重发时必须明确系统规则：旧码立即失效、两枚都在短时间有效，还是只保留最后一枚。然后按抵达顺序分别提交旧码和新码，确认界面错误文案与后端规则一致。若多封邮件乱序抵达，只测“最新一封”会掩盖真实风险。
- 正常路径：首次触发，在目标窗口内抵达并成功消费。
- 延迟路径：首次邮件超过目标窗口后抵达，代码是否仍有足够有效期。
- 重发路径：第二枚抵达前后分别提交第一枚，验证失效规则。
- 重复点击路径：前端应有冷却反馈，不应无提示地产生多条任务。
4. 把证据整理成可移交的小包
高质量缺陷不需要一整段录屏。一个最小证据包应包含环境、用例编号、脱敏收件地址、四个时间点、可见主题、预期与实际结果。如果能拿到业务侧关联标识，把它与测试编号放在一起，工程人员就能跨日志查询。
不要复制验证码关联的真实账号资料，也不要把完整邮件正文贴进公开工单。截图应遮住无关身份信息。临时邮箱适合隔离低风险测试，但它不是处理生产用户邮件的合规捷径。
提交缺陷前检查
- 能说明是首次发送还是重发；
- 时间全部使用同一时区；
- 预期包含明确阈值，而不是“应该快”；
- 地址与用例一一对应，没有复用旧收件箱；
- 证据已脱敏，且没有真实用户验证码。
5. 2026 年应关注哪些指标
只有平均耗时会掩盖长尾。团队至少应观察从任务创建到供应商接受、从供应商接受到目标系统接收、从接收到用户可见三段时延，并按 p50、p95 和 p99 查看。失败率还要按模板、语言、目标域与发送通道分组，否则某一地区或某一模板的故障会被总量稀释。
同时记录重发率和“首码抵达后已失效”的比例。重发率上升未必是投递变慢，也可能是页面没有给出清晰倒计时；首码大量失效则说明有效期、投递时延与重发策略互相冲突。指标的作用是缩小排查面，不是替代真实用例。
6. 知道一次性收件箱能证明什么
一次性收件箱可以证明某个测试地址能否收到、何时可见、正文和链接是否可读。它不能证明所有邮箱供应商都表现一致，也不能绕过发送方对临时域名的限制。遇到发送方主动拒绝时，应记录为策略结果，而不是反复换地址尝试规避。
支付、医疗、工作主账号与任何需要长期找回的身份，都不应绑定临时地址。需要跨周回归同一公开身份时，可进入邮件转发控制台创建可管理别名；临时收件箱仍留给几个小时内结束的低风险测试。
创建独立地址，记录第一条时间线
打开即获得可复制的一次性邮箱，并在同页刷新和阅读真实测试邮件。