验证码测试，先对齐三个时间

先限定范围：只测有权限的流程

只在你拥有或明确获授权的注册、登录流程中开展测试，优先使用测试环境和专用账号。不要批量注册、绕过频率限制，或用临时邮箱规避网站的地址规则。对方明确拒绝一次性邮箱时，应记录限制，而不是继续更换地址尝试绕过。

先写下本轮问题：是验证“能否收到”，还是比较“重发后旧码是否失效”？一轮只改变一个条件。临时邮箱收验证码能帮助观察用户侧结果，但不能替代发件服务的队列记录、SMTP 回执或服务端验证日志。

三个时间，分别记录什么

统一使用同一设备的时钟，记录日期、时区和秒数；跨设备时先确认时钟同步。下面的 T1、T2、T3 是记录标签，不表示后台一定按这个顺序完成所有工作。

T1 请求提交

记下点击发送的时刻，再补充页面是否受理。点击成功不等于服务器已经交给邮件系统；有权限查看接口时，可另记响应时间和请求编号。

T2 邮件首次可见

记下你第一次在收件箱看见该邮件的时刻。不要拿邮件正文日期或发件端 Date 字段替代，它们不一定是接收系统的到达时间。

T3 代码失效边界

分别记录发送方声明的期限与实际提交结果。不知道从请求、生成还是发送开始计时，就写“起算点未确认”，不要自行推定。

T2 减 T1 可以称为“用户侧首次可见等待时间”，不宜直接标为“SMTP 投递耗时”。而一次过期提示通常只能证明那次提交未被接受，不能精确测出代码在哪一秒失效。

准备：一个会话，一个完整地址

打开临时收件箱后，复制实际生成的完整地址，检查注册表单中没有多余空格或缺失字符。首页的 Microsoft 与 Uber 邮件是演示内容，不是你发起的测试结果，不能计入投递记录。

• 只保留一个注册标签页，将会话记为 A；不要同时在手机上发起相同操作。
• 检查临时邮箱剩余时间，给等待、验证和整理记录留出余量。
• 关闭会改变测试条件的自动填充或自动重试，预先确定等待上限。
• 记录环境、浏览器与本轮目标，不在共享表中保存完整验证码和访问凭证。

Fwdsky 新建临时信箱默认有效 3 小时，每次成功延长追加 3 小时，以返回的倒计时为准。这是信箱的可用窗口，不是发件网站验证码的有效期；可先用有效期规划检查任务是否适合临时地址。

第一轮只发一次，建立基线

把首次请求编号为 A-R1。点击一次发送，记下 T1 与页面反馈；没有收到时先按计划等待，不立即连点。看到邮件后记录 T2、主题和可用于关联的脱敏信息，再到同一注册页面提交代码，记录提交时刻及原始结果类别。

下面是虚构的记录示例。所有时间均为同一天、同一设备的北京时间；实际测试应填自己的数据。

这轮可以得出“首次可见等待 12 秒，随后一次提交成功”，不能得出“邮件服务器投递耗时恰好 12 秒”。若测试过期规则，应另开一轮；成功使用过的单次代码，不能再用来单独判断超时失效。

七秒轮询，不是投递秒表

Fwdsky 收件箱每 7 秒自动检查一次。假设上一次成功检查时没有邮件，下一次看见了邮件，系统中的可见变化可能发生在两次检查之间；仅凭页面不能确定其中哪一秒。请求耗时、人工反应和浏览器后台节流还会增加观察误差。

手动刷新也要写进记录

如果在两次轮询之间手动刷新，标注刷新时刻。它可能让你更早看到已经存在的邮件，却没有让发送方更快投递。不同轮次一轮手动刷新、一轮只等自动检查，不应直接比较几秒差异。

推荐写法：“14:00:12 首次在页面观察到邮件，期间使用自动检查。”避免写成：“邮件在 14:00:12 精确送达 SMTP。”

需要精确的验证码投递测试时，应在授权环境中关联请求编号、入队时间、发件记录和接收日志，并确认各系统时钟一致。用户侧页面只能提供其中一段证据。

第二轮，才测试重发规则

先保存基线结论，再为第二轮建立新的记录。首次请求记 B-R1，满足发送方冷却要求后重发，记 B-R2；分别记录点击、受理和首次可见时刻。验证码重发后可能换码，也可能复用原码，不能只凭数字是否变化判断是否真的发送。

把“新旧”绑定到请求，而不是列表位置

不要默认最上方邮件一定对应最后一次请求。异步任务可能乱序完成；若正文没有请求编号或其他可靠关联，只能注明“归属未确认”。有后台权限时用日志关联，没有证据时不要强行归因。

• 先查产品规则：重发是否立即使旧码失效，还是允许短暂并存？
• 验证旧码与新码时，考虑成功验证会消耗代码或结束挑战，必要时分开测试轮次。
• 记录每次验证结果，遵守错误次数限制；不要反复试码来寻找失效秒数。

如果页面只返回“无效或过期”，保留这个合并类别。它可能涉及超时、已使用、重发替换或会话不匹配，不能直接写成“新码覆盖了旧码”。

多标签页与晚到邮件，分开处理

标签页 A 发起注册，标签页 B 又发起登录，即使使用同一个邮箱，也可能对应不同挑战。先在记录中区分页面、用途和会话，再关联邮件。不要把 B 的代码填进 A 后，将失败归为邮件投递问题。

轮次结束后收到旧邮件，应标注“晚到，属于上一轮或归属待确认”，保留原请求时间，不能重置计时。隔离条件允许时可为新轮次换一个地址，但换址后旧信箱会被销毁，不能再用它观察旧请求的后续来信。

浏览器共享的登录状态也可能让两个标签页相互影响。若需要独立会话，使用获准的隔离测试配置，并把环境变化写进记录；单纯多开一个标签页不等于建立独立会话。

失败先分类，再决定下一步

“收不到”不是足够具体的结论。把失败发生的位置写清楚，才能避免在错误的一层反复刷新。

临时邮箱有效期、代码有效期与页面重发冷却是三套时钟。延长信箱不会延长已发验证码；刷新收件箱也不会让失效代码重新有效。

结束后，保存结论而不是秘密

保存脱敏后的环境、请求编号、时刻、等待方式与结果类别。截图应遮住完整地址、代码、会话标识和私人正文；不要将收件箱访问 token 放进工单、聊天或共享文档。删除测试邮件不会撤销已经建立的第三方账号。

完成测试后清理邮件，并按被测系统的流程删除测试账号或改绑可长期使用的地址。不要让临时地址继续承担密码找回、退款或安全通知；清理浏览器数据也不等于删除服务器数据，具体边界见隐私政策。

下一步：按收信任务选择地址

只验证一次注册邮件，可以回收件箱开展下一轮；需要持续观察通知、找回流程或后续订单邮件，应使用受控的长期邮箱，或登录创建邮件转发地址。别名将来信送到你的真实邮箱，但仍需妥善管理账户访问与别名状态。

还拿不准时，先看临时邮箱与邮箱别名的区别。方法的重点不是让测试更快结束，而是让下一位复核者知道：你看到了什么，还有什么没有证据。