测试到期，
不要只测试收信

一封邮件投递成功，只覆盖了流程的中间一段

复制地址，发送邮件，看到验证码——这只能证明一次投递在当时可用。自动销毁邮箱还有另一半承诺：期限到了，旧地址不再可用，邮件不能继续通过原凭证读取；新信到达时，也不应该把正在读的内容挤走。

因此，自毁邮箱测试应覆盖整个生命周期，而不只是截图里“收到一封”。从临时邮箱收件台开始，用自己控制的发件邮箱和虚构内容测试。不要为了制造样本注册真实账号，更不要把银行验证码、订单详情或客户资料当测试数据。

先写清预期：地址、邮件、浏览器凭证各自何时失效

先区分三个对象。地址决定来信投向哪里，邮件是服务端保存的内容，浏览器凭证决定谁能读取这个箱。它们不是同一件事：页面还留着一段正文，不等于地址仍能收信；本地还有凭证，也不代表服务端仍接受它。

FadeInbox 首页新地址默认保留 3 小时，成功延长一次追加 3 小时；换址则创建新的 3 小时地址，再销毁旧箱。实际到期时刻应以服务端返回和页面倒计时为准。寿命规划解释的是规则，验收记录还应写下本次观察值。

若到期后自动生成新地址，记录新旧两次任务，不能把新箱正常收信当作旧箱失效的证据。临时邮箱也不是“读完立刻焚毁”；本测试中的销毁边界是有效期结束或明确执行删除。

准备可重复样本：唯一任务编号、纯文本与 HTML 两种正文

给本轮测试一个不含个人信息的编号，例如 FX-261014-A。主题依次写成 FX-261014-A / 01 / TEXT 和 FX-261014-A / 02 / HTML。编号用于串起记录，不要把完整收件地址或访问凭证拼进编号。

两封信各承担一个任务

• 纯文本信：放入几段有序文字、一个长词和六位虚构数字，检查换行、窄屏折行与选择复制。
• HTML 信：使用自制信头、标题、验证码块和足够长的正文，同时附上纯文本替代内容。
• 共同约束：使用保留示例域名，不嵌真实登录链接、跟踪像素或外部收集表单。

验证码邮件展示要检查数字有没有被截断、正文和背景是否可读、窄屏是否横向溢出。HTML 被隔离展示时，不应继承收件台的按钮样式。外部图片被阻止也不自动算故障，关键是核心信息仍能阅读。

首页的 WhatsApp 与 LinkedIn 演示信只帮助理解界面，不证明投递链路可用。验收需要自己发送的真实测试信。未收到时先看到达诊断，不要用连续重发把延迟和重复投递混在一起。

倒计时边界：前台、后台、重新打开页面分别检查什么

记录创建后的到期时刻，再观察倒计时。前台应按秒更新，不能每次轮询才跳一次。临近边界时分别记录“到期前”“越过到期”“完成状态更新”三个时点；界面刷新可能有短暂延迟，但不能无期限保留可用状态。

切到后台，不是把寿命按暂停

让标签页进入后台数分钟，再返回。浏览器可能节流计时器，所以不要要求后台每秒都执行代码；应检查回到前台后是否按实际到期时刻校正。不能只是从离开前的秒数继续减，导致地址看起来多活了一段时间。

重开页面，检查恢复而非“重新赠时”

在同一浏览器正常关闭后重新打开页面：有效旧箱应保持原来的期限，不能无故重置为 3 小时。无痕窗口、清空站点数据或另一台设备属于不同条件，要另列用例，不要误报为恢复失败。

不要通过修改电脑时钟来冒充服务端到期。没有获准的短时测试环境时，就安排一次真实等待；可以先测其他用例，但最终仍要实际跨过到期边界。

延长与换址不是同一个动作：分别验证寿命和旧地址边界

延长应保留地址和已有邮件，只改变到期时刻。记下操作前的到期时间，点击一次，等待成功反馈，再确认新到期时刻增加约 3 小时。不要拿点击前后两个“剩余秒数”直接相减而忽略操作耗时。

换址则相反：新地址出现、新期限开始，旧箱及其邮件被销毁。先完成延长检查，再换址，观察新地址是否回到新的 3 小时窗口，而不是继承旧箱延长后的寿命。

