题目重点：在UI到后端数据之间验证真实journey，控制fixture、异步等待与运行成本。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练项目含前端、API和数据库，关键journey需按真实产品替换。
- E2E不等于所有case都从浏览器走，第三方真实依赖按测试环境合同决定。
解题路线
- 从用户价值挑少数关键journey，例如登录→创建资源→刷新查看→授权另一用户→撤销权限。明确每步UI、API与持久化预期，避免只断言按钮存在。
- 基础环境要可重建，版本一致、迁移完成、独立测试账户与数据，外部服务用sandbox或受控替身；同时保留少量真实边界契约测试，mock不能证明供应商兼容。
- 定位元素使用稳定可访问名称或专用标识，避免易变CSS结构。等待可观测状态/网络/完成事件，不固定sleep；超时保存截图、请求日志和服务trace以能分层定位。
- 覆盖关键正常与一两条失败恢复，如网络失败重试、权限被撤、刷新后状态保持。大量输入边界放单测/API层，防止UI套件膨胀慢且脆弱。
- 同一次E2E跨系统trace关联，失败后区分UI事件、路由、鉴权、API、异步任务和数据提交。重跑通过不代表原失败无效，记录flaky并消除竞态或环境共享。
- CI先跑快层再关键E2E，发布前代表浏览器/设备覆盖，长期维护按journey owner；删除旧功能同时清理过时case，不以用例数量当质量。
手动走一遍
创建后页面显示资源，但刷新消失，E2E能发现只更新了前端本地状态。只等toast成功会漏缺陷，应刷新或新会话读取持久化结果。撤权后换账户直接访问URL验证后端拒绝。
规模与取舍
E2E成本主要是启动/网络/等待，case少而关键；并行度受独立账户、数据库与浏览器资源限制，不能用无限重试掩盖不稳定。
易错点与追问
容易失分的边界
- toast成功等同落库成功。
- 所有边界都堆UI层。
- 共享fixture按顺序运行才通过。
继续深挖
- 怎样设计可诊断artifact？
- 第三方mock范围如何划分？
- 哪些journey必须每次发布跑？
