返回开发者与 QA
真正困难的是：现在到底哪个code有效
如何测试邮件 OTP，而不误用错误验证码
围绕请求边界、最新code、resend、过期、replay和最终状态测试OTP，不要把收件箱里任意一个数字当成成功证据。
约 8 分钟
当同一收件箱里存在多个看似合理的OTP时，测试很容易产生歧义。系统却有明确规则：哪个request生成了code、有效多久、resend是否使旧code失效、成功后是否可重放。测试应该直接验证这些规则。
显式建模 OTP 状态
| 事件 | 问题 | 断言 |
|---|---|---|
| 首次请求 | 哪个code有效？ | 当前code符合策略 |
| resend | 旧code还有效吗？ | 验证真实规则 |
| expiration | 何时失效？ | 过期后安全失败 |
| success | 能否replay？ | 验证one-time策略 |
确定性的测试顺序
- 1
建立请求边界
使用新收件人或无歧义时间窗口。
- 2
等待匹配邮件
先核对sender、subject、recipient和time再提取code。
- 3
提交当前code
验证response和account/session状态。
- 4
单独测试resend
不要混在happy path里。
- 5
单独测试expiration与replay
这是不同的security property。
Retry本身可能产生新 OTP
Playwright和Cypress可以重跑失败测试。如果每次retry都会重新请求OTP，而邮箱状态继续保留，那么retry正在改变你要诊断的状态。
应按attempt隔离identity，或明确关联每一次请求。
邮件OTP并不会自动变成phishing-resistant
NIST不把email视为绑定特定设备的out-of-band authenticator。一次性并不等于抗钓鱼。
可靠的OTP测试核心是state control：已知request、已知当前code，并把resend、expiration、replay和retry分别验证。
需要一个干净的收件地址做手工邮件 QA？
使用 MailOnce 检查真实的注册、OTP、魔法链接、密码重置和通知邮件，无需把个人邮箱放进测试数据。
创建临时邮箱来源与延伸阅读
用于支撑测试建议的安全资料和测试运行器一手文档。
继续测试
继续查看同一邮件测试问题空间中的下一个边界。