测试注册验证码时，一次成功路径只说明邮件可以到达，不能说明重发时的状态切换没有问题。先确认产品规定的是「最新码有效」还是「在有效期内的码均有效」，再设计用例；否则看到旧码能用就直接判错，很可能是在检验一个并不存在的需求。
给每轮测试准备独立地址
从临时测试邮箱取一个新地址，记下当前时间和预期有效期，在待测系统的注册页触发首封邮件。等首封邮件显示在收件台后，记录主题、到达时间和邮件正文对有效期的描述。测试结束后换新地址再跑下一种分支，不要让多轮旧信混在同一个列表里。
地址并不是验证流程的唯一状态：用户输入的邮箱、当前验证码、发送次数、下一次允许重发的时刻和登录页所处步骤都可能变化。制作记录表时为每个事件增加「当前邮箱」和「第几次发送」两列；必要时再记下被测系统返回的请求标识，但不要公开复制完整验证码。
冷却期：测视觉计时，也测真实限制
在按钮刚显示倒计时时连续点击或用键盘快速提交，观察是否发生重复发信。切换浏览器标签、刷新页面、断网后重连，再观察前端倒计时是否与服务端限制同步。前端按钮变灰不是防刷的证据：若通过重新打开注册页就能绕过限制，用户会收到一堆难辨新旧的信。
如果产品说明每隔一分钟可以重发，分别在冷却末尾前一秒和结束后一秒操作。记录可见提示和实际新邮件数量；避免把网络波动误判成「倒计时少了一秒」。需要测服务端限制时应使用团队允许的测试环境，别向真实业务地址连续触发大量邮件。
旧码与新码：先定义规则再断言
第一封抵达后记作 A，在允许重发时触发 B。确认两封邮件都属于同一账号、同一环境；先输入 A，再输入 B，各自观察是否能通过以及页面给出的解释。若首封邮件稍晚才到，按发送序号而非列表顺序判断新旧。可参考注册邮件时间线记录法还原到达顺序。
分三种情况写期望结果：产品规定旧码在新码发出后失效；产品允许两个码在各自有效期内并行；产品只允许重发后最新一封邮件里的链接使用。一个团队不应混用这三种规则。若系统没有明确说明，先提出需求澄清，而不是把测试通过/失败的标准留给个人猜测。
再试一次故意输入错误码：提示应该让用户知道是错误、过期、频率限制还是账户已验证。不要在公开截图中保留可用的验证码或完整激活链接；测试时只记下这封信的序号和验证结果即可。
改邮箱后重发：检查发往哪里
在验证码输入页选择修改邮箱，换成另一个独立测试地址。提交后检查新邮件是否只发往新的地址、界面是否显示新邮箱、旧邮箱收到的码还能否验证新注册流程。若产品允许回退到旧邮箱，应观察整个状态切换，而不是只看邮件标题。
修改邮箱后如果旧地址仍不断收到重发邮件，问题可能在账号绑定、队列任务或前端保存的字段。保留两个收件地址的去敏版本、每次点击的时间和当前页面显示的目标邮箱，才能区分「任务排队较晚」与「真正发送到了错误目标」。
边界测试要包括过期与重复提交
有效期结束前后分别输入 A 和 B，并记录是按邮件生成时间、发送时间还是输入时间判定。验证码已成功使用后再次提交同一码，应按产品设计拒绝或明确提示已完成；按浏览器后退键也不应再次激活账号。若注册页面有多个入口，例如移动网页和桌面网页，检查冷却时间与旧码状态是否跨设备一致。
临时测试地址默认 3 小时可用，适合当次注册验证。若回归测试跨天或需要回看已发邮件，请先看测试邮箱寿命规划器，需要长期保留时改用转发别名或由团队管理的测试邮箱，而不是依靠一个已过期的临时地址。
最后交付一份能复现的记录
把「前置条件—动作—预期—实际—可见证据」写成一行一事件。前置条件包括环境、账号状态和哪封邮件已经抵达；动作区分点击发送、点击重发、改邮箱和提交验证码；结果包含倒计时、收件地址及错误提示。完整测试集合还应覆盖首次注册、重复注册和激活，可用注册流程测试清单补齐遗漏。
如果重发成功但用户仍无法登录，记录属于哪一个码、在什么时刻输入、当时页面显示哪个邮箱。这样研发才能查找状态不一致的环节，而不是只收到一句「验证码偶尔无效」。