注册邮件到达顺序怎么测？

注册测试中最难复现的问题往往不是邮件完全丢失，而是两封邮件到达顺序和发送顺序不一致。第一封晚到，第二封早到；用户打开顶部那封，却输入了已作废的验证码。要辨别这些情况，先给每轮测试一个干净的收件地址，再同时记录页面事件与收件事件。

先确定一次测试的起点

在发送前记下浏览器时间、测试环境、注册账号和收件地址。用临时测试邮箱收件台领一个新地址，确认里面没有上轮留下的邮件，再把它填入注册表单。不要把同一个地址同时分配给几个并发用例，否则信件进入同一列表后很难还原是谁触发的。

页面的「发送成功」并不等于邮件已经交给用户。它可能表示前端请求成功，也可能只表示消息排进了队列。用四个时间点拆开观察：用户点发送、页面提示成功、邮件显示在收件箱、用户真正打开邮件。能访问服务器日志的团队可以另记邮件服务接受请求的时间，但不要把内部日志时间与用户本地时区混写在一个字段里。

把发送和到达写在同一张表

一个最小的测试记录至少要包含请求序号、操作动作、操作时间、邮件主题、收件显示时间、正文中的有效期，以及实际输入的验证码所对应的请求。时间精度按你的系统要求决定；对秒级重发场景，至少记到秒。记录只保存在受控测试环境，不要把原始验证码上传公开工单。

这不是规定服务必须按秒投递，而是让缺陷有证据：如果 UI 只按到达时间排序，A 可能被误认成最新验证码。记录两封邮件的主题、正文提示和邮件时间字段，确认产品是否明确解释「仅最新验证码有效」。

重发时要测哪些分支

冷却期间重复点击

先确认按钮是否禁用、是否显示剩余等待时间。等待期间不断点击或快速按回车，观察最终只产生一封信还是多封信。若是移动端，测试切到后台再回来是否会把计时重置；计时显示和真正允许发信的时刻应当吻合。

前一封晚于后一封到达

依次用 A、B 两封邮件中的码进行验证，记下每个码的期望结果和实际提示。不要假定所有系统重发后旧码都会立即失效：应先查看产品规则，再针对规则写断言。更重要的是，用户应能识别出哪封邮件与当前输入框相关。

有效期临界点

从「发出」还是「收到」开始计时，由应用规则决定。若邮件正文承诺十分钟有效，分别在临界点前后验证；邮件若因队列延迟才抵达，实际可用时间可能明显短于文案承诺。把时间与页面提示一并记录，避免只写「偶发过期」。

收不到信时先定位哪一段

先确认复制到表单的地址完整无空格，然后看表单是否真的接受了输入。接着在收件台手动刷新、核对当前地址是否被换过或过期。若服务方有投递日志，核对它是否接受了发送请求；仅凭用户看不到邮件不能断言是收件箱故障。不同服务可能拒收一次性邮箱域名，这属于输入策略，不是投递延迟。

新分配的地址默认有效 3 小时；较长的回归项目先用寿命规划器估算操作窗口。若要隔天重看注册邮件，不要使用会销毁的测试收件箱，改用长期转发别名或团队控制的测试邮箱。要覆盖正常注册、无效码和重复账号等场景，可以照着注册测试清单逐项走。

把时间线交给开发时写什么

给出环境、测试地址的去敏版本、请求序号、各事件时间、实际邮件主题和期望行为。截图应只保留与定位有关的 UI 状态；验证码、完整地址及激活链接不要作为公开附件传播。若能稳定复现，写清「第几次重发、经过多久、先到哪封、哪个码成功」，比一句「收信慢」更能帮助定位队列与状态更新。

把同一批测试限制在一个可管理的时间窗口，每做新一轮就换新地址。用这种方式，即使最终结论是第三方延迟，也能向团队说明观察到了什么、尚未证明什么。