端到端测试应验证用户真正完成任务时会看到什么：能否登录、能否提交、错误是否可理解、关键数据是否正确显示。把测试写成依赖 CSS 层级、随机线上数据和固定等待时间的脚本，短期看似省事，长期会产生大量无法复现的失败。Playwright 官方最佳实践把用户可见行为、测试隔离和稳定定位器作为重点，这也是建立发布前检查的起点。
先挑四条高价值路径
不要试图第一天覆盖全部页面。先选注册或登录、核心创建动作、支付或提交前确认、权限受限提示等路径。每条路径写成给定什么状态，用户做什么，看到什么结果。例如管理员创建一篇草稿并保存后，刷新页面仍能看到标题和状态；普通用户访问后台链接时看到权限提示。这样的描述比测试编辑器更容易发现缺口。
测试隔离与数据控制
每个测试都应能独立运行，不依赖上一个测试留下的 cookie、账号或数据库记录。准备专用测试账号和可重置的测试数据；不要在生产环境用真实客户数据跑破坏性操作。需要外部接口时，优先在测试中模拟可控响应，而不是依赖第三方站点是否稳定。这样失败时才知道问题来自自己的产品还是外部服务。
定位元素时看用户能看到什么
优先使用角色、可访问名称、标签、占位提示或稳定的测试标识。按钮有明确文字时，用按钮名称定位比依赖第三层 div 更耐改；表单标签发生变化时，测试也能提醒你检查用户文案。不要把内部函数名、临时 class 或页面实现细节当作测试契约。
避免固定等待
waitForTimeout 常会制造两种问题：机器快时白白浪费时间，机器慢时仍然失败。更好的写法是等待用户可见的状态，例如成功提示出现、按钮可点击、列表出现新记录，或网络请求完成。每个断言都应说明用户最终能确认的结果，而不是只确认脚本没有报错。
失败时留下能复现的证据
为失败测试保存截图、追踪、控制台错误和关键网络信息，同时记录测试数据版本、浏览器版本和提交号。排查时先问三件事：这次是否使用了不同数据；页面是否真的发生变化；断言是否验证了用户关心的结果。不要为了让 CI 变绿而盲目提高超时或重跑次数。
发布前最小清单
核心路径在独立上下文和测试数据下通过；关键错误提示、权限限制和空状态可读；桌面与至少一个移动视口检查关键流程；外部依赖有受控响应或明确降级方式；失败记录包含可复现材料，发布前已说明已知风险。端到端测试不能取代单元测试、代码评审或真实用户反馈。来源与核验：本文根据 Playwright 官方最佳实践和官方测试编写文档整理，命令和配置请以当前版本文档为准。
把用例写成可维护的资产
每新增一个测试，给它写清业务目的、前置数据、成功条件和责任模块。页面改版时先检查这些用例是否仍描述真实用户路径，再更新定位器。不要为了降低维护量而删除失败用例；先判断产品行为是否被有意改变，再决定改产品、改测试或补充迁移说明。
覆盖率不能替代风险判断
覆盖率高并不意味着发布安全。支付、权限、数据删除、文件上传和迁移流程即使只有少量用例，也应要求更严格的真实设备和异常路径检查。反过来，低风险的文案调整不需要用端到端测试重复验证所有后台逻辑。发布前应由产品、开发和测试共同确认本次改动影响了哪些用户路径。