邮箱验证测试的重点不在「能不能收到信」，而在收到信之后系统怎么处理那个令牌。正常点击链接一次就通过，这条路径谁都会测；真正会出事的是过期链接、重复点击、换浏览器，以及验证信根本没到。本文把这些情况拆成可执行的检查点，并说明测试该怎么组织。
验证流程一共有几条入口
邮箱出现在流程里的位置通常有四个：首次注册、更换邮箱、找回密码，以及登录时的二次确认。它们的共同点是需要证明「这个地址确实属于发起操作的人」，手段一般是一封带链接或带验证码的邮件。
四条入口不应该共用一套用例：注册时邮箱还没有绑定账号，换绑时旧邮箱与新邮箱都参与，找回密码时必须先有账号。状态机起始条件不同，能出的错也不同。
一个常被忽略的前提是邮箱唯一性规则：同一个地址能不能挂两个账号，决定了后面一大半用例的期望结果。这条规则应该先确认，再动手写用例。
正常路径之外必须覆盖的四种情况
- 令牌过期：链接点了但提示失效，系统应该给出重新发送的入口，而不是一个死页面。
- 重复点击：同一个链接点两次，第二次应该被识别为已使用，或者被安全地当作同一次验证处理。
- 换浏览器或换设备：在另一台设备上打开验证链接，行为应该与原设备一致，除非业务明确要求绑定会话。
- 验证信没到：用户没有收到信时，系统要给重新发送的路径，并把重复发送限制在一个合理的频率内。
这四种情况里的每一种都比正常路径更值得写用例，因为它们出现的概率不低，而且一旦出错，用户会卡在流程中间，既不能前进也不能重来。
验证信一直没到，这条路径怎么测?
先要能区分「用户没收到」和「系统没发出」。测试时可以让收信地址保持可观察，检查系统是否真的把信交给了投递环节；这一步是异步的，所以验证方式只能是等待与轮询，而不是等待固定秒数。
再检查重新发送的行为：连点多次之后，系统是每点一次都发一封，还是把请求合并。两种设计都成立，但必须是你有意选择的那个，而不是碰巧呈现出来的结果。
最后检查兜底文案。信没到时页面上应该有一条明确的下一步，而不是让用户自己猜是等下去还是重新注册。这条看起来只是文案，实际上是很多工单的来源。
同一个邮箱挂两个账号会怎样?
这是唯一性规则最直接的体现，也是最容易出安全问题的分支。常见设计是拒绝第二个账号，或者要求先在旧账号里完成解绑。测试要断言的是：系统的拒绝理由是否准确、返回的信息有没有额外泄露账号是否存在、以及有没有留下半成品账号。
如果产品允许同一地址挂多个账号，那么找回密码流程必须能区分账号，否则用户会收到一封让人不知道在给哪个账号改密码的信。这条在验收时经常被漏掉，直到有人投诉才被发现。
在本站的临时邮箱里跑一遍验证流程
要在一个循环里反复走注册流程，收信地址就得跟着换。打开临时邮箱，为每一轮生成一个新地址，信到了会自动出现在收件箱里，验证码被单独提取出来方便复制。整轮跑完把地址换掉，不会污染下一轮。
需要连续重复时，这套做法的好处是每个用例的收信范围都是独立的，不用担心两轮之间抢同一封信，也不用为了清理历史邮件额外做事。
给开发者：令牌、状态机与幂等
先定义状态，再写用例：未验证、已验证、换绑中，这三个状态之间的迁移应该有明确条件，而令牌只是触发迁移的一种输入。把状态写清楚之后，「重复点击」这类用例的期望值就不用猜了。
令牌要做到一次有效，过期之后不给出可推断的信息。接口层面要接受并发点击：两个请求同时到达时，只能产生同一个结果，不能留下两条验证记录。
不要只测顺利的那条路。真正昂贵的故障是「信到了但点不动」和「点了两次账号被锁」，前者考验令牌校验，后者考验幂等。想覆盖「信没到」这条路径，还要把投递环节也观察起来，具体做法见在持续集成里捕获邮件与地址格式的边界。
邮件之外的验证方式也要覆盖
很多系统的验证不止一条路：邮件链接之外，还有输入验证码、应用内确认、短信。每条路都要单独走通，而且彼此的状态要一致。常见缺陷是：用户先点了邮件链接完成验证，随后收到的验证码仍然有效并能再次使用；或者反过来，验证码用过之后链接还能再点一次。这类不一致在只测一条路时看不出来。
失败分支同样重要。地址写错时，系统会不会明确告诉用户信发不出去，还是假装成功让用户一直等；用户在等待期间点了「重新发送」，系统是又发一封还是复用上一封；超过一定次数之后的提示是否清楚。这些分支平时没人点，出了问题却最伤体验。
还有一条边界：不要把验证流程做成唯一的安全判断。邮件只能说明「这个人能收到这个地址的信」，不能证明他是谁。涉及资金或敏感操作时，还需要别的确认手段。
下一步
把上面四类异常情况写成用例，再补一条「信没到」的兜底检查，覆盖度基本就够用了。要跑这些用例，先打开临时邮箱拿一个可丢弃的地址当收件人；完整的注册与验证测试思路，可以参考用临时邮箱测试注册流程。
文中提到的地址与验证码只用于测试，不能作为真实身份或长期联系方式。