• 延长成功：地址不变，旧信仍可读，到期时刻后移，页面有成功反馈。
• 换址成功：地址改变，旧信退出列表，选中态和正文不能串到新箱。
• 操作失败：不得宣称成功，也不能在未拿到有效新箱时先丢弃仍可用的旧地址。

网络慢时不要重复点击。若界面停在处理中，先等请求完成并核对结果。测试旧地址失效，也不能只看发件方有没有退信：对方可能排队、重试或不提供退信。

轮询不该打断阅读：用两封测试邮件检查选中态与滚动位置

先打开那封较长的 HTML 测试信，滚到正文中段，记住一行文字。再从自己的发件箱发送第二封信，等待新行出现。列表可以更新，当前主题、选中行、正文和滚动位置却应保持原样。

跨过至少两轮轮询，再手动切到另一封信。若每隔几秒自动回到第一封、正文闪一下或滚动归零，通常说明刷新列表时重建了阅读区。邮件被标成“已读”也不能成为自动切换依据。

在手机上再做一次

打开真实邮件后，应进入独立阅读层，返回与删除始终可达，背景不能跟着滚。新信到达只能更新列表，不能自动弹出阅读层。返回列表后，正在读的那封仍应有选中标记；自动选择邮件与用户主动打开，是两个不同事件。

最后删除当前信，检查是否转到另一封或清楚的空态；删空后，列表与详情都应有标题和说明，而不是残留旧信头。

到期以后仍显示旧正文：区分界面缓存与服务端可访问性

到期时看到旧文字，先不要立刻断言“服务器没删”。浏览器已加载的正文可能暂留在内存里；另一种情况是应用仍能重新取回旧详情。前者是界面清理问题，后者涉及权限或保留边界，都需要记录，但证据不同。

1. 记下到期后的页面状态：旧地址是否仍标可用，旧正文是否被撤下。
2. 刷新页面或重新打开旧邮件，确认是否真的发生新的详情读取，而非继续显示已有内容。
3. 有开发者工具经验时，在自己的测试箱内核对请求状态和响应内容；截图前遮住查询参数与鉴权信息。

网络断开、超时或任意一次请求失败，都不能独立证明销毁成功。需要确认服务端明确拒绝旧箱访问，或返回对应的过期状态。旧凭证失效也只能证明不能通过这条访问路径取回，不能单凭前端测试证明备份、日志和所有存储副本均已物理擦除。

若页面已切换到新箱，要分开记录旧箱检查结果。不要把新凭证替换进去，再用“找不到旧邮件”作为唯一证据。数据处理范围以隐私政策为准。

把测试结果写成验收记录，而不是一份含秘密的截图集

一条好记录应让同事能按相同步骤复现，同时不获得你的邮箱访问权。保留任务编号、浏览器版本、设备宽度、带时区的时间、步骤、预期和观察结果。地址可用代号代替；验证码只使用虚构样本。

任务：FX-261014-A
环境：浏览器版本 / 系统 / 视口宽度
用例：阅读长邮件时接收第二封信
步骤：打开 02 → 滚至段落标记 → 发送 01 → 等待两轮轮询
预期：新行出现；当前邮件、选中态和滚动位置不变
实际：执行后填写，不预设“通过”
证据：脱敏截图编号 / 观察时间与时区
结论：通过 / 失败 / 待复核

不要直接共享完整网络导出文件。它可能包含临时箱 token、账号令牌、邮件正文或可下载附件的地址。若必须提供诊断材料，先按团队规范脱敏并限制访问范围；拿不准时，先提供步骤和错误发生时间，而不是原始请求。

“待复核”是有效结论。比如发件方尚未投递、测试期间断网，或临时邮箱到期时电脑休眠，都应注明条件，不能为了表格整齐硬填“通过”。

测试完成后的清理，以及不能由临时邮箱证明的事情

清理自己发送的样本、下载附件和本地诊断文件，检查测试是否意外创建了外部账号或订阅。需要保存的验收记录与邮箱凭证分开存放；地址销毁不会替你删除发件箱副本，也不会清理外部平台的数据。

这一组用例能检查收信、阅读和失效边界，但不能证明所有发件平台都接受临时地址、邮件永不延迟、内容绝对匿名，或真实账号永远能找回。重要账号应使用自己直接掌控的邮箱；持续测试通知可考虑长期转发别名，它仍不等于永久备份。

选择哪种地址，可以先看一次性邮箱与别名的区别。测试收尾时最值得保留的，是可复现的边界和清楚的结论，不是一封仍能打开的旧信。