OTP 自动化测试：从测试信箱里取出那串数字

端到端测试跑到验证码那一步很常见地会卡住：页面在等一串数字，测试却不知道去哪里拿。可行的做法是从测试信箱里取出最近一封信、解析出那串数字、再填回表单。听起来简单，做起来会遇到超时、旧信干扰和重发限流三件事，本文把它们逐条讲清楚。

端到端测试里验证码卡在哪一步

卡点通常不在「拿不到信」，而在「不知道拿的是哪一封」。收件箱里可能同时存在上一轮的验证码、系统通知，甚至语言不同的模板。解析逻辑如果只认第一封，就会在第二轮开始出错。

从测试信箱里取验证码，主要会遇到这几件事：

另一个卡点是时序：页面点完「发送验证码」之后进入倒计时，测试要在这段时间内完成取信与填写，否则会撞上按钮不可用。所以正确的顺序是先确定这一封，再解析，再填回。

最稳的办法是给每轮测试一个独立地址。地址本身就是标识，收到这个地址的信必然属于这一轮，不用比对主题，也不用比对时间。

如果必须共用信箱，就要靠可识别的特征：收件地址前缀、主题里的标识，或者正文里的订单号。这些都能用，但都比独立地址脆弱——模板一改，解析就断了。

解析本身也要保守：只在明确的字段或模式里取数字，不要从整封信里挑第一个看起来像数字的东西。验证码之外的数字很多，金额、时间、单号都长得差不多。

超时的原因是投递是异步的：信什么时候到不由测试决定。因此等待必须是轮询加上限，超时即失败，并且失败时把当时收件箱里的内容留下来，方便判断是信没到，还是解析错了。

旧信捣乱通常来自三处：地址被复用、收件箱没有清理，或者系统把上一轮的验证码又发了一遍。这三件事都能通过隔离与清理避免，而且成本很低。

还有一种情况是重发限流：连续请求验证码之后，系统会暂时不再发送。这是设计，不是故障——它保护的是所有用户，不该为了测试而关掉。

不建议。限流是产品行为的一部分，关掉它等于把一条真实存在的分支从测试里删掉，用户遇到的「点太多次之后收不到信」就永远不会被验证。合理的做法是给测试准备一个不会被卡住的额度策略，但依然保留对限流本身的用例。

如果确实需要「请求太频繁」这个场景，那就主动触发它，断言系统的提示与冷却之后的行为，而不是回避它。重发次数与冷却时长属于产品决定，本文不给具体数值；你要断言的是行为，而不是某个常数。

每轮测试换一个地址，就能让「这一封」变得没有歧义。打开临时邮箱，生成地址、填进注册页，信到了会自动出现在收件箱，页面会把验证码单独提取出来，点一下就能复制到需要填写的地方。

对人工排查来说，这个页面也够用：发件人、主题、正文都看得到，不需要额外装邮件客户端，也不会把测试流量引到你自己的常用邮箱。

解析要按「最新一封匹配主题的那封」来取，而不是无条件取第一封。主题匹配用宽松的包含关系，别把整个主题写成精确相等，否则模板一改就断。

重试要有上限，并且上限要能配置。每次重试之间留出间隔，别把信箱当成高频轮询的接口。超过上限就失败，同时保留原始报文——没有原始报文，你分不清是信没到、解析错了，还是填错了字段。

最后，人工兜底要保留。自动化跑得快，但它失败时，值班的人需要一条能立刻手动完成验证的路径；这条路径平时不用，出问题时价值极高。相关做法可以对照验证流程该怎么测和在持续集成里捕获邮件。

自动化负责重复的部分：每轮换地址、取信、解析、填回表单、断言结果。人工负责自动化做不好的部分：确认页面提示是否说得清楚、确认验证码在过期之后确实失效、确认连续请求之后的提示是否合理。这两类工作不能互相替代——用自动化去判断文案好不好，或用人工去重复几百次填表，都是浪费。

分工要落在具体的场景上。开发改了解析逻辑，跑自动化确认没有回归；产品调整了验证码的有效期或重发策略，人工走一遍确认体验没有变差。每次回归时优先跑「变量缺失、地址被拒、重复触发」这类容易坏的分支。

出问题时，自动化的价值在于留下现场：原始报文、当时的收件箱内容、填进去的与预期的是否一致。人工的价值在于判断这个现场意味着什么。把两者合起来，验证码这一步通常就不会再成为整条流水线的瓶颈。

配置同样要集中：地址来源、轮询间隔、重试上限、失败时的留证位置写在一起，别让每个用例各自定义一套。每条失败记录里保留使用的地址、主题与解析结果，但不要写入完整的验证码——需要复现时用时间与主题去定位，比留着那串数字更安全。

先把「这一封」的判定方式定下来，再写解析与重试，最后补一条人工兜底。要一个能立刻收信的地址，打开临时邮箱即可。整套注册与验证的检查点，见邮箱验证测试的覆盖点以及用临时邮箱测试注册流程。

测试中收到的验证码与地址只用于验证流程，不能代表任何真实身份。