症状 → 最快解法：Passkey 登录失败后，不要把“邮件已发出”当成恢复通过；将 Passkey 登录与邮件恢复分成两条独立验收链路。
适用条件：你正在测试自家 Web 或 App 的 Passkey 登录，以及产品实际提供的邮件备用登录或账号找回流程；请只在自家产品或获授权环境中操作。
开发者负责定义入口和预期状态，QA 负责证明邮件与链接确实完成闭环，安全负责人负责审查恢复路径暴露的风险。邮件恢复策略由产品自行设计，不同产品的行为不能互相推定；相关官方 Passkey 用户旅程指南也将邮件或电话回退作为可选恢复思路，而非要求所有产品采用统一流程。(developers.google.com)
开发者：先划清登录与恢复边界
先写清测试对象究竟是什么：Passkey 凭据登录、邮件验证码、邮件登录链接，还是需要额外身份核验的账号恢复。名称相似不代表行为相同；验证码可能只证明收到某个地址的邮件，登录链接可能直接建立会话，而恢复链接也可能先要求用户完成其他操作。
产品行为表要以自家实现为准，不要从某个系统或平台的操作体验推断所有产品规则。产品若支持多种入口，就分别记录触发条件、要求的用户操作和预期账号变化。
| 测试路径 | 验收证据 | 不能据此推断 |
|---|---|---|
| Passkey 登录 | 凭据验证通过，产品按预期建立登录态 | 邮件恢复也能正常工作 |
| 邮件验证码 | 邮件到达指定测试地址，验证码被产品接受或拒绝 | 点击链接后的状态变化 |
| 邮件登录链接 | 链接由产品处理，且登录态符合预期 | 账号恢复或凭据重建已经完成 |
| 账号恢复链接 | 恢复动作完成，账号与会话状态符合实现 | 其他产品采用同一恢复策略 |
Passkey 本身的验收也不能只看客户端弹窗。服务端认证资料将 challenge、RP ID、来源校验、签名验证和服务端登录状态列为认证流程的重要环节；其中 challenge 至少为 16 字节，资料建议的默认认证超时为 5 分钟。这些是 Passkey 认证实现中的技术参数，不是邮件恢复链接的统一时限。(developers.google.com)
QA：把邮件证据串回本次请求
如何确认恢复邮件属于本次测试？
触发前，先准备专用测试账号与受控收件地址，为这次测试记录请求标识、测试环境、账号标识和触发时间。收到邮件后，逐项核对收件地址、主题、发件信息、正文中的操作说明，以及链接指向的产品环境；不要只凭“收件箱里出现一封相似邮件”认定关联成功。
接着把邮件链路拆成几个独立观察点：
| 观察点 | 记录什么 | 失败时先查什么 |
|---|---|---|
| 应用生成 | 请求是否触发正确的模板和目标地址 | 账号映射、恢复入口、模板选择 |
| 发送服务接受 | 应用是否收到发送端的接受结果 | 请求错误、队列状态、发送服务响应 |
| 受控收件 | 邮件是否实际出现在指定测试收件箱 | 地址拼写、发送状态、测试环境收件配置 |
| 邮件内容 | 操作说明与链接是否匹配本次产品行为 | 模板变量、环境地址、过期或重用策略 |
这几层证据不能互相替代：发送端接受请求，不代表邮件已经可读取；看到邮件，也不代表恢复操作已完成。QA 应将应用生成、发送服务接受、真实收件分开记录，排查时才能定位断点，而不是把所有问题归结为“邮件没收到”。
如需将测试收件地址与个人邮箱隔离，可以先看注册邮件的暴露面自查；如果需要选择临时地址、长期别名或常用邮箱，可参考不同邮箱地址的选择矩阵。这类隔离适用于测试自家产品，不应把临时地址用于需要长期找回的重要账户。
QA：验证恢复链接到账号状态的闭环
恢复链接的处理结果与账号状态如何核验？
在测试账号上按产品真实要求完成邮件中的操作，然后检查服务端状态和后续行为，不要以页面跳转成功作为唯一断言。若产品实现了链接失效、重复使用拒绝或中途取消，就按这些预期分别执行；没有实现的分支应标为未覆盖，不能写成已验证。
| 链接处理结果 | 验收时检查 | 建议留下的证据 |
|---|---|---|
| 首次按预期完成 | 页面结果、账号状态、后续登录或凭据管理 | 脱敏后的结果、测试账号标识 |
| 链接无效或不适用 | 是否明确拒绝，账号状态是否保持原样 | 失败结果与对应状态 |
| 重复访问 | 产品是否按实现拒绝、提示或重新引导 | 再次访问的结果，不保留完整令牌 |
| 流程中途取消 | 是否保留原状态，是否出现错误登录态 | 取消后的状态与会话检查 |
Passkey 登录测试通过，能否说明邮件恢复也通过？
不能。Passkey 登录成功证明的是凭据认证路径符合本次测试条件；它没有证明恢复邮件生成、送达、链接处理或账号状态转换正常。反过来，邮件恢复成功也不能替代 Passkey 的服务端认证验收。两条路径需要分别记录通过、失败和未覆盖项。
安全负责人：审查恢复路径的风险边界
恢复路径是产品设计的备用机制，不能据此宣称邮件与 Passkey 具有相同的安全属性。风险审查应回到产品的安全目标：邮件地址如何绑定和验证，恢复后是否通知原有联系地址，旧会话是否继续有效，以及是否需要重新绑定凭据或执行额外核验。
还要检查测试数据是否越过边界：测试账号能否读取其他账号资料，恢复邮件是否混入真实用户地址，完整链接是否进入日志、录屏或缺少访问控制的报告。若产品的恢复动作会改变凭据、会话或联系地址，测试记录应明确指出状态变化，并确认通知和后续登录表现与设计一致。
标准中的恢复建议有明确适用范围，不应直接当成所有商业产品的规范。例如，数字身份指南中的账号恢复说明将账号恢复与认证区分，并讨论恢复方式和事件通知；其中关于恢复码的要求取决于相应规范的适用对象，不能直接转写成所有 Passkey 产品的邮件链接规则。(pages.nist.gov)
团队：按条件选择验收深度
- 若产品提供邮件备用登录或账号找回，就分别执行受控收件、链接处理和账号状态检查；缺少其中一项时，应将对应结果标为未验证。
- 若邮件链路由独立发送服务处理，且测试目标包括证明真实收件，就增加外部受控收件验收；只看到应用调用成功时，不要标记为“邮件已到达”。
- 若产品只使用 Passkey、没有邮件恢复入口，就只验收实际支持的登录与其他恢复机制，不要为满足测试模板而虚构邮件路径。
- 若测试环境复用了真实账号、地址或数据，就先隔离或替换，再运行恢复用例；否则，测试结果可能无法证明数据边界安全。
- 若测试涉及银行、支付、政务等需要长期找回的重要账户，不使用临时邮箱作为恢复地址；应选择能持续控制、可长期接收安全通知的邮箱。
团队最终记录可以按四类证据归档：Passkey 凭据登录、恢复邮件收件、链接处理、账号与会话状态。每一项单独标注本次覆盖范围、结果和遗留问题；产品实现或官方技术建议变化时，再按对应路径复测。有关恢复后重新创建 Passkey 的用户体验，可参考Passkey 与账号恢复体验指南。(fidoalliance.org)
如果测试只需要为自家产品准备一个隔离的收件地址，DewinBox 可以作为受控收件方案之一：页面说明提供免注册、即开即用的临时收件箱。开始前先核对页面当前公布的能力，再决定它是否适合你的测试环境；需要长期找回、持续收取安全通知或处理重要账户时，仍应使用长期可控的邮箱。